PCSX2 Documentation/Google Code svn repository comments archive 5000 to 5499

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 5000

gsdx-ogl: LINUX-ONLY
* add the forgotten hardware renderer object.
Oh my gosh! Opengl is 20% faster than Dx!!!
In case you're wondering, we're having the cake and cookies in the dev channel :p
hooo atlast but way fucking gsdx-ogl i wanted something more powerfull with this 5000 revision something about speeding the core threads by 20%
not some gsdx-ogl
just for 5000th rev
btw, gsdx-ogl, will it be for windows, or remain Linux-only?
i think it will be only for linux because its not on the automated pcsx2 builds
Stuck again at make with:
[ 73%] Building CXX object plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/GSDeviceOGL.cpp.o
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp: In destructor ‘virtual GSDeviceOGL::~GSDeviceOGL()’:
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:113:15: error: expected initializer before ‘:’ token
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:114:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:114:2: error: expected ‘;’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:114:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:114:2: error: expected ‘)’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:114:15: error: expected initializer before ‘:’ token
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:115:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:115:2: error: expected ‘;’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:115:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:115:2: error: expected ‘)’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:115:15: error: expected initializer before ‘:’ token
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:116:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:116:2: error: expected ‘;’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:116:2: error: expected primary-expression before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:116:2: error: expected ‘)’ before ‘for’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:116:15: error: expected initializer before ‘:’ token
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:117:13: error: could not convert ‘((GSDeviceOGL*)this)->GSDeviceOGL::m_vs.std::map<_Key, _Tp, _Compare, _Alloc>::clear [with _Key = unsigned int, _Tp = unsigned int, _Compare = std::less<unsigned int>, _Alloc = std::allocator<std::pair<const unsigned int, unsigned int> >]()’ to ‘bool’
/dave/gsdx-ogl/plugins/GSdx/GSDeviceOGL.cpp:118:14: error: expected ‘)’ before ‘;’ token
make[2]: *** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/GSDeviceOGL.cpp.o] Error 1
make[1]: *** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/all] Error 2
make: *** [all] Error 2
> Oh my gosh! Opengl is 20% faster than Dx!!!
I guest you did that in 10 seconds flat :P
Congrats on the 5000th revision and keep up this awesome work :)
It would appears on windows when it is finished on linux :) It don't appears on the ms build because it is a dev branch (actually I put linux only so people don't complain they can dl it on the build bot :p )
@rama, by the way where is the dev channel. I want my chocolates :p
snif, snif. I used a new nice c++11 feature. I guess your gcc version is tool old. I only test 4.6... That a shame but I will need to replace it. For the moment just remove line 113 to 116 on GSDeviceOGL.cpp.
Don't worry there still the r10000th.
I replace the bad code on r5002, if it can help you
Thanks, I'm already testing r5000 with those lines removed (yes, I have gcc 4.5).
Working alright, the hardware renderer is displaying only a black screen with sound (as expected) but I can see the framerate and cpu usage working on the title bar.
The software rendered (opengl) is working also.
The frame rate in hardware mode is aprox 45 fps while the software (opengl&sdl)mode gives about 20.
Yes nothings work :p I don't think it worth to compare the fps yet. I need to finish to implement some missing bits which will hurt the perf.
What kind of GPU do you have. If you have an nvidia gpu, can you
1/remove the Debug.txt file
2/Relaunch only the HW mode
3/Then copy/past the output of "sort -u Debug.txt"
If you have an amd gpu. Go to the church so they might fix their driver :p
No complains here :)
I imagine there is still a lot of work to be done.
Here is the output (yes, nvidia GPU):
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Good, very few issue.
Can you copy/past (from terminal) the compilation error of the shader.
Then it remains to find which gl call is deprecated...
Not sure what you need exactly, here is the whole output:
glX-Version 1.4 with Direct Rendering
convert.glsl (vs_main) :
convert.glsl (ps_main0) :
convert.glsl (ps_main1) :
convert.glsl (ps_main2) :
convert.glsl (ps_main3) :
convert.glsl (ps_main4) :
convert.glsl (ps_main5) :
convert.glsl (ps_main6) :
convert.glsl (ps_main7) :
Error opening plugins/merge.glsl: merge.glsl (ps_main0) :(0) : error C0000: syntax error, unexpected $end at token "<EOF>"
Error opening plugins/merge.glsl: merge.glsl (ps_main1) :(0) : error C0000: syntax error, unexpected $end at token "<EOF>"
interlace.glsl (ps_main0) :
interlace.glsl (ps_main1) :
interlace.glsl (ps_main2) :
interlace.glsl (ps_main3) :
fx.glsl (vs_main) :0(60) : error C3006: unknown modifier 'location' on out block
tfx.glsl (gs_main) :0(144) : error C3006: unknown modifier 'location' on in block
0(144) : error C1002: the name "GSin" is already defined at 0(144)
0(152) : error C3006: unknown modifier 'location' on out block
0(152) : error C1002: the name "GSout" is already defined at 0(152)
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
mfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (vs_main) :0(60) : error C3006: unknown modifier 'location' on out block
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (vs_main) :0(60) : error C3006: unknown modifier 'location' on out block
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (ps_main) :0(267) : error C3006: unknown modifier 'location' on in block
0(267) : error C1002: the name "PSin" is already defined at 0(267)
0(402) : error C7011: implicit cast from "int" to "bool"
perfect. Too much annoying issue :(
Which version of gl/glsl do you have? "glxinfo | grep version"
I'm afraid that I will need to split the interface in several element...
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
OpenGL version string: 4.2.0 NVIDIA 290.10
OpenGL shading language version string: 4.20 NVIDIA via Cg compiler
Ok. I commit a new version that will fix most of the glsl issue (I hope).
Note do a clean rebuild because I also fix the installation of the merge.glsl
congratulations on 5000
congratulations on r5000 [22

Revision 5001

i18n: add more fallback for some languages (thanks to pg)
cmake: implement the new XDG_STD options
It allow to move all pcsx2 data from $HOME/PCSX2 to $XDG_CONFIG_DIR/pcsx2.
Clearly a matter of personnal preference.
debian: drop the useless stable packet from the trunk. Only keep a copy on
branch release
Actually, the Sami fallback is incorrect.
There are Samis in Norway, Finland and Russia too,
people who more or less are unfamiliar with Swedish.
The correct entries would be:
And if you are up to it, please take a look at comment 72 & 73 in issue 915.
Sorry about the missing Patch-file.
I don't know how to make such.
Yes but my wxwidget don't support them. And I think it is the same of the ms version. Same for SORBIAN languages.
I'm not sure I understand what you want to do with the function. Albeit they seems similar, there are used in different place in the code and have different purpose. It works well so I prefer keep it like that.
If I understood things correctly "lang == wxLANGUAGE_SPANISH" in "i18n_IsLegacyLanguageId"
makes all versions of Spanish fallback on (regular) Spanish.
Well, the same thing could be applied to German, Italian, Portuguese and Swedish,
which would not only require fewer entries,
but would also support any possible new version of these languages,
whitout additional entries.
Portuguese requires this additional entry in "i18n_FallbackToAnotherLang":
which it already has.
Just a thought.
About the Chinese entries: They look wrong to me.
"lang == wxLANGUAGE_CHINESE" in "i18n_IsLegacyLanguageId" ought to wrack
the "_HONGKONG", "_MACAU" & "_SINGAPORE" entries in "i18n_FallbackToAnotherLang",
or else I have misunderstood how the "i18n_IsLegacyLanguageId" function works.
Can't investigate the matter any further since C#\C++ isn't my cup of tea.
About the missing support for some language platforms:
I don't know about Linux, but Windows & Visual Studios should support them:
I guess Linux will have to catch up.
I will need to look carefully. From the top of my mind. i18n_IsLegacyLanguageId removes some languages completely. For example wxLANGUAGE_SPANISH don't exist anymore, it was replaced by wxLANGUAGE_SPANISH_MODERN so instead to list both possibility on the language drop list, it would only add the second one.
Fallback change the default value. When you run the first time wizards, you can choose either your language or keep the default one (based on auto-detection). Your computer is portuguese. If no translation is provided, instead to keep english for the default language it will pick up brazilian. But you can still select some others languages or adds a portuguese translation without recompiling PCSX2.
I'm sure Chinese language is good because some chinese people ask me to do that :)
Actually linux is more recent than windows. But we deals with wxwidget not visual studio.
Nothing about Languages in the changelog for wxWidgets 2.9.3 (released 2011-12-14).
Hopefully, someone with influence will push them about this.
I have probably misunderstood "i18n_IsLegacyLanguageId" - period,
however, can you tell me this: Does all versions of Spanish fallback on (regular) Spanish?
Else, there is need for Spanish entries in "i18n_FallbackToAnotherLang" (if wxWidgets allow it):
Yes actually it was on 0.9.8 but I completely forgot to change 0.9.9. I saw it yesterday. And I think it need to fallback to spanish modern not spanish.
Actually, it would be nice if you added these comments for furure explorers:
// The correct fallback for Sami would be
// however, currently wxWidgets (2.9.3) only supports wxLANGUAGE_SAMI.
// Overkill 9000?
// Currently wxWidgets (2.9.3) doesn't support Sorbian.
Do not work "Tony_Hawks_Pro_Skater_4_USA_PS2"
Regarding the problem to all emulatoruw new verse
popszednia r4999 version, officially interpreted the "Tony_Hawks_Pro_Skater_4_USA_PS2"
I'm looking to improve this problem :)
Nie dzieła "Tony_Hawks_Pro_Skater_4_USA_PS2"
problem do tyczy wszystkich emulatoruw nowej wersi
popszednia wesja r4999 odczytywała "Tony_Hawks_Pro_Skater_4_USA_PS2"
czekam na poprawe tego problemu:)

Revision 5002

gsdx-ogl: LINUX-ONLY
Remove foreach feature not supported on old compiler
by the way, nothings work yet for the hardware renderer. It is only for debug
So, now we are dropping support for vs2008 as well? :D
I'll start using lambdas then!
Well I was too optimistic :) I think I would love c++ in 10 years :)
I'm currently looking to implement this function. GSDeviceOGL::CopyRect(GSTexture* st, GSTexture* dt, const GSVector4i& r)
I found that it is only called in GSTextureCache.cpp (around line 720). It copy the full data. Did the data need to be really duplicated? Perhaps you need a rendertarget on dx rather than a texture.
CopyRect is the faster version of drawing a quad, it does not need stretching and usually has a separate api call (d3d9: StretchRect, d3d10+: CopyRect). Only used for DATE when no stencil buffer is available, is that ever possible in opengl?
Did not see this one. Yes it is used for Date without stencil but it is also used in texturecache to create the source. Doing a copy on opengl is cumbersome. Opengl can uses both texture and render are render target. Texture contains an index and a data pack. So instead of copying the data, maybe I could swap the index. kindla a move instead of a copy. Well I think I would try to implement the copy and go back when it is working if I could replace with a move.
I see, that's where it finds textures among previous rendertargets and copies them. Copying is unavoidable, the size of the surfaces are different (ex. rt was 640x512 and the texture is 512x512). CopyRect is chosen there when no stretching is needed, otherwise StretchRect.
Ok thanks.

Revision 5003

gsdx-ogl: LINUX-ONLY
* rework a little the shader to be hopefully compatible with nvidia
* request a pure 4.2 context (all gpu 4.1 capable support 4.2 anyway)
Compiles OK but it crashes instantly at boot (Boot CDVD fast) when using OpenGL (hardware or software). SDL rendering is working.
I have only this in terminal:
The program 'pcsx2' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 19 error_code 8 request_code 136 minor_code 34)
I get a BadMatch error on startup as well. If I copy tfx.glsl from this revision into r5002, I get the following messages:
tfx.glsl (vs_main) :Vertex info
0(79) : warning C7050: "z" might be used before being initialized
tfx.glsl (gs_main) :
tfx.glsl (ps_main) :0(378) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (vs_main) :Vertex info
0(79) : warning C7050: "z" might be used before being initialized
tfx.glsl (ps_main) :0(378) : error C7011: implicit cast from "int" to "bool"
tfx.glsl (gs_main) :
tfx.glsl (ps_main) :0(378) : error C7011: implicit cast from "int" to "bool"
Crap I completely forgot, previous nvidi drivers didn't handle well 4.2 context. Can you try to restore a 4.1 context, just change the version in GSWnd.cpp (line 373) and comment the version test in GSDeviceOGL.cpp (line 189)
If I change the 2 to a 1 and rebuild, instead of a BadMatch error, I get the following:
glX-Version 1.4 with Direct Rendering
GSopen Failed: return code: 0xffffffff
It goes back to the r5002 behavior if I also revert lines 173-192 of GSDeviceOGL.cpp.
... So go back again on 4.1. It is not critical anyway, the only 4.2 feature I want is the guarantee that the mapping buffer is aligned for sse operations.
Ok I fix remaining issue on glsl in my environment.
The others issue I want to fix is this one (from dubigrasu report)
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Arcum, Do you have it too? It might depend on the game!
Yeah, I've got that. In fact, the beginning of my Debug.txt on hardware mode looks like this:
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. ClearBuffer: Cannot clear depth when target does not have depth bits.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Invalid <face>.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Invalid <face>.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Invalid <face>.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Invalid <face>.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
I was using Disgaea 1 to test, btw.
I test the game. I don't have same errors but I fix an important one on the back buffer management. Anyway I commit the fix with glsl and context fix.

Revision 5004

Fix Dynamic CRC hacks (got broken on r4991 )
Search and replace failed me? lol
Seems like it :)

Revision 5005

GSdx: Saving the conditional var update (vista or better) before I try a new
idea again. That Sync() call is wasting too much time, if there was only one
queue then the main thread could also grab and process elements instead of just
waiting for the workers.
Won't build for me with Visual C++ 2010 Express. r5004 builds fine without errors, but this one gives me 6 unresolved externals:
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>GSRasterizer.obj : error LNK2001: unresolved external symbol [email protected]
5>D:\pcsx2-svn\bin\plugins\GSdx32-SSSE3.dll : fatal error LNK1120: 6 unresolved externals
According to MSDN, kernel32.lib has these, which is an essential lib, every windows program links it. Very strange. Do you have 2010 SP1?
Vista is even older than 2010, might be another missing thing from the value edition of visual studio.
The express edition doesn't have any service packs, iirc
nvm, downloading SP1 as I type this. I'll post here if it fixes anything.
I tried a clean build on Visual C++ 2010 SP1, but it still has the unresolved externals.
I could load these functions dynimically, or you could get the full version of visual studio. Or just download it from http://buildbot.orphis.net/pcsx2/
I'll try using VS2008 tomorrow.
This is working great on my dual core.
I can now enter any number of extra threads and depending on the situation gain or loose a couple fps.
There's now always a number of threads where I get a couple more fps than with the old r4991 threading system :)
Deadlocks are also a thing of the past.
Compiling works on VS2008 Pro.
8 threads run quite smooth as well, but the fastest is at 6 on my 4 core with HT cpu. A real 6 core xeon or bulldozer could be even more interesting.
Most games are limited by pcsx2 now, I can only really test a few, like the intro of MGS3.
Btw, the GS % on title bar isn't looking right for some reason.
Well, if we could de-duplicate uploads to the GS, that would help :p
The GSdx plugin is no longer listed in the plugin selector. The PCSX2 program log indicates "File is not a valid dynamic library."
BTW, I'm using Windows XP Professional x64 and previous GSdx versions work just fine. Does this mean that from now on, this plugin only works in Vista or higher?
Oh noes, really? I might need to load these functions dynamically after all, thought a missing import can be only a link time error. Everyday you learn something new :D

Revision 5006

gsdx-ogl: LINUX-ONLY
* go back to opengl 4.1 (nvidia driver is buggy with 4.1).
* fix the backbuffer allocation. bad order of parameter
* fix remaining glsl error
All right, that takes care of the context creation with nvidia, and the glsl errors. Still a black screen, but I'm assuming it's supposed to be at this point.
Here's the latest Debug.txt:
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. ClearBuffer: Cannot clear depth when target does not have depth bits.
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. State(s) are invalid: primitive mode match.
(last error repeats over and over...)
Yes the black screen is expected. I did not finish to implement everything. It would be nearly finish when we got a picture :) Anyway, for the moment I want to smash as much as possible the easy (we have at least some error message) bug.
By the way, if you can find the origin of this error, it would help me.
Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
This one comes surely from GSDeviceOGL::ClearDepth
Message:GL_INVALID_ENUM error generated. ClearBuffer: Cannot clear depth when target does not have depth bits.
And could you check that the remaining one come from GSDeviceOGL::DrawPrimitive. I have a similar error, but I don't know if it linked to my driver bug or not.
Message:GL_INVALID_OPERATION error generated. State(s) are invalid: primitive mode match.
I miss the macro selector of shader. With luck it will fix some of nvidia errors :)

Revision 5007

GSdx: Moved filling up rendering threads on a new thread, to not block the main,
it looks like now I can replace one of the spin loops with an event. Using
events results in about -5% fps, but still pretty fast.
Still working okay here, much like the last revision.
I did loose a bit speed in Shadow of the Colossus though.
If you want to look at a really bad case of GS load, do you have Shadow Hearts 1?
That game really hates any threading, more than halving fps :p
i think it is time to do some optimization to the gsdx plugin and to the rest of the emu because no body have done some optimaze for more then 2-3 month.
Errr, ICO stopped working when I recompiled pcsx2. It was booting in r4942, the one I used until now.
Only a few changes to pcsx2 since then.
Try to disable your memory card 1. ICO also doesn't work for me when I have it "inserted".
Nope, Sony logo, then nothing. It's still working if I use the old exe.
Weird, I have the PAL version so I can't debug..
Just have to go back and find the last working revision... I'll do that later if no one beats me.
Checked Shadow Hearts, in the train after start, 120 fps in single-threaded mode, 100-110 with any number of threads. I think it just does not have enough to draw, very simple graphics. EE is also maxed out, not a very good subject to test GS speed. Is there any other place in the game where the difference is much bigger?
Nope, this is what I meant.
If you check the hardware renderer you'll see how much it has to work to even get around 60fps.
It's drawing the backgrounds in super small tiles, which I think is a pretty heavy GS load.
So the issue is there is too much thread management going on due to the volume of small GS writes? Maybe there needs to be buffer checks and fill up a work load before processing (assuming mainly the GIF processing queue)
What is difficult for one mode, easy for the other. Slowdowns usually aren't caused by the same reason.
But yes, threading has some overhead, it's really worth splitting the work when the games fill the whole screen with many things to draw, simple ones run fast enough already.
ramapcsx2: r4961 broke ICO, you did this! :D
I know why Shadow Hearts sucks so much, it repeatedly writes texture data at the same address, have to stop and wait each time for worker threads to release the texture.
Thanks for testing, Gabest.
I suppose yours is ICO NTSC then. Gotta find someone that has it for debugging the flag changes.
Heh, random trial and error shows that this is a timing problem.
I know I have the pal version of the game but I'm not too sure anymore that yours is NTSC.
Simply build a devel pcsx2 and set the pal framerate to be 60fps.
That fixes the problem I have, as I can now start the game with my memory card inserted.

Revision 5008

GSdx: Replaced condvar/srwlock imports with getprocaddress, it should work on XP
and compile on vs2010 express again.
Great, works with VC2010 express now. Thanks for fixing this :)
GSdx is indeed working again on XP Pro x64. Thanks gabest11!
where i can download .exe r5008 verison?

Revision 5009

gsdx-ogl: LINUX-ONLY
* implement offscreen and cache (mostly a copy past of dx)
* add the missing macro selector of the shader...
Looking good. When loading the same game in hardware mode, this was the entirety of the Debug.txt (None of the repeating errors are there):
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Cool. The first one come from glew. Not critical. Others are only performance issue, not important at the moment.
It remains the most difficult part, debug the whole stuff :)
Yeah I found that Debug.txt very encouraging. It's nice to know that the first line is because of glew, too...
And, of course, we can worry more about performance issues when it actually shows something other then a black window. ^_^

Revision 5010

GSdx: changes of r5007 did not help as much as I thought, disabled it for the
time being, plus other minor optimizations
Nice Great Work Guyz!
So many new Revisions can´t decide now wich one i wan´t to try(have r4940 right now!) and i have a AMD Phenom II x6 1090T CPU and Windows 7 64bit, wich revision could you recommend?
shall i try this revision or should i wait a little longer?
You should usually try the latest revision which usually includes all previous modifications (except for few cases, such as this revision, which reverts some functionality because it wasn't as good as it was hoped).
Software mode causes screen artifacts in Valkyrie Profile Silmeria. There's screen flicker and spiky shadows on the main character Alicia when in town. Previous revision (r5008) doesn't have this problem even though it's slightly slower than this revision. Hardware mode seems to be fine though.
Does it depend on how many threads use set?
Bully also flickers :'(
since r5005, r4999 ok
Yes, it does depend on the number of extra threads. Screen flickering and spiky shadows still present in r5012 when extra threads is 1 or higher.

Revision 5011

GSdx: Hack around a problem with the texture cache finding depth stencils when
there can't be any.
This makes the Arc the Lad fog issue go away.
Review would be nice though :)
Just tested it. Works great at least up until after the fighting cutscene. Will look into it more later after I mess with cd-rom drive and it stops making this awful grinding noise.

Revision 5012

GSdx: This fixes the flickering in Bully, and probably games with the same
problem. Could not check Valkyrie Profile Silmeria, yet.
The fix isn't perfect, overlapping frame and z writes should be checked as well, not just their base address.
The screen artifacts in Valkyrie Profile Silmeria which started in r5010 are unfortunately still present in this revision. Setting extra rendering threads to 0 gets rid of the problem but with severe performance hit. The problem shows up when it's set to 1 or higher.
I just tried it on my laptop computer which has Windows 7, and the artifacts don't occur even with extra threads > 0. Perhaps it only occurs in XP?
Found it, both were bogus, xp just uses slower threads syncronization and the problem surfaced easier. I was counting page references wrong, it underflow sometimes below 0.
was this flickering in particular a new issue, or is it the one related to skipdraw?

Revision 5013

Linux-only: Removed a few obsolete files. Copied in a build script to make
rebuilding the project a bit easier.
Actually, I see a mistake in the build script, so I'll fix that...
Good idea.
The music I've been listening to for this commit, incidentally, was "Wild Arms: ARMed and DANGerous". Great stuff.
Thanks. The bug is in the "clean" keyword, incidentally. It works, but the code for it is wrong...
For anyone that wants to use this build file, first of all, keep in mind that it's experimental. However, running "./build.sh" will build pcsx2 with all the default options, using a build folder it creates, and will create an install_log.txt file in the root directory, logging any warnings and errors during the build.
Parameters you can pass it include:
debug - for a debug build
dev - for a development build
release - for a release build
gsdx - turns on the internal sdl 1.3, to enable gsdx to compile
clean - causes it to rebuild pcsx2 + plugins from scratch, instead of just the changes
I mainly did this for my own use, as I end up rebuilding pcsx2 a lot. ^_^

Revision 5014

Linux-only: Quick fix to the last commit.
It's always the little things. The mistake I made on the if statement worked anyways because I messed up and declared the vaziable with a different name then I used in the rest of the script.
Hmm... If I think about it, I should change it from bash to sh. I don't think I did anything bash-specific...

Revision 5015

GSdx: Valkyrie Profile 2 fix (discussed under r5010 and r5012), this bug could
have broken much more games, strange that it did not.
I checked Grandia Xtreme with these changes just to see if it would fix the flickering and it doesn't seem to change anything. The opening title screens/video seems to play without flickering, but the game itself still flickers (in fact I think it looks worse in software rendering). Changing threads doesn't seem to make it much better either. So I'm guessing that the flickering issue that was in Bully was different. :\
Oh well, nice fixes though.
I have the normal ff12 from every region and the demo, but not the international, fmv 60+, intro around 90 fps, EE is maxed in both cases.
A left-over r5005 build was also in the plugins dir, tried it and same speed. Is the internation that different? Have to go "shopping" again.
Yes FFXII IZJS fmv´s are slower now than before...
Please fix naruto ultimate ninja 4: Shadows of characters show only in software mode...
Dragon Quest VIII: software mode show more graphics than hardware
Valkyrie Profile Silmeria is back to its splendid GSdx glory, thanks gabest!
As for FFXII IZJS, like gabest I'm not getting the slowdown at all compared to the US version. With frame limit off I'm getting around 125 fps in the opening fmv in both versions with hardware and software rendering. I tried both the untouched ISO and the English-patched one for the IZJS version. I'll try it later on my much slower laptop to see if there's any performance difference there.
I just tried FFXII IZJS on my slow laptop and the opening fmv runs at the same speed as the US version. It also runs at the same speed compared to GSdx r5010, around 55-60 fps.
Wrong hum
something ain't right
i just tested US (NOT IZJS)release and result is confusing
test conducted in main menu of "new game" where u choose config:
SW r5015:
fps 45,EE 18%,GS 100%,VU 1-10%
SW r4980:
fps 98,EE 34%,GS 93%, VU 7-10%
results say for it self?
And i switched to IZSJ release and tested same thing over with that one
it shows the same results SW got busted with fps double down
I am sorry for damn spam of posts :S
To summary :
FPS result doesn't make any difference during actual video sequence in either version of the game or svn build.But in that "menu" difference is massive.
CPU? threads?
sorry i was doing some extra testing
gsdx ini : swthreads=4
on Phenom x4 965 3.4ghz
i also traced that fps thing all the way beck to r4992
so,sorry this change has nothing to do with it.
r4992 is worst with fps then rev after rev since then it gets more stable up to 50fps but far from 100fps from r4991
What are the fps numbers with 0, 1, 2, 3, 4 threads? Are you on XP or Vista/Win7?
OK MY BAD forget all of this above SORRY
since this new business of SW new line in gsdx is added "extrathreads"
and before was "swthreads"
once i putted extrathreads=3 instead of 0 speed jumped up to 115 fps compared to old revision 95 fps
Its clearly my misinformation and i apologize
oh, you are editing the ini file :D
I had to change the name of this setting, 0 is the old 1, already saved values were not compatible.
i understand now.Sorry for that.
At end conclusion is Very Good A- :P go sit ;-)) joke ;-)
Speed in fps jumped by 15 in that menu then before
strange thing is that actual video of game has no difference in ammount of threads used.be it extra 0 or extra 3+ only in that menu.
But either-way very good job!
He was just changing the old ineffective threading options, while the gui would have saved it under a new name.
yeah just deleted old "swthreads" line in gsdx ini and edited new line extrathreads=0 to be extrathreads=3
speed is now 115fps compared to old 95fps.but as i said no speed changes during video,just in menu.

Revision 5016

GSdx: a little refinement to the fix for the issue that come up with Bully.

Revision 5017

* fix the new extra thread option in the gui dialog
* implement condition variable on linux. Will need some benchmark.
Note it was on the linux gui too

Revision 5018

GSdx: Improved Genji CRC hack.
What change for the CRC hack?
It also fixes the graphics when the character dies.

Revision 5019

GSdx: a few minor changes, please check if I wrapped the new pthread things
EE: 100%, pcsx2 really needs a new wizard.
falcon recently found a wizard in terraria *endjoke*
gabest, (unrelated to this commit), do you think you could add a pixel-shader based deinterlacer? first step maybe as half frame rate, and then possibly full frame rate? maybe also dll based deinterlacer (similar to the way ffdshow accepts dscaler deinterlace dlls). Afterall, our only proper deinterlace right now is bob, but there are better deinterlacers out there.
Software renderer causes crash to desktop starting with this revision under Windows XP x64. It works fine in GSdx r5018 and earlier. Hardware renderer still works fine though, only software renderer is affected.

Revision 5020

gsdx linux:
* use memory instead of tr1 (was the experimental implementation of c++11)
* remove strict aliasing optimization because I saw some bad warnings
* Fix pthread of the previous commit. Use default attribute but it might need
some tuning

Revision 5021

gsdx linux:
* add the code to select the attribute (still the default but can be changed
* add a hidden option (condvar) to select between the 2 threads algorithm

Revision 5022

gsdx-ogl: merge from trunk (4990:5021)

Revision 5023

portaudio: Updated codebase from svn 1748 to svn 1802.
Notable changes:
- Changes to buffer size calculations and latency calculations.
Not a big update, just wanted to commit something before the year ended!

Revision 5024

<avih> hmm.. this is wrong(-ish). I've updated portaudio, but spu2x still shows
as version r4949 ... can this be fixed? or maybe i didn't compile it properly?
<avih> so, come on, touch spu2x to have recent rev number
Touched... hopefully I touched right. Felt awkward.

Revision 5025

@gigahertz: some sensitivity is required when touching a small plugin! Let's
hope I got it right :)
I did say it felt awkward. See, I was doing it wrong.
Yea, whatever you say :p
ROFL at rev 5024 and this revision =)) =)) =)) - the "plugin" just got a little *bigger* ; +10 for these 2 revisions.

Revision 5026

GSdx: bit less idle time by refcouting used texture pages.
Hey Gabest, could you look at VS2008 as well? :p
2>D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\xhash(200) : error C2039: 'min_buckets': Ist kein Element von 'stdext::hash_compare<uint64>'
2> g:\pcsx2_trunk\plugins\gsdx\stdafx.h(154): Siehe Deklaration von 'stdext::hash_compare<uint64>'
2> D:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\hash_map(88): Siehe Verweis auf die Instanziierung der gerade kompilierten Klassen-template "stdext::_Hash<_Traits>".
2> with
2> [
2> _Traits=stdext::_Hmap_traits<uint64,std::list<uint32> ,stdext::hash_compare<uint64>,std::allocator<std::pair<const uint64,std::list<uint32> >>,false>
2> ]
2> g:\pcsx2_trunk\plugins\gsdx\GSLocalMemory.h(33): Siehe Verweis auf die Instanziierung der gerade kompilierten Klassen-template "stdext::hash_map<_Kty,_Ty>".
2> with
2> [
2> _Kty=uint64,
2> _Ty=std::list<uint32> *
2> ]

Revision 5027

GSdx: vs2008 fix
I just use the default values for bucket_size and min_buckets, dunno what they do :D
Thanks :)
Thanks works better. :)

Revision 5028

GSdx: GSOffset::GetPages was caching a ridiculous amount of data, it isn't that
much slower without it.
Hmm, any statistics what changed and where it mattered maybe? :p
I checked how many list<uint32> was allocated and it reached 10000 after just moving around a bit in any game. It cached the contained page numbers of every "base pointer + rectange" it was asked for.

Revision 5029

GUI: Exclude Turbo/SlowMo factors from the presets. (Now can keep custom
turbo/slowmo speeds while still using the presets)
Good Idea!

Revision 5030

gsdx-ogl: LINUX-ONLY
* fix vertex shader for HW renderer :) Remains the fragment part...
* add some dumping infrastucture (DUMP_START and DUMP_LENGTH)

Revision 5031

gsdx-ogl: LINUX-ONLY
* It works with the HW renderer !!!
* Not sure this fix will work with dual blending but we will see later
* screen is vertically flipped again...
Note: I get the logo startup of fahrenheit. There are still lots of bug.
Nice work. Needs a lot of fixes (every iso I tried was majorly glitched besides the flipped screen, and one crashed), but the fact that it's actually rendering now is great...
Yes. It is a big step forward :)
I found a solution to workaround my AMD driver bug so I will be able to debug more. Actually I think there is a (few) major issue(s) rather than plenty of small one. Hum, I need to double check that the color send to shader are correct and properly converted.
I made anothers big step forward. I found anothers driver bug, could you test latest revision and tell me on nvidia. I expect that 2D rendering to work now. I got a crash on colin mcrae rally3/disgaea but we are nearly in game.

Revision 5032

Added a workaround for the savestate freeze bug in Gust games when the MTVU
speedhack is active.
Aligning GIF packets on state save actions seems to cause some issues with the
Still hope to find a better solution.
This could fix other games that have a chance of freezing when saving a state with mtvu enabled.
Yea, I'm sure it happened in other games as well.
Gust games are simply triggering it reliably, probably has to do with them filling the mtgs ring buffer so quickly.
Also it happpened by me in r5011, in the Game Final Fantasy XII(PAL EUR Version), after i saved too much, and one time in Suikoden Tactics(PAL EUR), but i was thinking it was my HD(it was making a strange noise, while saving)
If i try this Revision are the Savestates compatible whit this?

Revision 5033

gsdx-ogl: LINUX-ONLY
* Fix the Geomtry shader to output 2 triangles for quad primitive (ie 2R
- There is an AMD driver bug on geomtry shader input interface (well could be
the spec too). Tell me if it still working on nvidia
* Add a workaroung to a previous AMD bug. It is impossible to unattach a shader
so destroy the full shader pipeline...
* Be more strict on FBO management. Would optimize it later
* use a texture insted of a render buffer for depth-stencil management.
* add more dumping capabilities (in particular depth buffer)
Haven't tested the previous release.
This one gives me only a black screen if starting a game (any game) with one exception; on Rogue Ops I can see the progress bar loading (good quality image but smaller) and after that the screen gets black again.
If started without a disc I can see the Playstation menu in black and white (more white actually, the image is very faint)
In console I get messages like:
glX-Version 1.4 with Direct Rendering
convert.glsl (entry vs_main, prog 1) :
convert.glsl (entry ps_main0, prog 2) :
merge.glsl (entry ps_main0, prog 10) :
merge.glsl (entry ps_main1, prog 11) :
interlace.glsl (entry ps_main0, prog 12) :
interlace.glsl (entry ps_main1, prog 13) :
fx.glsl (entry vs_main, prog 16) :
#define VS_BPPZ 0
#define VS_TME 0
#define VS_FST 0
#define VS_RTCOPY 0
tfx.glsl (entry gs_main, prog 17) :
#define GS_IIP 0
#define GS_PRIM 3
tfx.glsl (entry ps_main, prog 18) :
#define PS_FST 0
#define PS_WMS 0
#define PS_WMT 0
#define PS_FMT 0
#define PS_AEM 0
#define PS_TFX 4
#define PS_TCC 0
#define PS_ATST 1
#define PS_FOG 0
#define PS_CLR1 0
#define PS_FBA 0
#define PS_AOUT 1
#define PS_LTF 0
#define PS_COLCLIP 0
#define PS_DATE 0
and in debug text:
Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
Log is correct. I bet there is somethings wrong with the geometry shader.
Could you try
1/ restore the proper location of attribut
file plugins/GSdx/res/tfx.glsl line :138
Replace "in vertex GSin[];"
By "layout(location = 0) in vertex GSin[];"
2/ replace all occurence of GSin by OUT
3/ Both 1&2 in the same time
Note: You can revert your change with svn revert
Tried all three variants but no change.
What game do you have? FFX? colin mcrae rally 3? disgaea 1? It would be easier to test on the same game.
Current status is game menu must more or less be accurate (it miss sometimes some elements). And I have various crashes (too much) that will be a nighmare to debug.
Meh...none of those above.
Not many games I'm afraid...God of war 1&2, Soul Reaver2, Silent Hill2, Constantine, Ico, MOH European Assault, Tomb Raider Legend, Rogue Ops and a bunch of other discs scratched beyond recovery.
Good, soul reaver2 I have the pal (multi5). Except the crash I have the menu and start video :) Could you try this one with the previous fix.
Gow does not work only a black screen :p Oh my gosh it use lots of different shaders, too much 3d on the menu. It would be a good testcase when I fixed all those crashes...
Definitely an improvement over the last one, though everything is still glitchy. To give you an idea of the sort of issues I'm seeing, here's a few screenshots:
Dark Cloud opening screen in software mode (Which is what it should look like):
Dark Cloud in hardware mode:
Mana Khemia in software mode:
Mana Khemia in hardware mode:
Disgaea 1 in hardware mode:
But then, I think you have that one...
Wait a sec...
Try this patch:
Index: plugins/GSdx/res/tfx.glsl
--- plugins/GSdx/res/tfx.glsl (revision 5033)
+++ plugins/GSdx/res/tfx.glsl (working copy)
@@ -619,7 +619,8 @@
// FIXME: I'm not sure about the value of others field
// output.c1 = c.a * 2; // used for alpha blending
- SV_Target0 = vec4(c.a*2, c.a*2, c.a*2, c.a * 2);
+ //SV_Target0 = vec4(c.a*2, c.a*2, c.a*2, c.a * 2);
+ SV_Target0 = vec4(c.r*2, c.g*2, c.b*2, c.a * 2);
if(PS_AOUT != 0) // 16 bit output
Much better...
Hum, could you try instead to swap SV_Target0 and SV_Target1?
By the way, I cannot boot mana khemia, it crash. Maybe because it is the PAL version.
Looks like swapping SV_Target0 and SV_Target1 in that function works as well.
And actually, if I try to go past that screen in mana khemia, it crashes in hardware mode (In IASetVertexBuffer), but works in software mode. I just figured we'd tackle one bug at a time...
It must work better :) because you don't need the factor 2. There are 2 index for dual source blending. One index (logically 1) is used as a coeff for the blending. And the others is the real ouput. In those basic case there is probably no blending. It seems the normal color is 1 for amd and 0 for nvidia....
can you start a game on disgaea or does it crashes. I think I will need to reboot my computer.
Ah yes, I completey forgot it. Actually the mapping of the buffer failed for whatever the reason but the dst pointer is null. I add a test on local to return, the function but it probably crash later because there is nothing to draw face palm...
If you have a 32bits environment, you can try to build/install apitrace (it is an opengl debugger). I would need to install it I have a complete mess of my 32bits compatibility libs.
By the way, I'm trying to connect on irc from time to time. I feel it would be easier to communicate.
I'm able to start a new game on Disgaea. There are some graphic artifacts, but it seems to work.
And other Gust games crash at startup, too, in hardware mode. It's right at the point that Gust does something funky that we've had crashes related to in pcsx2 in the past, IIRC.
And given that I'm testing in a separate 32-bit Lubuntu environment that I set up just for testing, I should be able to install apitrace. (If I can find it in the repositories, anyways...)
(I don't think I actually have an irc client even installed in this environment, incidentally. I've never been much for IRC...)
it is on github:
I think you need todo "git clone git://github.com/apitrace/apitrace.git"
Nah, since this is Lubuntu, I added this ppa to my repositories:
It's installed now.
Just looking over the docs a bit. If I run "apitrace trace ./pcsx2-dev", it seems to spam "apitrace: warning: unknown buffer target 0x8A11" over and over while running, regardless of the game I run.
I am, however, able to generate trace files...
don't worry for the error. I don't think it is important. Normally you can replay the trace
then you can lookup to have the full detail of texture/framebuffer/shader or whatever.
For the blending can you test something, swap the index definition line 260 instead of swaping SV_Target0 and SV_Target1. Don't ask me why but that different on my computer.
All right, I set lines 260 and 261 to:
layout(location = 0, index = 1) out vec4 SV_Target0;
layout(location = 0, index = 0) out vec4 SV_Target1;
And reverted my other changes. Still seems to be working properly. (Testing using Disgaea at the moment.)
Ok. I try various others way. The behavior is black magic! I'm sure it will fall at the next cross-road...
I commit the change for the fragment shader. I also add a check on dst (mana khemia), hopefully it would print some error in Debug.txt. On my side I have a memory corruption somewhere and it crash before.
I'll check that. Incidentally, replaying the trace file I generated earlier fails with this error:
[email protected]:/usr/local/src/pcsx2-ogl/bin$ glretrace pcsx2-dev.trace
2244 glMapBufferRange(target = GL_ARRAY_BUFFER, offset = 0, length = 64, access = GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_RANGE_BIT | GL_MAP_UNSYNCHRONIZED_BIT) = 0xa0029400
2244: warning: failed to map buffer
warning: could not translate address 0xa0029400
Segmentation fault
I got similar error. It seems it was not 64/32 bits issue.
It might worth to test without optimization flags GL_MAP_INVALIDATE_* and GL_MAP_UNSYNCHRONIZED_BIT. On my side, my crash seem related to GSTextureOGL::Update if I return without doing anythings I don't have any memory corruption !

Revision 5034

gsdx-ogl: LINUX-ONLY
* invert the index of fragment output. Seem to work better on Nvidia (strangely
no impact for AMD)
* opengl support pitch too, so remove useless copy to an fbo
That works for me, though we'll really want to figure out why the index makes a difference at some point...
Oh, I'm going to have to check on a clean build, but it looks like Mana Khemia no longer crashes on this build. Instead, it now spams "CRITICAL ERROR map failed for vb !!!" a bunch at the point it would have crashed, but keeps working after that, and stops spamming after a minute.
Yes it just bypass the upload of vertex which is not a good idea.
I don't find any reason why suddently it cannot map the buffer. Maybe I will implement 2 algoriths glmapbuffer (current) and glbuffersubdata (new one). Maybe the 2nd one will work, we never know with opengl ;)
I have some concern with the texture upload which lead to a memory corruption. Oh well, I'm going to sleep. Good luck ;)
I did figure out something. (For when you get up tomorrow, anyways...)
In the upload function, if you do the following:
GLint size;
glGetBufferParameteriv(GL_ARRAY_BUFFER, GL_BUFFER_SIZE, &size);
In the cases where it is failing, size is smaller then stride*start + stride*count. (640 or 16, where it was usually 1920000).
And per the manual, for glMapBufferRange, GL_INVALID_VALUE is generated if either of offset or length is negative, or if offset + length is greater than the value of GL_BUFFER_SIZE...
So for a workaround for the moment, this works:
void upload(const void* src, uint32 flags)
GLint size;
glGetBufferParameteriv(GL_ARRAY_BUFFER, GL_BUFFER_SIZE, &size);
uint8* dst = NULL;
if (size >= stride*start + stride*count)
dst = (uint8*) glMapBufferRange(GL_ARRAY_BUFFER, stride*start, stride*count, flags);
#ifdef OGL_DEBUG
if (dst == NULL) {
fprintf(stderr, "CRITICAL ERROR map failed for vb !!!\n");
memcpy(dst, src, stride*count);
Not sure it's the right behavior, though. I was a bit amused to see some of the same glitches I've seen on this game repeatedly in zzogl appear. :)
Actually, there's a copy and paste error there. Remove the CheckDebugLog() from that function. I'm playing with it a bit more right now, though.
Something is happening :)
This time I get a perfect PS2 boot screen and following menus, settings etc:
Medal of Honor menus and in game movies are almost perfect:
Actual game however:
Soul Reaver2 seems to work very well:
In game movie:
That's a very nice start for this plugin! :)
Good idea. There is a buffer corruption somewhere. Or I didnot recreate correctly the buffer.
Here a trace:
start 3832 size 6, max_size 60000 (stride 32). Buffer size 1920000 on id 2,6
start 5344 size 4, max_size 60000 (stride 32). Buffer size 1920000 on id 1,1
start 5348 size 4, max_size 60000 (stride 32). Buffer size 1920000 on id 1,1
start 3838 size 2, max_size 60000 (stride 32). Buffer size 1920000 on id 2,6
start 5352 size 4, max_size 60000 (stride 32). Buffer size -217060512 on id 1,1
CRITICAL ERROR map failed for vb !!!
I see anothers CRITICAL issue. All my trace seems to have a stride of 32. Id represents the opengl ID of the buffers. One for the HW renderer and one for the 2D resizer.
Thanks dubigrasu. When we fix the instability issue, I'm sure some games will be nearly playable.
Hum actually both vertex object are 32bytes. Gabest probably aligned them for performance. It might be possible to reduce the code a little but that not the issue :(
Hum I have a hint:
If you comment s_gs->ReadFIFO(mem, size); in GSreadFIFO2, it will go further.
That strange it failed to get value of the size from this call. Maybe it is called from anothers thread.
I got my answer from gdb.... GSopen -> MTGS but GSreadFIFO2 -> EE Core
The function is barely used so for the moment we will disable it until we found a better solution. I don't know if it the same for GSreadFIFO1?
Now I need to find why the uploading of texture crash on amd and seem to be fine on your side.
I commit a workaround that bypass FIFO2 for the moment. With luck it would make mana khemia playable on nvidia.
Just as a point, not all the fifo2 calls are causing the "CRITICAL ERROR map failed for vb !!!" errors. I just did a bit of testing, and there are a bunch right after that that go through...
Hum that possible. I admit is a bit overkill, but any gl command will cause some troubles.
GL context is only defined by threads. There is no context in the EE core thread so you cannot use any gl command.
Playing around with it, I re-enabled fifo, and added this to the start of upload:
GLint b_size = -1;
glGetBufferParameteriv(m_target, GL_BUFFER_SIZE, &b_size);
if (b_size <= 0)
The times when it can't use a gl command, b_size stays at -1. ^_^
That a clever trick. Where did you add it exactly in GSFIFO2 ? Is it sometimes valid (ie size > 0)?
Arcum, do you have a frequency (50Hz vs 60Hz) selection at the start of mana khemia? It migh be limited to the PAL version.
See http://imageshack.us/photo/my-images/39/manakhemiastart.png/
To render the letter, a texture with only alpha channel is uploaded. Letter are opaque. On my side I have a big rectangle with the "letter color". The blending equation is "Blend op: ADD; src:SRC1 ALPHA; dst:1 - SRC1 ALPHA". So we can conclude there is something wrong with the blending but I don't know if my opengl implementation is bad or if AMD driver is buggy ! I wouldn't be surprised of the later.
In my latest commit, I add a (not defined) define to disable dual souce blending and the letters are good albeit darker (because of some factor 2). Anyway it confirms the issue with blending stuff.
I don't have a frequency selection on Mana Khemia. All but one or two of my games are the US versions...
Ok, I will try to create a dump.

Revision 5035

GSdx-ogl: happy new years commit :)
* move all vertex buffer stuff into the class
* Bypass FIFO2 because of multithread issue with OGL(temporary workaround until
we found a nicer solutions)
Have you tried serializing the two reads with GSCritSec?
No. It is not an issue with thread safety. Opengl context is local to a thread so I cannot access it from another thread. I could create a 2nd context in EEcore and share data between them but I don't think it could be done easily (too much to share). I will need to learn more about opengl multithreading capabilities.
Latest opengl gets an interesting extension:
This extension provides GLSL built-in functions allowing shaders to load from, store to, and perform atomic read-modify-write operations to a texture object from any shader stage.
On opengl texture are both input and output (render target) of shaders. If I understand correctly. This extensions would allow
1/ compute blending within the fragment shader. It might be possible to fix some ps2 blending factor (aka 1+...)
2/ manually implement the z buffer in the fragment shader. In others word, transmit the full integer 32bits from the vertex shader to the fragment shader and store the z value into a 32 integer texture.
I think you have somethings similar in DX11. Did you have any reason to not using it? performance impact?
In order to read the render target texture inside a pixel shader you need to have it set as an input buffer to the shader, but that is not possible, the dx11 runtime notices it and tells you that it has forcefully unbound it (if you are using the debug runtimes). In a compute shader you can do that, it just does not have anything to interpolate a triangle. If this extension is like the mixture of a pixel and compute shader then it looks promising. There are numerous GS features that need r/w access to target buffer because the default ROP cannot do them. Alpha bending, destination alpha test, writing color components bitmasked or the msb set (FBA), even swizzling could be implemented if you could control where to write and what.
I will need to carefully understand this extension, there are maybe some limitations (could be same as DX) but that look very interesting ;) There is clearly a trend to mix compute and rendering.

Revision 5036

GSdx: Small optimizations here and there, just saving changes before trying to
add an index buffer, that might help reducing load on the main gs thread a bit.
That's where I think the bottleneck currently is in games with high polygon
Is it game like GTA VC stories ?
Gabest, tell me if there is something new to put in the plugins for those using openGL 3.3? Something that improves perfoance, I have not seen in a while constructive for this version of openGL
It isn't me who you need to ask about opengl, don't know much about its versions.
gl 2.1 = DX9, gl3.x = DX10 and gl4.x = DX11.
willianholtz1, can you give me the output of glxinfo? I need the start with all GL/GLX extensions. You could drop array of GLX visual at the end. Thank you.
I'm not sure I understand your question. When the OGL4 port is ready and reliable (some games become playable), I will probrably plan to support ogl3. Key of dev is "divide and conquer" ;)
That's right. :)
I think it would be better to view.
NVIDIA-Settings -g
willianholtz1, can you test revision r5041. With luck it will work with your GPU. SW mode must be OK. HW is not yet finish, but start to menu must work for most games.
I know my old computer in itself is most definitly or highly likely to be a bottleneck to anything lol.
(Pentium 4 3.2GHZ Extreme
Geforce 6600 256MB AGP card...
use to be a 7950 512MB geforce but that bit the dust)
like i said old so i dont expect much out of it and looking to save up for a decent new rig...
But could this future update 'the index buffer' potentially help out older computers to run games more efficently through PCSX2.
Post: #3348
bit of an issue from most likely this commit
Nah ref, as I told him in the thread: This glitch has always been there :p
mkay ;p

Revision 5037

Get rid of some irritating warnings in Linux.
Just a workaround for some behavior that was causing a few warnings to pop up any time the iso list was recreated. I think it was trying to add a radio menu item to a group of radio menu items that no longer existed, and the line I added is making it start a new radio group...

Revision 5038

* Use a geometry shader pass-through to replace previous AMD workaround
* various cosmetic change

Revision 5039

* replace hexa debug value with nice string for standard human
* move things around
Crap, I forgot to remove the dumping of some draw command. Oh well, it would only fill your /tmp directory ;)
Remove those define at startup of GSDeviceOGL.cpp:
#define DUMP_START (70)
#define DUMP_LENGTH (130)

Revision 5040

* add a new define (DISABLE_DUAL_BLEND) to easily test blend mode

Revision 5041

gsdx-ogl: code seems compatible with an opengl 3.3 context. Only load some
shader extensions.
you are the man!
Does it really work? My GPU/drivers is 4.2 so I cannot test it.
Actually I saw your code and found it interesting, but the compile and test this message appeared
GLX-Version 1.4 with Direct Rendering
GL_ARB_shading_language_420pack is not supported
That annoying! From you previous report is must be supported. Which version of libglew do you have? Can you try to upgrade it to 1.7?
Otherwise remove line 218 from GSDeviceOGL.cpp.
Only one thing, I deleted the line 218 of GSDeviceOGL.cpp. In entando OpenGL hardware, it is all black with the image, but I can hear the sounds and something when I press the buttons.
In any case:
well nothings work :p That strange it work on Arcum GPU. We will need to fix all the shader errors.
I get the same error as above:
"GLX-Version 1.4 with Direct Rendering
GL_ARB_shading_language_420pack is not supported"
and the emu hangs just right there.
I do have glew 1.7.0.
Removing line 128 doesn't change a thing, same message and hangs.
Debug text is not created.
All right, with this revision, I have to remove line 218, as above. There's obvious missing graphics, but I still have my hack from earlier in, so that could be related. I did get a few errors when running:
tfx.glsl (entry vs_main, prog 17) :
<...snip defines...>
0(86) : error C7011: implicit cast from "int" to "uint"
0(88) : error C7011: implicit cast from "int" to "uint"
tfx.glsl (entry gs_main, prog 18) :
<...snip defines...>
tfx.glsl (entry ps_main, prog 19) :
<...snip defines...>
0(335) : error C7011: implicit cast from "ivec4" to "uvec4"
0(346) : error C7011: implicit cast from "ivec2" to "uvec2"
0(354) : error C7011: implicit cast from "ivec2" to "uvec2"
The latter three mentioned are lines 315, 324, and 334 in tfx.glsl. I'm assuming they have to do with uv_out being a vec4 and MskFix being a uvec4.
The first two errors are from setting z at the beginning of vs_main. Substituting the following gets rid of them:
uint z;
if(VS_BPPZ == 1) // 24
z = i_z & uint(0xffffff);
else if(VS_BPPZ == 2) // 16
z = i_z & uint(0xffff);
z = i_z;
dubigrasu, what give you "glxinfo | grep 420pack"
Are you sure to have properly remove the line (218, 128 is a typo). I find it strange that you have a different behavior that willianholtz1.
Revert my change in GSWnd.cpp to restore a 4.1 context. Maybe you can try a 4.0 context too.
Lines 315, 324, and 334 just need MskFix cast to be signed.
Arcum, I assume GLSL 3.3 is a bit more cumbersome than GLSL 4 on nvidia. On the missing graphics. Don't know why the extension check doesn't work!
1/ error on shader are critical because it won't draw anythings. If you change back the GLSL version to 4.2 you can probably test it.
2/ could be related to blending
3/ maybe the fifo2 hack. There is some possibility here: http://www.opengl.org/wiki/OpenGL_and_multithreading
I think we will to unattach and reattach the context. Maybe it could work without detaching the context on GS thread. I think PCSX2 have some guarantee to never run both FIFO and gs thread in the same time.
4/ others bugs :) God of wars menu is still black screen. So there are still bugs.
Arghhh, crap.
I apologize Gregory. I did removed the line 128, not 218 :(
Let me try again.
By the way, feel free to commit GLSL fix :) And the removal of line 218, if the driver don't support glsl420 it would only print error on the shader compilation.
Committed. I left in the code I'd been playing with for the fifo hack as well. We can always revert that later if need be.
Left in printing a value I'd had in there for testing accidentally, too. Oh well...
Good. I thinks willianholtz1 have additional issue on convert. Do you have them too?
0(119) : error C7011: implicit cast from "int" to "uint"
0(119) : error C7011: implicit cast from "int" to "uint"
0(119) : error C7011: implicit cast from "int" to "uint"
0(119) : error C7011: implicit cast from "int" to "uint"
0(144) : error C7011: implicit cast from "int" to "uint"
0(144) : error C7011: implicit cast from "int" to "uint"
I think it would be a good idea to keep FIXME, TODO, OGL_DEBUG defined near hack. So we could grep them later. glget* command could be very slow.
Anyway, did it fix the missing element, maybe you can try to disable dual blending.
Oh, yeah, I missed those. I'll look at them.
And having FIXME or something similar by it would be a good idea. We obviously don't want to forget about it...
OK. tried again with line 218 removed.
PCSX is starting but only with a black screen. I can hear the sound though.
The console output: http://www.text-upload.com/read.php?t=8603
Debug text:
"Type:Error ID:1280 Severity:High Message:GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. State(s) are invalid: program pipeline config.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. <program> object is not successfully linked, or is not a program object.
Type:Error ID:1282 Severity:High Message:GL_INVALID_OPERATION error generated. State(s) are invalid: program pipeline config.
Type:Performance ID:131218 Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches."
glxinfo | grep 420pack
GL_ARB_shading_language_100, GL_ARB_shading_language_420pack,
This is without touching GSWnd.cpp yet, I'll do it next.
dubigrasu, please use next revision. If fix lots of things and probably the black screen issue :)
I committed one more revision, to take care of the other glsl errors. It's the same thing each time, pretty much, so it's easy to spot.
I'll try the last revision of course, but just for the heck of it I changed from 3.3 to 4.1. with no result (black screen).
On to 5043 now.

Revision 5042

gsdx-ogl: Fix a few glsl errors. Comment out line 218 of GSDevice.cpp. Mess with
the fifo hack a bit.

Revision 5043

gsdx-ogl: Fix a few glsl errors I missed last commit.
Working with image.
I get the same message in console:
glX-Version 1.4 with Direct Rendering
GL_ARB_shading_language_420pack is not supported
and debug text:
GL_INVALID_ENUM error generated. Operation is not valid from the core profile.
Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
One thing to notice is (if this is relevant at this point) that the image in game is shifted to the bottom part of the screen, about 15% of the lower image is not visible.
PS2 boot screen and menus are well centered.
Your previous errors are expected and not important.
which game? Code was not tested a lots because it crash on my GPU AMD. But that not normal. 15% is bigger enough to be more than a round issue. The HW render computes some scaling/offset to convert integer (PS2 coordinate) to [0..1] float (PC coordinate). Maybe there is something wrong with the buffer upload.
"Your previous errors are expected and not important."
Um..I don't know exactly what to consider an error so I posted that anyway, as an info.
The game is Soul Reaver.
I'll test some other game to see if this 15% is consistent.
ok I have the game (well PAL). I just need to find why my silly driver crash then I would be able to investigate the issue.
OPenGL HW work for me! thanx
I tested other games for the 15% shift issue and is not consistent.
Some games are not affected and the shift seems more present in NTSC games.
@gregory and @arcum42. using OpenGL HW I got some screens.
it's weird, sometimes the picture is right and sometimes gets bad, take a look at Kingdom Hearts game at the beginning runs thus:
Then back to normal:
it focuses alternating between scenes one hour and another does not work!
That good news. The code is very recent. It work far better than expected.
It probably a z depth issue or an alpha blending issue (except the shift issue). Hum, the shift issue could be also an issue with texture size/viewport, that also could explain why it crash on my side.
I found the issue with the shift. You need to change nativeres to 1 in inis/GSdx.ini.
I think the gui need to be updated to add new HW option.
I got 2 questions.
1/ Does this behavior also appear on windows too ?
2/ Do you see the letters of the first menu (new game load) or only some colours rectangle.
Note windows == directx
I changed what you said and it worked!
letters appear
menu works
Nativeres=1 is solving the issue for MOH but Soul Reaver is shifted upwards this time.
The in-game image is cut exactly in half and only the upper part is visible.
The behavior is not consistent though, the movies are centered.
1 = I don't have a Windows installed right now.
2 = I can see them, but like I said only the upper part of the screen.
Don't have the issue on my side but I'v got the PAL version. However it is quite strange.
@dubigr clear all configs and tray again
It's a clean config except nativeres=1.
Nativeres=1 is fixing the issue for several games, but for SR it has the opposite effect, moving the image upwards (like in the screenshot).
One thing I noticed:
Minimizing/maximizing the window has the effect of restoring the full image but only for an instance, the game continues on the upper half while the lower half remains stuck as it were at the point of maximizing.
I don't how it work on windows but there are several config that are link together. I think the issue of the shift is because we need a factor * native res. In your case 512x448. So 1024*896 for KH. But it takes 1024x1024. It seems the option conflict on linux. I don't know how to handle them properly.
upscale_multiplier = 1
resx = 1024
resy = 1024
nativeres = 1
Changing "upscale_multiplier" to other value than 1 has the same effect as nativeres = 1 (centering the image but also cutting it in half).
However, while using any of the above settings to center the image, a full screen can be restored by interlacing the image (any interlace mode).
Now I'm using upscale_multiplier = 2 and Blend bff interlace mode and the image is well centered and complete (on all games I manage to start).
I don't know what to make of this, so I leave that to you :)
GSdx has got a mechanism to replay GS scene. I will need to implement it on linux. So you will be able to send me back the data for analysis. Maybe I miss a factor 2 somewhere. But it might also be an issue with the frontend part of GSdx (same behavior as dx)

Revision 5044

* add some define to enable/disable SDL so we could build gsdx without SDL
* debug: dump data based on frame count rather from draw count
Is this the beginning of the end for SDL software rendering?
If so I'm curious about the reasons...is SDL causing too much problems or just is becoming obsolete?
The first goal is to reduce the burden of compilation when you compile svn for the 1000th times we will understand :)
On sdl subject.
1/ SDL1.3 is not yet release on distribution. Gabest prefer to avoid this dependency. And it cannot be enabled by default, because some wxwidget depends on SDL1.2 which is not compatible with 1.3
2/ There were some bug on SDL SW render. Well it was maybe incomplete but for example "interlace features" are working on OpenGL.
3/ There were some hacks to workaround SDL issue and I change a little SDL to avoid some crashes. It is not future proof.
4/ For the moment opengl requires a DX10 capable GPU (5 years old), but intel will be opengl 3.3 compatible in 1-2 years on linux, 5-10 years on windows (IB will be 3.1 IIRC).... But I found an interesting feature of opengl 4.2 that can improve a lots the emulation accuracy. I don't know if I will be able to support both GPU class, at least I would like to keep OGL 3.3 for the SW render.
Ah yes the WX issue, I had to create my own rpm to get past it, that kinda suck. And SDL 1.3 seems to be for ages in experimental state.
Still, I'm kinda bummed hearing this...for the moment SDL is the only certain Linux option to use PCSX...well, there is also the GL plugin but I didn't had much luck with it while with SDL I can play everything.
But of course, there is also gsdx-ogl :)
The replacement of SDL is opengl SW. Don't worry you won't lose anythings. Me too I finish severals games (well 2) with SDL. By the way it is not yet remove. It a matter of choice, you can have either OGL or both OGL and SDL. Besides the target is the HW render, it remains lots of work but in only 1 month we get very interesting results.
Thanks for the clarifications.

Revision 5045

GSdx: the promised index buffer update, needed a lot of changes, expect bugs in
the next dozen revisions.
The GSRenderer template class is also gone, less bloated headers :)
Massive amount of changes, how do you keep it compiling??! :)
This is quite unfortunate for greg. He would have extremely hard time merging his branch back IMO, or be forced to fork or just drop it all together, and none of the above is too nice...
Many files were updated, but he only needs to copy GSRendererDX* and add IASetIndexBuffer to his GSDevice.
I would say better now than in 3 monthes :) Gabest is right opengl is independent of most of the change.
How much we gain?
Cool :)
By the way, I saw that you use the index buffer to avoid dupplication for *FAN and *STRIP primitive. Is it useful in another places?
Ah one more question. You deals with some .gs files in some review. What is it exactly? Is it a dump of the GS input so you can replay the "game" without bios and games? If I'm correct, it would be very useful for me so I could send bug report to AMD on their opengl implementation.
This change was rather bad for Xenosaga 2 (cpu load high).
We're down from 48fps to 32fps now :/
Couldn't see a difference in Dark Cloud 2 but Valkyrie Profile 2 was a bit slower.
This is in hardware rendering.
Software is unchanged here.
Ah yea, I'm using that intro scene in XS2 where they show that mech and 2 guys before it.
There's tons of geometry going on there and the load is almost exclusively on GSdx.
Oh and sorry for the negative, as I really do like the move of code out of the headers :p
2 others notes:
1/ How do you guarantee that index are valid when the vertex array is resized.
2/ Why not used R16 format for the index buffer, it would allow to reduce by 2 the bandwith needed by the index buffer. It would limit vertex to 64k which is maybe enough for the PS2.
Rama, do you know which kind of primitive do you have on xenosaga?
I'll check xenosaga, most games are definitly faster.
The total vertex data including the index is about 2/3 of the old, I still have to reimplement pre-clipping with the scissor (that TODO in GSRendererDX*::Draw()), it was only done for the sw-renderer now.
1 Where? How? I don't understand the question :P
2 There are cases when it goes above 64k. The real hardware does not buffer groups of primitives, it just draws when the drawing kick happens, probably.
1 Oh, I think you mean in IASetVertexBuffer, not GrowVertexBuffer. That throws away some data, it was a rare bug before I never fixed, now it is a double bug :D
1/ My understanding of setup IA:
IASetVertexBuffer(vertices, sizeof(GSVertexHW11), count);
You send vertex from m_vertex.start to m_vertex.start+count. Because the GPU buffer is too small. You allocate a new one. Invalidate all previous data with this flag D3D11_MAP_WRITE_DISCARD (or others stuff)
IASetIndexBuffer(index, index_count);
You send the index data but index was computed from the previous size of GPU buffer. So for example an index at start (start != ) + 10 will be at only 10 now!
Skipped over your question about the .gs files. When you make a snapshot with F8, also hold down the shift key and it will output two frames of input data. There is an exported function GSReplay that can read it and replace pcsx2, in this revision I just made it read everything into memory at start because vtune showed to much fread before my code. I use gs files to test game scenes faster, analyse bug reports without the game or to compare fps changes between versions, thought you already knew about this. On linux don't know if there is any rundll32.exe, you may need to write a little program that launches gsdx, checking F8 during snapshots is also windows-only.
Yes, reallocation breaks things, it has already thrown out vertices, they should be copied over to the new buffer. It's a write only buffer, need to call some dx/opengl api to do it.
Hm, wait.
ASSERT(m_vertex.count == 0);
I never call IASetVertexBuffer more than once between drawing calls. I could, but then this assert would be triggered. So, when reallocation happens the buffer does not have any outstanding not-yet-rendered data that would be appended.
The index buffer in relation does not matter, the start is used when calling DrawIndexed/Primitive.
Appending would also break when the end of the buffer is reached and discarded.
OK. I miss the base instance on the DrawIndexedPrimitive. Hopefully for me I could do the same on GL :)
Thanks for your answer on .gs. My todo list become bigger ;)
ramapcsx2: In xs2 into at that place there are 34k primitives, half of them can be removed, the question is, is it enough to drop them from the index buffer.
Not sure I understand the question, Gabest.
All I'm seeing is reduced performance in my games, especially XS2 with it's many primitives.
I thought this change was meant to reduce CPU load?
There are two factors here. If I remove the entries from the index buffer and upload the whole vertex buffer, it only helps a very little. However, if I don't even call GSRendererHW::Draw (which sets up states, fetches the texture), because every triangle failed the scissor test, then it gets back to the old speed, almost, because the vertices are still all uploaded. I'll try to add some basic filtering to GSState::DrawingKick, if that does not help, copying vertices to a temporary buffer, without the failed ones, should help.
"every triangle failed the scissor test"
oh yea, because xs2 generously sends 50% off-screen triangles to the GS :D
With this version Rouge Galaxy has a lot of SPS and the .Hack terminal Disc shows only a black screen after starting a new "game".
Also all games I tested so far are slower or same speed. (GTX560Ti / X4 940)
Its really sad that the Xenosaga games are slower on my sytem with the new multithreading option. They are may favourite JRPG games and now they are even slower.
Hopefully a 2600k can bring some more speed in a few weeks.
Just use the last version until everything is sorted out.
shrinking to 2/3 data? over PCIe? and you do a whole level of new computation to prepare the data in software. ahh. we'll see how it turns out. ;)
Oh yea, Rogue Galaxy looks funky :p
I'm going to neutral, as you've noticed my report.
Had to check Dragon Quest 8 then as well:
Strangely, Dark Cloud 2 is unaffected.
A typo to fix in the next commit
1 line-by-line comment
line 518:
518: printf("GSdx: Set shader %d (%s).\n", (int)m_shader);
I'm suprised it does not crash on windows. The extra %s must be removed or a string must be print.
"This change was rather bad for Xenosaga 2 (cpu load high).
We're down from 48fps to 32fps now :/"
Down 20fps in Industrial Plant (Dark Professor) 115-125fps to 95-105
Greg: that never crashes windows, it just prints out an uninitialized value ;p
Windows is uncrashable!
(Well sometimes it is. And then you often wish it would crash and tell you what went wrong :p)
Some evident bugs: the Playstation2 logo doesn't show up anymore on complete boot and in Devil May Cry 1 when you start a new game the fading in red is wrong (the background disappears immediately and the screen turn completely red.
P.S. using WinXP Ati Hd4850 and Gsdx Dx9(hardware)
Confirmed for Dx9 hardware, the logo appears fine for Dx10

Revision 5046

GSdx: there is a possibility of calling GSState::Flush in the middle of a strip
or fan, the last few vertices must be saved to be able to continue, haven't
found anything with this problem though.

Revision 5047

GSdx: fixing the broken things...
The scissor and empty area tests are now done in VertexKick, that eliminates the different variations for each vertex type in the derived classes.
Great, bugs in Level 5 engine games are gone and speed is back as it was before in Xenosaga 2 :)

Revision 5048

GSdx: disable vtune
Without it we do not lose performance?
It only enables profiling in vtune.

Revision 5049

GSdx: vtune tells me GSOffset::GetPages is too slow without the cache and its
slowest part is new uint32[], lets use pre-allocated buffers then. In d3d9 mode,
locking the vertex buffer is the most painful thing, there is a terrible delay
until it returns, the same Map call in d3d10/11 does not behave like that.

Revision 5050

* fix some issue with cmake and new sdl define
* Implement shortcut key handling on linux.
+ some option are not yet implemented (fxaa)
+ gs dump can be created with <shift> <F8>

Revision 5051

Let users set software parameters (extra threads and line AA) regardless of
currently configured renderer.
Makes testing far easier.
Some of latest changes (5036 work fine, 5051 not) cause graphic corruption in Onimusha series, issue 951 is also unresolved.

Revision 5052

gsdx-ogl: add a loader to replay gs file. Quite shaky but probably enough for
debug :)
Unable to compile, got some errors:
well that normal I tested without SDL :p
Ok I fix it in the next commit. Now you will be able to generate a .gs inside pcsx2/snaps directory. And the pcsx2_GSReplayLoader will be able to replay again and again until I found a way to fix it :p Well only if it is an opengl issue.
Create the dump:
1 dual frame => shift f8
a video => ctrl shift f8, and keep ctrl press. Release ctrl to finish the movie. Warning it could take lots of disk space.
Replay the dump:
pcsx2_GSReplayLoader <ini dir> <gs file>
For example:
pcsx2_GSReplayLoader ~/.config/pcsx2/inis ~/.config/pcsx2/snaps/gsdx_20120106233019.gs
Ditched the SDL but I can't play the dump.
I got this error:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 17
Current serial number in output stream: 19
I put the Sleep(100) there to leave some mark in vtune's cpu usage graph, so I know where the real thing starts :P
I thought it was to avoid noise in profiling. Anyway, I don't have vtune not free, surely not AMD compatible. And 100 seconds it really too long :p
AMD have a free equivalent but I'm not sure I can install it on my 64 bits system to replay 32 bits traces. By the way, maybe I could compile GSdx on 64 bits for the replay.
lol, it is measured in ms for Sleep.
64-bit build is currently broken, the xbyak code has not been updated for a while.
The new vtune amplifier is really awesome, not as clunky as the old was, but surely not amd compatible. It's free for 30 days, you can just register a new email and get new licenses when it expires.
Ahhh. Actually I replaced Sleep with sleep (second), I didn't found the previous one (well I didn't search a lot). In worst case I will replace it with 1 second :)
Ok I won't touch the 64 bits code. I have enough issue already. Thanks for the vtune tip, for the moment I'm on AMD but maybe for my next cpu.

Revision 5053

gsdx-ogl: was too shaky after all!
Compiling again OK with SDL.
Like previously the dump is created but I can't play the .gs file:
[[email protected] bin]$ ./pcsx2_GSReplayLoader /home/dave/gsdx-ogl/bin/inis/ /home/dave/gsdx-ogl/bin/snaps/gsdx_20120107020112.gs
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 1 (X_CreateWindow)
Value in failed request: 0x0
Serial number of failed request: 119
Current serial number in output stream: 122
I personally haven't had much luck building this revision or the last. When I compile, it's been failing with linker errors on the replay loader for glew, gtk, and x11:
Linking CXX static library libGSdx-static.a
[ 80%] Built target GSdx-static
Scanning dependencies of target pcsx2_GSReplayLoader
[ 81%] Building CXX object plugins/GSdx/CMakeFiles/pcsx2_GSReplayLoader.dir/linux_replay.cpp.o
Linking CXX executable pcsx2_GSReplayLoader
libGSdx-static.a(GSDeviceOGL.cpp.o): In function `GSVertexBufferStateOGL::draw_arrays()':
/usr/local/src/pcsx2-ogl/plugins/GSdx/GSDeviceOGL.h:376: undefined reference to `glDrawArrays'
libGSdx-static.a(GSDeviceOGL.cpp.o): In function `GSUniformBufferOGL::bind()':
/usr/local/src/pcsx2-ogl/plugins/GSdx/GSDeviceOGL.h:245: undefined reference to `__glewBindBuffer'
libGSdx-static.a(GSDeviceOGL.cpp.o): In function `GSVertexBufferStateOGL::bind()':
That's with gcc 4.6.1, cmake 2.8.5, on a 32-bit Lubuntu system without sdl included (though it did the same thing with sdl included...).
Well, I got it to compile after some modifications. I end up with the same error as dubigrasu when running it, though.
Here's what I did to get it to compile:
Index: plugins/GSdx/CMakeLists.txt
--- plugins/GSdx/CMakeLists.txt (revision 5053)
+++ plugins/GSdx/CMakeLists.txt (working copy)
@@ -205,6 +205,13 @@
target_link_libraries(${Replay} ${SDL_LIBRARY})
+target_link_libraries(${Static} ${OPENGL_LIBRARIES})
+target_link_libraries(${Static} ${X11_LIBRARIES})
+target_link_libraries(${Static} ${GLEW_LIBRARY})
+target_link_libraries(${Static} ${GTK2_LIBRARIES})
+ target_link_libraries(${Static} ${SDL_LIBRARY})
target_link_libraries(${Output} "${USER_CMAKE_LD_FLAGS}")
Loader error seems like the previous I get. It failed to pick up the ini directory and get windows size = 0,0...
Could you test to add a break point on GS.cpp:280 and confirm that it does not pick the window size. Check also that ModeWidth and ModeHeight was set in GSdx ini.
Sure enough, looking, they were 0. In fact, it's looking like they have to be set by hand at the moment; I don't think the plugin is setting them.
That is, ModeWidth and ModeHeight were 0.
can you send me a dump (at gmail dot com to my login) of your half sreen issue. Bzip or xz it.
Arcum, does it work, if you manually set the value on the ini? Maybe it would be better to fallback on 800x600 rather than 0x0 when no config is defined!
I'm currently looking at GOW black screen issue on menu. The good news is that menu texture seems to be properly built (with some minor glitch). But we got an issue on the merge stage which impact alpha value. Alpha does not work very well on AMD so I would like to know if it work better on nvidia.
It does in fact work if I set them in the ini file manually. And there is actually a fallback in GSWnd::Create, but it is only checked if ENABLE_SDL_DEV is defined.
When I was looking at that, I also noticed a #if ENABLE_SDL_DEV in GSWnd::SetWindowText instead of #ifdef, btw...
Ok. We just need to move the ifdef under the fallback that will do the trick.
For gow, I'm close to find the issue I think. Blending is not enabled during the merge stage which is not normal. I must have forgotten a setup call somewhere
I'll send the dump asap (I'm at work now) but what kind, dual frame or video?
If video, how long must be (or how big)?
Is growing to 1 GB in just few seconds...
Just a dual frame. It is enough :)
I added values to ModeWidth and ModeHeight (800x600) and made a short 5 seconds capture.
The error is gone now but the player is segfaulting after a very brief image.
Sent the mail BTW.
hum, did you have the issue when you replay it. Can you send me your config file too.
While snapshot was taken the issue (half screen) was present.
I can't use the pcsx2_GSReplayLoader to play anything. It starts but immediately segfaults.
I can only see for a fraction of a second an attempt to start.
ModeHeight = 600
ModeWidth = 800
UserHacks_AlphaHack = 0
UserHacks_HalfPixelOffset = 0
UserHacks_SkipDraw = 0
aa1 = 1
aspectratio = 1
dump = 0
extrathreads = 3
fba = 1
filter = 1
fxaa = 0
interlace = 0
logz = 1
mipmap = 1
msaa = 0
nativeres = 1
paltex = 0
renderer = 12
save = 0
saven = 0
savez = 0
upscale_multiplier = 1
vsync = 0
windowed = 1
can you create a gdb backtrace. Note use a debug build.
gdb pcsx2_GSReplayLoader
run ini_path_directory my_dot_gs_file
When the segfault appears, just enter backtrace full.
This is from r5065
Good. Is it with the SDL build?
I was afraid you gonna ask that:)
Is it because of this?:
#1 0x0822f8ab in XMapRaised (a=0x0, b=54525963) at /home/dave/gsdx-ogl/3rdparty/SDL-1.3.0-5387/src/video/x11/SDL_x11sym.h:7
Yes, SDL included.
Yes and no ;) Could you give it a try without SDL for the moment.
no -> Actually I did not see the SDL_x11sym in the log. Which render my question pointless by the way.
Yes -> The display value (a) is null. Looking at the code, it seems to be miss in some SDL code path. The code becomes way too complicated. You have 2 way to handle windows (GSopen and GSopen2). You have 2 window render, opengl or sdl. Then you have the build with/without SDL. Way too much combination.
OK, made a debug without SDL build.
pcsx2_GSReplayLoader is working.
Need another backtrace?
no. It was just to have a confirmation of the issue. I will fix that later. Windows management code will need to be completely rewritten at some points to separare DX/OGL MS/OGL LNX/SDL.
So do you have the issue of half screen on the replay too? If yes, I'm afraid that you will have to dump few frames (2 or 3). Look at the top of GSDeviceOGL.cpp. You can control the define. Texture will be dumped into your /tmp directory. Open them and look. Find when the texture miss half of the screen. Check input is complete. The number inside the file name is the draw call. Draw call datas are print to the screen, speaking of that I need to send them to a file. I will need this data.
I'm trying to implement a way to trace polygon line onto the screen so it would be easier to see what is going wrong but no luck so far.
Think you have to give me some more advices on this.
I've edited the file GSDeviceOGL.cpp and now I got textures dumping so fast in /tmp that by the point it reaches the half screen part is already 15 GB in size and heck if I know what to search in all that gazillion frames.
Don't dump everythings. You can control the start and the length. For example those parameter dump frame 600 (~~10 second) to 603. Normally 3 frame sould be enough. If 600 is too short increase it to start later.
#define DUMP_START (600)
#define DUMP_LENGTH (3)
An advice clean previous value in /tmp before each run.
The best is to look at the out.* file first. If there are complex scene you will see the construction of the picture step by step. If it is only a mapping, it will draw a rectangle and map the full texture.

Revision 5054

gsdx-ogl: Add a Native Resolution checkmark to the dialog box. Set a default for
ModHeight & ModeWidth when saving the ini file. Link the gdsx static library
against a few things.
It might be the good to think how you can improve the gui. It would be very interesting to separte HW and SW. Some options have only valid in 1 mode.
Yeah, the current dialog box was thrown together pretty quickly, and was written when sdl was the only option. (And for that matter, when the plugin wasn't working yet.) It could stand some improvement.
For separating hardware and software, it'd probably be easiest to just grey out options that don't apply when the renderer is changed...
I know this is the right spot for it but could there be a option to dumb textures to a folder? You know when textures are loaded and you could just dump those. It'd be a real help.
What texture exactly do you want to dump? You mean the current define in the code to dump some texture before the call to the draw command?
Is it possible to dump all textures as they're loaded?

Revision 5055

gsdx-ogl: Revise build.sh script, redoing the command line options.
Just wanted to be a bit more standard. Add -- in front of all the options, and the "gsdx" option is now --sdl13, since gsdx will build without it now.
If you type ./build.sh --help, or, in fact, any invalid option, it'll print out a list of the options for you.

Revision 5056

gsdx-ogl: Remodel the linux dialog box to make it look better.
This is still a work in progress, based on what the Windows version looks like. I'm also trying to determine what should be there and what shouldn't, since there were things in the dialog box that were clearly wrong...
One of my comments in the code is, in fact, inaccurate, btw.
is now much better, keep it up. :)
Thanks. It's a result of me going into window, taking some screenshots, then spending a bit of time with the layout docs on gtk. I'd been kind of avoiding looking up how tables worked with widgets in Gtk. :)
And now I've just spent a bit of time getting everything to disable when it's supposed to...

Revision 5057

gsdx-ogl: Add msaa controls. (Probably doesn't actually do anything at the
Of course there's a bunch of stuff that should be enabled or disabled at various times that isn't right now.

Revision 5058

gsdx-ogl: Things now disable and reenable when appropriate.

Revision 5059

gsdx-ogl: All the Windows versions get a fancy logo on top, so...
I'm still ambivalent on this one, since the logo doesn't quite fit right. It's the same size as the Windows one (and derived from it), but the Linux dialog is wider.
This is what it looks like at the moment, btw:
Way to go :)
Thanks. I kept a layered version of the graphic around, so I may tweak it a bit later...

Revision 5060

gsdx-ogl: Added the hacks section to the dialog.
Just like in Windows, you need allowHacks enabled for them to appear.

Revision 5061

gsdx-ogl: Since Texture Filtering has 3 states in Windows, change it to a combo
box in Linux.
I didn't see any of those fancy 3 way checkboxes in gtk...
And that's probably enough of mucking with the dialog box for me today. I think it's just about on par with the Windows dialog box now.
You sure you don't want to write the GUI in wxWidgets? Keep it consistent with the emulator itself. wxWidgets also has 3 state check boxes.
a) I know gtk+ a lot better then wxWidgets.
b) None of the plugins currently use wxWidgets for their dialogs. So it is consistent in being inconsistent, as it were.
c) Last time I looked into it, it looked significantly harder to create a wxwidgets dialog box that gets called from a plugin then either a gtk+ or Windows dialog.
Also keep in mind that the major work on the gsdx's dialog's already been done at this point. For here it's mostly tweaking and maintenance. (As far as the dialog box goes, anyways. Lot's of stuff still needs to be done on the backend...)
for (c) it can be done. http://www.dreamincode.net/forums/topic/164761-using-wxwidgets-in-a-dll/
please no wxwidgets, it's mfc with all it's problems.
hey guys: Fleeing a bit of GS. Would do a little review on DVD in Linux plugins?
I did not want to post as problems because it is a simple question!
very good jobs. I love the fancy logo :)
Thanks. It started out life as a copy of the GSdx 9 logo, which I then started playing with in Gimp. In fact, as I recall, one of the layers is still the original GSdx 9 logo, only with the 9 removed...

Revision 5062

GSdx: sps fixed, some code clean up and optimization, ps2 logo still broken in
hw mode, I'll check it later
Just wanted to voice appreciation for all the hard work going into GSdx recently ^_^; It's really exciting to see all the changes happening. Please keep up the great work :-)
Could you be a little more precise on 'SPS fixed'? What SPS? Where? :P
It was caused by the recent index buffer changes, some vertices were converted twice from one format to another.
Well, I've recently updated from an unknown revision (I just don't remember which one I used) to rev. 5037 and ... the saddest thing ever has happened: While re-playing Xenosaga ep 1 (yeah, 43th time) the fps go down to 25 from ~50;
Honestly, I don't remember such slowdowns before on my noob-ish pc: Core 2 Quad 3.0Ghz / 8GB DDR2 / ATi Radeon 5870 / Win7 x64 SP1;
I wonder when that hack-fixing HW mode will be stopped and total rewrite of HW mode being held;
Sorry for my English >.<
Hidden geometry removal was temporally not re-implemented, xenosaga had a lot of them, try the latest built.
gobantai: Patience young padawan. Best to keep a backup of a plugin lying around when trying a experimental version.
I really like those recent index buffer changes, speedup in lots of games.
I hope you can take a look at "Crash on the Titans" shadow bug in HW mode.
sw: http://images.zm-online.net/images/AHKT.jpg
hw: http://images.zm-online.net/images/k2HEn.jpg
Omg haha..the PS2 logo..if this is fixed PCSX2 can emulate everything perfectly

Revision 5063

GSdx: fixing a possible buffer overflow
Just to add to your to-do list, recent changes (r5045+) have also broken most psx game graphics (such as chrono cross, wild arms 2, Valkyrie profile..and every other title I tried out :p)
oh noooo
And I just found more problems, I can't do ceil(xmin, ymin) == ceil(xmax, ymax) to remove triangles without substracting the screen offset. The offset might have a fractional part. There are gaps in DMC.
indeed, only fmv's and fmpegs are working on psx games
I think sprites are missing, I can see everything in xenogears, except the dialog texts.
couldn't get into FF8, the load menu wasn't displaying so i suppose the actual 3d parts might have worked if i got further.

Revision 5064

* fix bad setup issue for constant blend factor
* Use a read framebuffer to read back the texture (less disruptive)
* cmake separate the loader to the main plugins
I've tried SVNs from EmuCR and from the official website, but I don't see this plugin/backend anywhere? I want to test it. Let me know whne you get a chance please!
You need to compile this on Linux, using the correct branch.
It has nothing to do with Windows.
Oh I thought this was available on all platforms.
Just at a mention, all the various spamming debug defines were left uncommented...
Also, OGL_DEBUG was not defined, so we're back to Gust crashes.
Good point. I forgot yet again debugging stuff, blending must be reenabled too... However OGL_DEBUG must be defined. It is defined in CommonFlags inside cmake!
On the gust crashes. Can you test to add those 2 call around fifo2.
// DO fifo2 stuff here.
It would attach the main context to the EE thread that it allows to use any gl command from the EE thread. Normally context can only be attached to 1 thread but when FIFO2 is called all gs command are stopped so it might work finger-crossed. If it crashes, we will need to find a way to unattach the context inside the GS thread.
Hmm. Missed that. I'll do a clean rebuild first, then, and see if something didn't come over properly.
Adding the AttachContext & DetachContext in GSreadFIFO2 seems to take care of the issue.
Very good news. We must be sure that it does not crash because of threading issue inside the driver. AMD drivers are still crashing on my side, not very practical to test the stability.

Revision 5065

GSdx: it's hard to keep track of the leftover vertices properly, a bit of sps
was still possible, psx sprites were fixed too
nice fix, psx game graphics are working again. :)
Also is this Change only for PCSX also the psone emulator? Also i never used that Emulator only ePSXe and PSXeven(for games they dont work well whit ePSXe) is there a big difference to these Emulator´s, also in the Past i loved ePSXe cause of these nice Shader Effekts and Combatiblity to most of my loved games.
This rev fixes ps2 graphics errors as well.
I don't know if gsdx works with pcsx, I use epsxe.
For the recent efforts at GSdx. Keep it up :)
[email protected], Gsdx will work in most psemupro plugin compatible emulators such as ssspsx, epsxe(shark), pcsx(r), psxseven..etc
The variances from emu to emu is usually pretty minor since the plugins control most of it, the only problem with gsdx in other emulators is vsync so you might have to use spueternal set to "async, wait" to cap the fps to 60.
I personally use ssspsx and rarely ever have problems with it, and gsdx is great since it can make the game look like a normal psx game but with upscaled sprites.
Nice work so far, you guys magically fixed most of the lagginess Crash Tag Team Racing had! Of course there's still an issue with it's sound having a really loud and high pitch noise to it, but i hope you guys will address other issues when the time's right. :)
Oh, and something i wanted to ask: I keep hearing that the GSdx can be used for psx games but every emulator i've tried does not "see" it. What about it?
[email protected], you need to copy it to the plugins folder, you will also need the plugin dependency's (SDL.dll) in the root folder.
that should work for most emulators however some like psxseven need 'gpu' in front of the filename for it to show in the gui (or you can manually set it in the ini).
@[email protected] Thx for the Information:)
Btw i have a Question about Savestates, is it only me or do we all have to look in the Console to see in wich state we saved?
In ZeroGS i can see it but i like GSdx more, this would be a realy nice fix:)
Big Thx for the Speed Boost in most of my Games, they work Great now (i try to Play Valkyrie Profile through again, it has buggy Screens in Lost Forest in HW Mode and Vertical Stripes in In-Game Scenes, if i change to SW mode its gone).
Keep up the Good Work
Works well in ePSXe and PCSX-R...thanks...but am I missing something as far as speed in pcsx2? Everything seems to run exactly the same...just referring to TM's post...
@konaj: Thanks for the tip. I did try adding the 'gpu' part in front of the lib, but i didn't know i needed SDL.dll for it to work. Anyway, it runs great.
Now i don't know if the team decides sometime later in the future to emulate PS1 games from within PCSX2 (since i tried PCSX and it pretty much sucks :P), but there are quite a lot of things the GSdx plugin needs to change at the PS1 side, some of which are:
1) Make it's own ini, i had to move the one from PCSX2 in the emu for it to save its settings
2) Allow dynamic framerates for PAL and NTSC
3) Show savestate slots
4) Make windowed mode actually work
That's the end of my rant :D
@jeremybe forgot to Mention the changes from r5011 to r5065 got a nice Speed boost for me mostly in SW Mode and little bit in Hw Mode, i was testing Games like Valkyrie Profile, Tenchu Wrath of Heaven and WWF Smackdown VS Raw 2011(i dont feel big slowdownes here anymore).
Maybe its cause of some MTVU Changes? It works good for me (have AMD Phenom II X6 BE 1090T) whit extra Rendering Threads 4.
Wich Games did you Test?
Good work !! As always ))
But there is a problem - Killzone hangs in SW mode after 3-4 min of gameplay. Might be buffer overflow or somthing like it... HW mode works OK.
(Strange - this game need a very powerful videocard in both modes.)
This rev has also presented a work-around for H/W rendering of PS2: Arc Twilight of the Spirits PAL (Arc the Lad)in DX 10/11 without texture corruption (white overlay on anything but sprite objects) by switching to S/W mode, and then back to H/W mode, works untill the emu is shutdown. Have to repeat apon initial load of the game.

Revision 5066

wiki: a todo list of gsdx ogl.

Revision 5067

gsdx-ogl: linux only
* Fix some issue on wnd management, mix between sdl/ogl render
* create new gsdx option for ogl debug
+ debug_ogl_dump: start frame to dump when not 0
+ debug_ogl_dump_length: length of the dump
+ debug_ogl_shader: print shader debug
Note current dump option must be fixed to use linux path.

Revision 5068

GSdx: nothing really new, just testing the compute shader, if you are an expert
take a look and tell me your opinion :P
Oh no. More work for me :p Can you bump renderer to more than 12 (ie 15), I already use it for opengl, otherwise I will change it.
What is your current goal? Port the SW render to a compute shader. Or do you want to add compute capability to the current HW render? Well if you can mix UAV and others GPU capability.
By the way did previous modification (ie buffer index) are stable now? Or do you need to fix some regression? I try to find the best time zone for my branch synchronization :)
> Oh no. More work for me :p Can you bump renderer to more than 12 (ie 15), I already use it for opengl, otherwise I will change it.
Lets make opengl modes the next three numbers then.
12: opengl + hw, 13: opengl + sw, 14: opengl + null
15: compute shader, 16: opencl, 17: cuda, whatever ...
> What is your current goal?
Not taking anything from other renderers, it can only be a complete reimplementation of everything built on top of GSRenderer. Might be a failure in the end, dunno how fast it is going to be. Rasterization will be brute forced, each pixel/thread interpolates values on its own. And I'm not yet sure about the r/w performance of RWByteAddressBuffer either, hopefully latencies won't kill it, all the GS memory is only 4 megabytes.
> By the way did previous modification (ie buffer index) are stable now?
Seems so.
Everything seems to be pretty fast so far (not really doing anything in the shader yet). The slowest part is updating the vertex buffer, in each draw I discard 10000 vertices, reallocation is damn slow. This will be modified to be a ring-buffer like the real vertex buffer. Or there is this mysterious ConsumeStructuredBuffer, what is not clear to me, how parallel running threads can consume it, each has its own pointer or they share the same queue.
Hm, I think the regular vertex/index buffer can be used in the CS, just need to add D3D11_BIND_SHADER_RESOURCE. There won't be any hidden conversion, like uint32 colors to float4, but still very convenient.
D3D11: ERROR: ID3D11DeviceContext::Map: Map cannot be called with MAP_WRITE_NO_OVERWRITE access, because it can only be used by D3D11_USAGE_DYNAMIC Resources which were created with GPU Input BindFlags that were restricted to only D3D11_BIND_VERTEX_BUFFER and D3D11_BIND_INDEX_BUFFER. [ RESOURCE_MANIPULATION ERROR #2097210: RESOURCE_MAP_INVALIDMAPTYPE ]
Doh, why so picky.
Stream-output might be the solution, that way it goes through the vertex shader, which can be feed with vertices fast.
Another idea to try, drop compute shader, use RWByteAddressBuffer from the pixel shader, output set to a dummy 1x1 render target. Just how mad that would be.
thank for the reply
what is exactly stream-output?
Doesn't compile on VS2008.
I also don't own DX11 hardware, so dunno if I can test anything here :p
I'm not sure anymore if I want use the compute shader. RWByteAddressBuffer in a pixel shader may work better. Stream-output stage in dx10/11 is after the geometry shader, it stops there and does not call the rest of the shaders, you can choose to write the processed vertices to your own buffers and that's it.
I still hope that a (DX9) hardware renderer is possible that uses a working texture cache.
I know that blending will never work with the current limitations but it should be possible to come up with a correct texture cache for GS emulation.
Sudo mentioned texture sheets with correct updating, those could maybe do the trick..
On my opinion, a pure compute/opencl/cuda shaders migth be a better idea on the future. Hardware will probably have more capability and will be easier to program.
However, RWByteAddressBuffer will worth some exploration. It could be implemented as speed/accuracy hack for the moment. It doesn't need to start from scratch moreover we could test the performance. For your information, I'm currently trying to implement depth management (feel smaller and easier that blending at the moment) from shader on opengl. Unfortunately I haven't had any free time for 1 week so progress are quite slow.
Oh, that damned RWByteAddressBuffer, if I draw one single triangle, it's fine, send more and writes seem to happen out of order to it. I find no way to syncronize it from a pixel shader. DeviceMemoryBarrier and the globallycoherent attribute were the two options, but they do nothing. How is it possible that a pixel shader at the same pixel can complete faster that the previous? My only guess is that the results are buffered and serialized somewhere after. Now, trying to replace the buffer with a rwtexture, it will be much slower, from what I googled.
Same with textures. I'm a sad panda.
Maybe if I used a dummy zbuffer or a dummy alpha blending, that would serialize it.
From the opengl spec:
* The relative order of invocations of the same shader type are
undefined. A store issued by a shader when working on primitive B
might complete prior to a store for primitive A, even if primitive A is specified prior to primitive B. This applies even to fragment
shaders; while fragment shader outputs are written to the framebuffer in primitive order, stores executed by fragment shader invocations are not.
"Devils are in details" :)
Anyway, I have several web site (amd & nvidia) presentation that is worth reading.
# A cuda based rasterizer
# Amd presentation on OIT (order independant transparancy). Read this one! I think we need to do somethings similar (ie without the sorting) besides it is based on DX11.
# Something similar than the previous one. Deals with Accumulated buffer (Abuffer)
Hum, I said something wrong. We actually need to sort based on the primive ID. Maybe it could work (most of the time) with a standard depth sorting.
Every gpu rasterizer I've seen approached the problem like this. That's where I wanted to start, first without assigning triangles to tiles, just using the largest bounding rectangle and let the thread groups work on the mosty empty regions. Binning and sorting would greatly reduce the work, that would be the next step, when I tried iterating over a few thousand triangles on the whole screen (640x512) even the mouse pointer stopped moving a bit.
Also tested the stream-output, it can be easily used to put vertex data into device buffer, and once it's there the compute shader can read it. This looks to be the fastest way to upload it.
What do you want to do exactly with the stream-output?
On the window management (GSWnd), would it be possible to manage it like GSDevice/GSRenderer (ie inheritance and dynamic object).It would be easier to handle properly OGL_LNX/SDL on linux and the future OGL_MS.
Niceeeeeeeeeeee <3
Hmm, maybe some saturation filters would look nice? :p
That linked fragment-list idea might actually work. I'm only worried about the size of that buffer needed, one batch may have millions of rendered pixels, multiplied by the fragment data. Hundred 640x480 quads each outputting only two float4 can reach a gigabyte.
Long time ago I tried several temporary bufferers in the sw shader, instead of finishing a triangle as fast as possible, doing the rendering steps horizontally across the triangles but parallel, saving the results each time to memory. That turned out to be trashing the cache and even if the algoritms were simple and fast, working with too many data killed the idea.
> What do you want to do exactly with the stream-output?
I have already written about my difficulties of streaming vertices fast to the gpu, the only buffer type which supports dynamic memory and no-overwrite mapping is the vertex buffer, but that cannot be bound to anything else than the vertex shader. The stream-output option can store the transformed vertices into a regular gpu memory buffer and then I can feed it to the compute shader.
> On the window management (GSWnd), would it be possible to manage it like GSDevice/GSRenderer (ie inheritance and dynamic object).It would be easier to handle properly OGL_LNX/SDL on linux and the future OGL_MS.
Looks possible.
I want the MAME hlsl shaders :P They used the effect system and there are quite a lot of parameters, won't be easy to figure it out.
Hmmmmmmm. Creating the linked list of fragments also assume shaders at the same screen coordinate run in serial order. I'm surprised it worked for him at all.
They use atomic to avoid any collision. At least, atomic for the buffer offset (ie a pure counter) and screen_buffer that hold buffer offset. I'm not sure the pure data buffer need atomic because you write to different location.
Me too I'm worried about the buffer size. On my gpu (hd5770, 1GB), the following
GLint size = 0;
glGetIntegerv(GL_MAX_TEXTURE_BUFFER_SIZE, &size);
fprintf(stderr, "size 1d buffer %dMB\n", size/(1024*1024));
give me
size 1d buffer 256MB
I was expected much less! Anyway, we might need a way to drop useless fragment to save resources. Dx11.1 will allow to run UAV from any shader stage, maybe a very early coarse depth testing could help.
Think it over again, if pixel shader runs out-of-order, no atomic operations will help. This is based on the same assumption I fell for. He cannot possibly create a linked list because the order of linkage will be the same erroneous order, resulting from the parallel pixel shader runs at the same screen position.
The other guy tried to use absolute positions, not a list. That is immune to this problem, the only limitation is that the size of the fragment buffer at each screen position limits the number of triangles he can send at a time.
I'm not sure I understand the issue. As far as I understand, list is created in a random order. However when they render , they do it pixel by pixel (duno if they are able to run all pixel in parallel), the first step is to sort the list based on depth value, in ours case we might need to sort it based on a fragment/primitive ID. The sort is probably cost a lots. But you will be able to recover initial order to compute the final depth/colors.
Texture2D dimension limit is 8K x 8K, that's 256MB with DWORD elements, I wonder what would happen if I tried larger types :P
Read his description of the process. When the shader runs he reads the list-index of the last pixel at that screen position from a screen-size lookup table, this will be the back-pointer, and adds it to the end with the fragment data. It all depends on serial pixel rendering. In the second step he traverses this list and re-runs the pixel shader state step-by-step.
which guy, amd, nvidia or the thirds one?
For the texture, are you sure they aren't a max byte size limit too?
The power-point presentation, actually two guys from amd. I'm tempted to ask them about this little issue.
Don't know, need to try, the debug runtime can tell if there is any problem. But if 256MB is not enough, we are doing it wrong.
The reference rasterizer does not reorder, no surprise. This presentation is from 2010, maybe they used that, or had older hardware.
Hum, I will need to carefully reread everything tonight. For me, if you want to do order independent transparency, you need to sort pixels somewhere.
Nvidia presentation is more recent, the guy did several of them and you can download the code source of the his cuda rasterizer (on google code). The major issue is to understand cuda :p
Don't read that far, just pages 8-21, before it sorts by Z (which may or may not fix the out-of-order problem, depends on what tests and blending you want).
So the trick is sorting, every linked-list implementation I could find were based on the amd article and each one sorted by z (no mention what happens when two pixels have the same z). This is probably the most helpful: http://www4.atword.jp/cathy39/category/direct3d11/oit-direct3d11/. The problem is, a temporary buffer is needed inside a shader for sorting, and that again limits the number of fragments at the same screen position. At least it does not need a huge buffer. Depth is no good for me, but there is a primitive id attached to each pixel, I could store that in the list item, only this temp buffer is worrying me. If each batch is sent with 32 prims, that may add too much calling overhead.
Yep, better uses the primitive id. What part is worrying you, the sorting? The buffer will need to be copied inside local memory/register shaders.
What do you think of the possibility to do early pixel testing like depth or alpha or whatever? It could reduces the buffer size and save fragment computing resource. Well it could be very tricky when blending is enabled.
Tricks can come later, first the main issues :P
I'm trying to find out the largest array size, or total local variables, you can have in a pixel shader.
error X4505: Sum of temp registers and indexable temp registers exceeds limit of 4096
10 fps at most, without texturing :'(
I was expecting a bit more :( In particular, I'm nearly sure that you have a good GPU! What resolution did you use? 512x512?
460GTX, just at the native resolution. I'll upload it soon, not much is done, just reading and writing the frame buffers with the vertex color and depth.
I think the switching between drawing and the quad that transforms the linked list is the problem, there is no way to do that for more than 100 times per frame. Maybe if I rendered 512, or whatever limit I choose for sorting, from different batches together into a common list, only have to flush it when the result needs to be transfered to a texture or have to be read back.

Revision 5069

gsdx-ogl: linux only (merge from trunk 5022:5068)

Revision 5070

gsdx-ogl: linux only
compilation fix, add bits for the index buffer.
current status is blackscreen :p
with this all was extremely slow!
Did you test latest version of the trunk? The best is to report to Gabest.
For the moment, I don't care about performance. The goal is to follow Gabest modification so I will be able to merge it back to the trunk. The OGL part is only a backend, rendering is exactly the same between dx and opengl (it might be changed later).
By the way, can you test next revision and tell me if it still working on nvidia.
well, it works on nvidia
Now the hardware is working, it did not work before
but is still slow, but as you said Gabest should check it!
Good. There is a lots of glitch. If you can send me a .gs, just shift F8 in the middle of very bad frame. You can found them inside snaps directory. I suspect some issue with z buffer accuracy.
Not sure I understand correctly. What is slow? GSdx ogl or the index buffer added recently (dx or ogl, both?).
GSdx-ogl is slow,
. gs hardware
. gs software
Ok, that normal. I didn't do any speed optimization for the basic reason that it does not work on amd system and I have an amd system ;). You expect too much, it will take times. By the way did you try the option, maybe you can use native resolution. Anyway for the moment, the goal is to fix emulation glitches.
Thanks very much for the .gs effectively it is very slow!!! I got 254 ms for a frame (ie 4fps!). Which game?
well, I have intel and nvidia, games that were tested and were slow:
Megaman X8, Silent Hill Origins, and marvel vs capcom 2, the others I tried are still bad, but I agree when you talk about emulation errors.
For me ogl is in range from slightly faster than software (NeoGeo Battle Coliseum - just a few fps more) to 3-20 times faster (ThunderForce IV - with software it's average 55-90fps with software and below 30 fps on pre-boss warning screen, with opengl it's 340-590fps during intro movie and about 120-190fps ingame)
But speed is not important atm, i've found some bugs, for example Sengoku Basara X and Hokuto no Ken both show black screen with ogl and fully playable with software (i guess these games use same engine)
KOF Maximum Impact 2 and KOF MI Reg A have transparent characters (you can see background through fighters).
Can you provide me a .gs dump of 1 japanese game (shift f8 then go snaps directory)?
Willianholtz1's dump is very interesting. It uses a feature called destination alpha testing. I think the texture, that contains the value, is flipped vertically. It could explain lots of issue.
Here you go - http://www.mediafire.com/file/9mwiabym66nuc4x/gs_snaps.7z
First dump - Sengoku Basara X [SLPM-55008]
Second - Hokuto no Ken [SLPM-66660]
And if you need ones with software rendering - http://www.mediafire.com/file/a28zxpeccu1o9j3/gs_snaps_soft.7z
Thanks you very much.
I gave a quick look at the first dump. Most the rendering is correct, but at the end a black texture appears from nowhere which is merged with the screen... By curiosity, I enabled "8 bits texture" option but I hit an "not yet implemented" assertion... Before I finish to implement everythings, do you know if you need it on directX?
8 bit textures ? It's not required as i can see, just tested on my wife's laptop in dx9 mode, game shows all memory card/save related dialogs and main menu just fine with default settings ( 8 bit textures off)
You guys have it running? I'm jealous...
None of the rendering modes work for me anymore (see backtrace); That includes the NULL ones.
which gpu? drivers?
By the way I advise you to build GSdx without SDL and to uses opengl render.
an NVIDIA 460GT, the drivers as you can see from the backtrace are of version 290.10.
I really did mean none of the renderers work for me, all of them; OpenGL hardware, OpenGL software, SDL 1.3 Software, SDL NULL, etc trigger that SIGABRT.
I'll see what I can do about not building with SDL though...
Only 3 render works.
OGL/ HW (not yet finish)
I'm nearly sure that you're current wxwidget version is not compatible with SDL1.3. The backtrace was inside SDL, so better drop cmake SDL flags.
Thanks for that, removing "-DFORCE_INTERNAL_SDL=TRUE" from my modified version of the AUR PKGBUILD did the trick.
Made it a lot smaller too...
Now, do you think you can do something about the assert in SetupDATE?
Pretty much all my games hit it at some point early on - makes it near impossible to help test.
Good, that the main reason why I develop the openGL backend.
remove it :p Or uses a release build not a debug one. Assert(0) is reminder for me to finish implement somethings.
With the Willianholtz1's dump I will be able to test and fix DATE but I will need first to incorporate recent Gabest's heavy modification.
@everybody, I remove the assert(0) inside DATE and implement some missing bits. I hope it fixes some issues. At least the dump of willianholtz1 render correctly.
shadowflash, can you tell me if you still have the black screen issue?
Yeah, still black screen in those two games with hardware opengl renderer, no issues with software one.

Revision 5071

gsdx-ogl: linux only
* Was easy, I forgot to set the type of the buffer.
* align shader change too

Revision 5072

GSdx: added a shortcut in GSState::Transfer for the most frequent vertex format
I found (helps quite a lot), less thread-syncing for the sw renderer, and the
bios boot logo was fixed (just had to clear the memory on reset).
Great find with that Sony Logo :)
Hopefully that'll fix the kingdom hearts video border issue too :p
I'll look at the bug we had with Disgaea 2 video borders (still have, the right side is messed).
Maybe we can remove a hack here..
Gabest, thanks, but you have killed the game a new plug-in. God of War and Gran Turismo 4 has graphics bugs.
Thank you again.
Can we see screenshots of the new bugs?
It may be a problem with CRC based hacks..
Playstation 2 logo is always drawn such for several revisions emulator
Problems in games only in progressive video render, plug-in 5072 the same way that hard that the software renderer
All games are NTSC region.
P.S. Gran Turismo 4 on the plug-in version 5068 using the software render generally crash at the start of the race.
I'm not getting any of your glitches but I noticed that the PS2 logo is broken in DX9 hardware mode now. (More than it used to be :p )
(The missing text in GT4 is not from GSdx, that's a PCSX2 issue.)
Also please specify which renderer you used for your broken screenshots.
Confirmed, happens with God of War 1 and 2 (NTSC) (DX9,10 HW and SW).
Ah okay, got to the GoW 1 issue here.
The 'trick' is to have a FMV run first.
This calls GS reset and any 2D elements from then on are broken.
I am using directx 10 ... and the logo are constantly broken. I also checked the HW and SW renderers. Again, only glitches in the progressive mode on the new plug-in.
That's strange, I checked all renderers with the bios and dozens of games, which bios do you use?
Using Europe 01.70 BIOS here, DX9 HW doesn't even show the logo, just fine in DX10 HW. But the DX9 HW issue was not introduced in this revision, not sure how long it has been missing from it.
Sedabi77 care to explain what do you mean by 'progressive mode'? Are you talking about a specific game?
ramapcsx2: Disgaea 2 (slus-21397) here, can't see any problems with warning and the first video. I remember fixing this years ago.
GoW breaks the bios logo! It changes to this at the end: http://s018.radikal.ru/i511/1201/4c/3a4528991fc7.jpg
Seems clearing was not the answere, maybe it has to do with the changing of the display registers or the interlaced mode. Something must clear the memory there. And it may depend on the game, too.
Dude, that's because your bios is a different region to the game ;p dont try to fix it
True, it's ok with the EU bios :P
Still, the in game graphics is missing if the memory is cleared on reset :(
Maybe theres different reset conditions? like soft resets and hard resets or smth. or maybe the memory is just cleared it the resolution changes or smth. Just throwing it out there :P
I use bios usa 2.30 Prior to this release, everything worked perfectly in the game. That is, when you use the progressive in the game settings, all showed no errors. Playstation2 logo display correctly.
Now in the game, I have shown in the picture, there are errors in the mapping. But these errors are only in the progressive mode.
And the most interesting, if you use BIOS 1.60 Europe logo is displayed correctly. But in the game after the regime's progressive image is.
Sincerely Sedabi
Please don't focus too much on the garbled logo for now.
The issue with it is long known to change between BIOS versions and game regions.
Sudonim mentioned that he thinks it's unlikely that the whole GS memory clears on a single register access (the reset call).
I show the screenshots from the game for different BIOS, you asked, I answered vseproblemmy have a new version of GSdx plugin and they appear when you turn on progressive scan in game options, not the emulator, not a video driver, and it is in the game.
I have removed the memory clear in the latest revision, please if it is back to the old look.
Serial = SCES-51135
Name = Primal
Region = PAL-M5
Compat = 5
BIOS: Euro 2.20
This revision (is resonable to assume) broke "Primal" in HW-mode.
It worked fine with r5068 (EMUCR), but not with this one (EMUCR).
The problem remains in r5082.
The menu works fine, but once ingame the screen is all black;
there is no display.

Revision 5073

GSdx: Just some notes on the Disgaea 2 FMV border issue.
Would it be hard to support moving the output area?
Yes, disgaea uses the display registers, and I fixed this already to show the correct area in the videos. Which version do you have rama?
NTSC version.
The problem only shows up when upscaling is used but I figured that it can happen on all games that move the display and expect it to work :p
Now I see it, only on non-native. It is more like an upscaling problem somewhere.

Revision 5074

GSdx: Simplified vertex formats and the related code, everything works with the
basic GSVertex until it gets uploaded to the vertex buffer.
The ConvertVertex function was removed. Since the vertex trace was rewritten for GSVertex, dx11 now uploads the vertex data as-is (UV not moved to ST) and the texture coordinates are picked from the right place depending on FST. Opengl shader should be changed too, if it is like dx11, using the original vertex format.
Now everything is normal again become.
But surprisingly, the europa 1.60 BIOS screen in the game GoW is still green))
The "Playstation 2" after bios goes off center and blurred again.
Negative because of broken lighting effects.
See : http://forums.pcsx2.net/Thread-GSDX-New-DX11-HW-Mode-Issue-on-r5074
nooooooooooooooo, press shift+f8 and make a .gs please
when lot of code changes, it is guaranteed to break something :P
okay on it
forum post updated with the .gs dump as requested :)

Revision 5075

GSdx: quick fix for unreal tournament (and others using DATE)
OK just tested the PS2 bios intro logo again, DX10 and 9 HW modes work fine now, DX9 and 10 software modes get it stuck at the bottom of the screen after it fades out. GoW bug gone in both DX9 and 10.
I made hw-mode remove current the render targets on reset, so it is not showing old video memory, but sw-mode still does, zeroing seem to break games.
Tested a bunch of different games here, all working so far :)
the bug from r5074 is fixed.
Good Job, as always :).
Star Wars Racer (NTSC-U) seems messed up in dx9-11 hw&sw.
Here's the dump http://www.mediafire.com/?5qd6spos2u3skph
*too lazy to make a bug report or register on the forum*
Oh yea, that game looks bad ><

Revision 5076

GSdx: made a little mistake masking the unused giftag regs, when all 16 were in-
Wicked! Fixed Star Wars Racer.
in one of the most recent revisions by you (not sure which one) tekken tag teams terrible graphical isssues were fixed, where parts of therer bodies becoe invisibile :D still slow as hell but now looks proper
probably off topic, but i'd like to note for future reference that Jak games for some reason need to be forced to software rendering at startup for them to load, otherwise they keep spamming "clearing manual block" forever. Oh, and them eyes are always messed up in HW, what about it?
yes i agree with you [email protected]
i always wanted to report about that bugs in jak because this series is one of my favorite games.
soo guys! try to fix it if you can it will be pleasure.
thanks and sorry for my bad english.
Haven't tested any of multitude of new revisions recently, but after seeing jamma's post about Tekken no longer having body parts become invisible I thought a similar issue in Trapt might have been fixed. Unfortunately Trapt (NTSC-U, running in DX10 HW mode) still occasionally has times where models become partly invisible. Easiest one I've found to spot would be the rock from the Boulder Trap when its rolling downhill (slope, stairs, etc) and viewed from certain angles. The bottom half of the rock tends to become invisible though the top still shows normally. I did however notice that Trapt ran ~5-10 fps faster than the last time I had checked it back around ~R4967.
I also decided to check out Front Mission 5 (NTSC-J) and see if that game still had its dirty overlay issues and sadly that game is still all kinds of messed up.
Regardless keep up the good work. Its always exciting to see that new updates are being done. I've also enjoyed reading all the information being said between gabest and others in these GSDX update posts despite 99% of it being extremely over my head.
If anything gets fixed in hw mode, that is accidental. There might be a way to do the accurate software rendering with dx11 shaders, other than that there probably won't be any d3d accelerated improvements until dx12 or something.
I always wondered if any of those impossible blends was possible with Dx11.
Out of curiosity, what's the reason that there won't be any improvements to HW mode? I assume technical limitations with using DX11?
Just curious about this as well. By impossible blends were you talking about the "things going invisible" issues that occur in some games? I noticed that it does seem to happen more often when viewing where models overlap with somethings shadow. Or were you talking about that dirty overlay looking issue with FM5?
I'm not very knowledgable about all this stuff but I do find it all fascinating so I figured I'd ask.

Revision 5077

GSdx: broken frame skipping should be fixed, and a few random sw renderer
ok, tested in my old notebook and when I ran the BIOS the laptop freezes. Windows was Saying that the Video driver stooped responding the goes to blackscreen and freezes all. Btw GSDx was configured in default settings and native resolution.(SSE2 and SSSE3)
My laptop Specs: Toshiba Satellite A-205
Proc: Intel Pentium 4 Dual core @1.7Ghz
Ram: 1GB
Vcard (integrated): Intel express 965 Chipset
OS: Win 7 x86 Ultimate
I know it's old but FFX and FFX-2 still works there with the SVN 4972 without problems
In my desktop PC all seems to work normal.
Is 4972 the last revision not crashing?
OK. So the Graphical Glitch in Dragon Ball Z Budokai Tenkaichi 3 NTSC using frame skip 1 : 2 no longer appears.
But the Speed is slow. In 49xx it used to work (using frameskip) at 83 fps, but in this revison it works at 54 fps (using frame skip of 1 : 2).
Its as if frame skipping is not working at all.
I'm sure no drawing is happening, maybe there was something else skipped but not anymore.
The Graphical Glitch as told, no longer apppears. :)
But what about the speed. Is frame-skipping working?
4972 it was the last I was using because the savestates of 7 games. Maybe and more probable it my laptop that have the problem. In my desktop PC all works good.
GOW orbs trails have bad blending(?). It shows in black since this revision. 5076 are ok.

Revision 5078

GSdx: next attempt to fix frame skipping
Perfect :)
Dragon Ball Z Budokai Tenkaichi 3 NTSC is working now with frame skipping enabled at 1 : 2 or even higher.
Thanks Gabest +1
Failed to build in linux. Missing add info to CMakeList?
-- Configuring done
CMake Error at plugins/GSdx/CMakeLists.txt:172 (add_library):
Cannot find source file:
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
You can remove GSVertexTrace.*.cpp from the makefile, only GSVertexTrace.cpp and GSVertexTrace.h needed.
Thanks for the info. Any chance this solution will be applied and commited ?

Revision 5079

GSdx: fixing dmc3 bugs with the sw renderer in multi-threaded mode.

Revision 5080

GSdx: a different fix for ZoE2, also seem to help DMC, so I removed the previous
one, please check again.
What issue did you fix in Z.O.E. 2?
Background of the main menu, it was looking bad with multi-threaded renderign.
I see. Z.O.E 2 has quite a few issues, three to be exact. I sent you a PM on the forum but I'm gonna post it on here too, if anyone care to fix it or is interested.
1. Lighting issue 1 : This can be trigger after a cutscene-- one during the first anubis boss fight and another inside the Bahram ship with Taper, and more.
Symptoms: the multi-laser shots and the burst attack or energy ball attack has missing effects after a cutscene.
2. Lighting issue 2 : The light is so intense that it can be seen through walls, objects, and/or background. The first few second in my video shows this: http://www.youtube.com/watch?v=iEm091ZhePw
3. Possible memory leak from either GSdx or Pcsx2. For information here http://forums.pcsx2.net/Thread-Bug-Report-Anubis-Zone-of-the-Enders-Special-Edition-NTSC-J
All versions of the Z.o.E. 2 carries the same issue.
Actually, I left out one last issue, but this one is the least of my concern for this game.
4. The left vertical side has a choppy or laggy effect during a cutscene. It seems like it's updating much slower than other areas of the screen. This can be best seen at http://www.youtube.com/watch?v=_9WKr-MOMwM during 6:07 - 6:36

Revision 5081

GSdx: reverted some of the changes of r5077, it breaks GoW.

Revision 5082

GSdx: fix for tokyo xtreme racing invisible letters, laz0rs did not set the
texture size.
Oh and Xenosaga 2 constantly hits it.
Did they hit it pre to the addition of the || TEX0.TW == 0 etc tho? I suspect they possibly did.
Yeah, I'm checking for == 0.
Is PRIM->FST 1? It can only work with UV coordinates, ST is normalized between 0-1, so that needs the texture size.
Oh, and sometimes TEX0 is just randomly set, but not used before another comes with real values.
TEX0.TW = 0 TEX0.TH = 0 PRIM->FST = 0
In both, XS2 and Wild Arms.
Just flukes then :p
When xs2 draws, texture mapping is off., during the intro logos.
Wonder if that causes any unnecessary overhead? :p
This must be the only game reaching the Draw fuction in this state, we should see more missing textures if this happens, and even then it just makes the texture cache allocate 1024x1024 instead of 1x1.
Some dotHack particles are back to normal with this, looked garbled otherwise.

Revision 5083

GSdx: more fun with shaders but nothing works yet.
How Let it work?
How to download this latest SVN version???
@[email protected]
You need to compile it yourself or download the automated SVN build you wish to from here: buildbot.orphis.net/pcsx2/

Revision 5084

GSdx: silent hill shattered memories purple street light fix, not block aligned
filled rects were not correctly masked, may also fix games which store texture
data in the alpha channel but use 24-bit target buffers (or just mask it in
every time) and draw a lot of those unaligned rects. (tested many .gs dumps,
very rare combination)
Gabest, first thanks very much for your exelent work and dedication. Sorry for my question but have any chances to fix the bad fog efect under ICO in gsdx dx10 HW mode? or is it imposible?
Under software mode works perfect (buy slow for mi old computer).
Thank you for answer!
There are things that just cannot be done with d3d currently. We can only hope that the next generation of video cards will introduce major changes, since dx9 it's basically the same.
AVX2 will be interesting as well, I expect fps to go up greatly. It will have gather intruction for texture lookups, can process twice as many pixels on 256 bit, vector shift for a much shorter mipmapping code, this should have all been in sandy bridge already.
Ok! thanks for your time!
Tested a couple issue games but they're all unaffected by this, unfortunately.
I found one particular glitch pretty often, dunno if you've looked at it yet.
GS dump:
This kind of glitch happens in a couple of games, usually the kind where hardware rendering fails pretty hard :p
Yes, the shadows also look like this, also happens in rogue galaxy. Some kind of inaccuracy, I tried to debug it once, but everything looked alright.
Also can be seen in Tales of Legendia on the water and in the first scenes of Haunting Ground.
Ok, debugged it again.
It draws the shadow in 32-bit, then switches to 16-bit, by this separates the colors to low and high words into vertical strips, 8-8 pixels wide. Then copies each left strip as a sprite onto the right strip with FBMSK = 0x03ff, alpha and blue enabled and overwritten. The size of the sprite is 384 x 8, but the part which it copies is a 1/16 pixel longer, 384.0625 x 8, so it shinks the source a very little, and this is because the glich appears.
With bilinear sampling enabled, when interpolating the four 1 bit alpha values at the edge of the drawn shadow, the four values are like 0x80 0x80 0 0, it always gets smaller than 0x80, for example 0x78, and since the frame buffer is 16-bit, the stored bit for alpha will be 0 (0x78 >> 7).
If the source and target sizes were exactly the same, interpolation would not mix 0x80 with the empty pixels, but for some strange reason it still works on the ps2. I tried reducing the blending factor precision from 15 bits, at 4 it looked alright, 0x80 is kept at the edges, but that means only 16 possible shades between two sampled texels. Zooming into any texture larger than 16x would have this effect: http://www.lagom.nl/lcd-test/img/gradient-h-32col.png.
This is the texture: http://imageshack.us/photo/my-images/440/dq8.png/
It stays red where alpha has dropped below 0x80.
Even okami gets fixed by only using 4 bit...
Why don't we have someone who can test things on ps2? :P Just need to zoom into a texture and see if those bands appear.
Galerians Ash (dialog text is missing, sw & hw)
gs file
I can test things on a PS2, no problem.
Just give me exact instructions what to do, and remember that I only have a capture card with s-vhs inputs ;)
mmm i have dragonquest8 original, i have ps2 and i have vga cable for ps2 ( with swap trick method )...
can i test something?
I was thinking of testing custom made elfs, so someone who can test means who can also create little programs, not just to run them :D
We used to do this but it takes a lot of effort.
The SDK isn't the best and we need a couple of hacks to get printfs from the EE.
I still have the setup though and sudo might be able to code what you want, if he wants to ;)

Revision 5085

GSdx: fixing two different bugs of the sw renderer, addressing outside the
texture in region wrap mode (skygunner), and little gaps in shadows and other
random places (dq8, rogue galaxy, okami).
Perfect...Dq8 now have perfect shadows.. good work...
but i have a one question to do: that shadows don´t appear in hardware mode, but why?
I have to add skipdraw lvl 1 to show shadows in Dq8 (i´m using Directx 10.1) .
wow, fantastic work on the SW part :D
Software renderer causes crash to desktop under XP 64-bit. Hardware renderer works just fine though. The changes which cause the crash in the software renderer actually started with r5019. The software renderer in r5018 and earlier works just fine.
Can anyone confirm?
here slow but fine.. nothing crash here , gabest
Skygunner fixed :).
Good Job
Nice work there.
I can confirm that software rederer is broken since r5019 but only when extra redering threds is activated. I have XP 64-bit and a old Phenom 9600.
BTW, Nice work on the GSdx plugin lately! :)
good job.. very nice!
Awesome, that took care of most issues I had.
Tales of Legendia remains :p
That fog texture looks actually worse if water is in the background, but for simplicities sake I did the .gs without water.
I have a small question, probably been answered before, so sorry for that.
I've seen quite a lot of games with fog in HW mode which tears up in vertical/horizontal lines of varying size when scaling is used. I understand that while this may be impossible to fix properly, why not implement a file that applies specific GSDX settings to specific games? That way people will be able to browse through games without having to redo them due to incompatibilities and the such. Perhaps a button in the GSDX dialog to automatically add the settings to that file for the game being run.
There are no such settings, to disable specific drawings you have to analyze the game first, it cannot be done without understanding the GS a little, and a compiler.
You misunderstood me. I was talking about saving the current settings when a game is running to a special file that the game will use every time it started. Not all games like directx10, not all like the MTVU hack. It would be nice to be able to save the best settings for each game and not having to readjust them all over.
ramapcsx2: I could not find the problem yet, but it captures pieces of the screen into a texture in an interesting way that I have not seen yet. Sets TEX0 to load the palette from a 16x16 block of the frame buffer, that's exactly 256 colors, and then draws with a dummy 8-bit texture which have pixel values going from 0 to 255 (row 0: 0-15, row 1: 16-31, etc.). Why they could not just address the frame buffer directly is a mystery.
8924th: I see! Hmm.
[email protected]
You talking about something like this?
I just copy ini-files to the "pcsx2\inis" folder before i start game.
I really prefer an external tool like this to yet another special hacks section.
Gabest: Most likely some form of optimization, I guess.
@drdev: yes, but not as practical as doing so automatically. Might as well reset them myself i have to copy files all over. :P
8924th: Use this: http://forums.pcsx2.net/Thread-PS2Lunch-a-simple-launcher-for-PCSX2
@Gabest Great job on this, as usual. always nice to see plugin optimization.
@pcsx2guide Thanks for the ref link, not actually spotted that launcher before, appreciated.
Whats a ps2 lunch?
^It's a front-end/loader, stores your customized settings for each game soo you don't need to change them each time choosing different game to play. It also hase some additional features added from time to time.
ramapcsx2: ToL might be doing tricks with the TEXFLUSH register, that's the only suspicious thing I could find. Change palette, TEXFLUSH, draw, change palette, no TEXFLUSH, draw.
TEXFLUSH would be very hard to implement properly, but maybe just for the palette updates it is possible.
The shadows in Xenosaga 1 are fixed:)
They had problems?
gabest would it be possible to add in any kind of software render upscale (like how you did on the psx side (for example the character sprites can be unscaled but everything else is left normal)).
That's filtering not upscaling, but it seems it's not as easy with PS2 emulation.
There are three problems currently, ps2 has swizzled memory, bilinear texture filtering, and twice the resolution. With enough thinking and more cpu power the first and the last could be overcome, but bilinear needs a pixel center with a special meaning. To copy one image to another perfectly either the vertex or the texture coord has to end on .5 (psx does not even have decimals in the coordinates). When upscaling this is multiplied by some factor and the you will get broken edges, shifted and blurred overlays. I can only think of implementing some kind of multi-sampling, that does not need messing with the coordinates, just a lot more cpu power and temporary memory space.
In Xenosaga were black lines from the characters corners to the shadows on the ground in HW and SW. Now they are only in HW.
I think the broken shadows in Xenosaga 2 dissappeared but I will test it later. Maybe it happened in an earlier revision.
Upscaling in SW would be nice but I think it is just too slow.
Gabest: I can confirm what Andrian is experiencing with a WoW32 version of wine. Newer revisions crash when extrathreads is greater than 0 whilst using the software renderer. (I checked against revision 4919 and that worked fine with 2 or more threads)
For what it's worth, this is the backtrace for revision 5088 (in spite of what the path says) - http://pastebin.com/PKgu7kN7
I had assumed it was a wine bug as I couldn't reproduce the crash on my Windows 7 installation - http://bugs.winehq.org/show_bug.cgi?id=29645
While you're at it, can you tweak the "Logarithmic Z" option in the GUI a bit for DX9? It's greyed out under wine so I have to manually hexedit the embedded shaders in the DLL to force it on.
martinsc, if you want to get rid of the black lines on character corners in Xenosaga (HW mode), you have to enable (1) the Skipdraw Hack.
Ok last comment: in fact the real solution is Offset Hack used on 2x or more scaling (on custom it doesn't work), because with Skipdraw hack shadows are gone.

Revision 5086

gsdx-ogl: linux only
* implement some missing shader for DATE, invert coordinate like strech
* Use glCopyImageSubDataNV nvidia extension to copy image (you need latest AMD

Revision 5087

Set the EE round mode to nearest for SMT: Nocturne.
Fixes the problem where players can not use ladders mid-game.
thanks for all the hard work
btw afaik ntsc and pal versions of FFX(&FFX Int. and probably all other)
have some problems that can be fixed with clamp mode:
1. enemies facing wrong direction
2. inverted controls in the first room of Zanarkand Trials
I think it should be safe to add eeClampMode = 3 and vuClampMode = 3 to all versions of FFX/FFX Int. to the database to fix them.
Or are there any other negative effects to this settings?
Is there a thread somewhere where games are reported for speedhack incompatibilities? I have another one which doesn't work with MTVU.
grove4l85: Higher clamping will reduce speed, then you'll have to face the countless n00bs screaming MAH FFX IS SLOWWW HALP!!1111ONEONEONE :P
8924th: No there isn't but you could post it in the microVU bug reports thread in the bug report forum...although small chance any of that will be fixed with cottonvibes gone :/
pcsx2guide: seems to me sometimes that this repository is getting more attention than the forum, so i'll just say it here. Digimon World 4 (PAL) doesn't work at all with MTVU. :P
and that's just tough :P if a game doesnt work with mtvu, thats just how it goes :P
refraction: you guys did modify the game database for Nocture to use nearest rounding so ladders will work, so why not "turn off" other hacks if a game is found incompatible? :P
(Speed)hacks are meant for tuning when one's computer is not fast enough to keep up.
They will become unneeded over time, as machines get faster.
What we enabled here is a needed compatibility tweak, without which a player cannot progress in the game.
Though cpu speed upgrades have decreased over the last decade. It seems to be far more about gfx cards these days.
thats why the mtvu hack is so good
Hi Rama !
This fix is very interesting in the way it works.
Is it possible to fix Ace Combat series collision bug with something similar ? Or at least - track down source of this collision problem ?
This just changes the default settings to the ones that work with this game, it's not a new 'fix'. The AC collision problems have been discussed here:
Thanks dude, but I know that forum topic, and this is I who wrote that last note about collision problem. Collision bug still not fixed and I think this revision is close to answer...
As I said before, there is NO code change in this revision. Just an automatic settings change which everyone could already do from the GUI.
Oh my.... I know that this revision has no actual code change in round mode or other important emulation segments !
I'm just asking Rama (and other real coders) to look inside EE roundmode algorhytm and check is there anything what could break collision computation in Ace Combat series...

Revision 5088

gsdx: linux compilation fix. Gcc don't support same name for variable and
template parameter
cmake: compilation fix on debian sid (and potentially ubuntu)
i18n: add some comment for potential language change in the future.
Nice, however a little fallacy:
// The correct fallback for Sami would be
// however, currently wxWidgets (2.9.3) only supports wxLANGUAGE_SAMI.
should be:
// The correct fallback for Sami would be
// however, currently wxWidgets (2.9.3) only supports wxLANGUAGE_SAMI.
Uhm, for the next update...
According to the change log, wxWidgets 2.9.4 (release 2012-07-09)
haven't enhanced the support for Sami or added support for Sorbian.

Revision 5089

GSdx: this should fix xp/wine crashing when extrathreads > 0, and added a sprite
drawing shortcut, hopefully won't break anything.
Am I doing something wrong? On my system (XP 32-bit SP3) this revision keeps on crashing with extrathreads and now it even crashes using the usually safe 0 setting...
I found out that if I use the Pcsx2 "fast start" option it doesn't crash even using extrathreads, instead starting with the "complete start" Pcsx2 always crashes on every (included 0) extrathread setting (of course using software gsdx)
Found it, little mistake :P
Any change you were expecting from the sprite shortcut? No errors on the sprite games I checked, nor speed difference.
It's for simple image copying. I removed the conditional jumps from WritePixel when I'm absolutely sure no pixels can fail any tests. It should be slightly faster, even though that I found such sprite drawings are mostly limited by memory access.

Revision 5090

GSdx: full boot fixed, thanks for finding, I always use fast boot.
Can't get to download this revision properly from svn section of main site (try to check it, file is 0 kb and damaged)...anyway I trust you that it is fixed:-)
where from? the buildbot?
hm, the buildbot looks to be broken atm: "Unable to open the svn log file rev/svnlog.xml"
It's fixed on Win7 at least.
Working on fixing the buildbot... Don't hold your breath though...
Fixed !
That was fast :p
Out of disk space !
So I just removed about 15GB of Jpcsp builds ;)
[email protected]
Insufficient disk space> <
Just simple question... the new releases has all previews releases modification?
exp: You get the last release and do your tweaks ?
The buildbot version is exactly the same as if you had downloaded the source code for r5090 and compiled it. No change, no tweak. Simple as that.
And yeah, every new revision builds upon the last.
A change made in r4000 will be in r4001 and r4002 as well, unless one of these revisions undid the change.
Hi Gabe !
Killzone still broken in SW renderer.. Hardware works OK, but without postprocessing.
When Killzone crashes, console says:
GSdx: out-of-memory, texturing temporary disabled
Thanks for answer my question
The logo is still glitchy in PAL games, looks perfect in NTSC Games though.
@[email protected]
Thank you for the buildbot, Just wanted to say that.
I got some awkward value in texture, the height is 0 (in GOW start game menu)! Technically, in GSRendererHW.cpp:300 => m_vt.m_max.p is 512,0 so it seems to be related in VertexTrace. Note my CPU only support SSE2, it might be different in SSE41 code path. Do you have the same behavior on Windows too?
Which texture height? I guess it is not TEX0.TH.
No, it is a GSTextureOGL. If I understand correctly the following code compute the minimum size of a render target based on the vertex position (clamp on the scissor).
GSVector4i r = GSVector4i(m_vt.m_min.p.xyxy(m_vt.m_max.p)).rintersect(GSVector4i(context->scissor.in));
(gdb) p m_vt.m_max.p.f32
$7 = {512, 0, 0, 0}
(gdb) p m_vt.m_min.p.f32
$8 = {0, 0, 0, 0}
(gdb) p context->scissor.in.f32
$10 = {0, 0, 512, 448}
For information, GSVertexTrace::FindMinMax gives m_max.p.y == 0
p primclass
Gabest, I wonder if you noticed my comment above.
PS2 Logo is glitchy in PAL Games, can you confirm that please?
gregory.hainaut: it is a line between (0,0)-(512,0), I think we should extend it by 1 pixel in every direction for points and lines. The sw renderer does GSVector4i(m_vt.m_min.p.floor().xyxy(m_vt.m_max.p.ceil())), still not enough for such a case.
kimokimo1: refraction said once that the pal bios was broken, when I checked it the texture was not present in the video memory anywere.
Gabest: I'm using US Bios.

Revision 5091

GSdx-ogl: LINUX only. sync from trunk (5068:5090)
Note: code still need to be updated with latest rendering improvement.
How to download this version?
This is a branch, you need to checkout the specific branch and compile it yourself. If you don't know what I just said, you can't :P
svn checkout http://pcsx2.googlecode.com/svn/branches/gsdx-ogl pcsx2-gsdx-ogl
Then you can select the version with
svn update -r 5091 pcsx2-gsdx-ogl
Be aware that this revision won't even compile. I'm in process to fix it but it would take some times. Well actually I have already a patch but it crashes when I upload the vertex...

Revision 5092

Not transferring unused vif registers to the MTVU thread can save at least half
of the ring buffer space. The whole set is about 400 bytes, including padding,
but I could find references to only 6 regs.
oh nice, will this improve speed, for mtvu hack? or is it just more efficient?
Few games which use very small packet sizes have less overhead. If I set the renderer to null I can notice about +5% fps maybe.
Hey, nice job there.
This change helped my dualcore in Xenosaga by 10% :)
The speedup is noticeable in all my games, from 2 to 10%.
This suggests that there's more to be had in this direction, methinks :p
from 2 to 10%? awesome!, this should be the biggest commit after the hack of cottonvibbes. Thanks gabest11.
Goodd work friends!! This mtvu hack could be to 2 cores too.
great release!
Good work! Im sure this could be reduced further. Only num needs to be written back really (as this decrements as it does the unpack) all the others don't change during the unpack.
Also col/row regs only need to be written back if Mode is set to something other than 0 which is the most common setting.
Infact Col doesnt even need to go on to the thread unless mode is set to something other than 0, possibly only if mode is set to 2 (cant quite remember when col is used)
Okay just checked it out.
Mode == 2 requires row writeback, others only read from main thread
Mode == 0 requires col to go across but not back again, other modes don't require col
Yay I'm being a tit! Its mask 2 that needs Col, sorry! But yeh row writeback still requires mode 2
Indeed. (What? :p )
As you guys know, VIF is slow. So doing less work there when possible should always be a good speedup.
Tell me if you need something tested / verified :p
A nice speedup!
Good work!
Rama: we could probably have flags for it when we set mode and mask saying I'd we need row write/ read and Col read, would cut down a few bytes :p
You get the speedup only if MTVU is enabled in hacks section?
Markwrst: yes, as implied it is for mtvu only
There is a lot of event ping-pong going on in MTVU and MTGS, I'm sure that could get a similar speedup with conditional vars as gsdx.
This scene is bothering me the most currently: http://imgur.com/mLIwl
Only 15 fps with the null renderer. (it gained about 1 fps with this change)
Yeh sotc is evil l, just put vu cycle stealing on :p
Right. This game is essentially overburdening the real PS2 as well, it just makes up for it by running at a really low framerate.
PCSX2 timing isn't exact enough so it renders faster than it would on a PS2.
I used to try getting the timing more correct, then someone will come along and complete rework of something which has zero timing and make it thus so it can never have timing! ;p
Excellent work Gabest, many recent SVN comes with useful speeds that many games takes advantage, one of them is MGS3 but in this svn have an issue,when you start the game, some backgrounds of the intro screen are missing like this http://imageshack.us/photo/my-images/818/piciv.png/
tell me if anyone see the image and also, if anyone have the same issue with this game, thank you so much and keep up the excelent work :)
Anyone else? I can't repro, there is always something in the background, first time I noticed it changes.
if you wish, I made a pickup with another version to see if happens the same, if its true, don't worry for that :), and in mgs3 you do some superb improvements, 5-10% speed improvement in cutscenes and gameplay, good work :)
gabest, in r5090 happens the same, so don't worry, my mistake
I truly see an issue but in ff12, in gilgamesh's battle that the shadows messed up, ill make a pic for that if u can fix it, I'll be very grateful with you, thanks :)
look gabest, in hw mode, dx11, no hacks http://imageshack.us/photo/my-images/402/picfinal.png/
in sw mode, dx11, no hacks http://imageshack.us/photo/my-images/600/picfinalsw.png/
so thats it, thanks for your hard work :)
Ow, we had that Final Fantasy issue before.
Is the hardware screenshot done with upscaling? If so, is it done with the custom upscale option? (That might be the problem then.)
Ref: There's too many chips involved, including the full GS which never had any timing either ;)
rama, its true, i use a custom upscaling in my gs, 720p (1280*720), so that issue could fix if I let a native resolution in gs plugin? or it could be another posibility?
thanks for the advice :)
PD. my gfx card is a 6850, 1090t proc (this info could be useful :) )
Rama and the others, in hw mode with native resolution still have the same problem, with sw mode shadowing problem's dissapeared, take it in mind for future revs, thanks for the help :)
Getting nice speedup from this. GTA LCS which I always used as a test game due to its general slowness got nice 10fps speedboost no joke. I say these kind of experiments need to get even further and it'll be really close to having every compatible game really playable. Good luck!
It's unrelated but maybe you're interested in looking at the shadows problem in Silent Hill Origins.
The software renderer seems to have a precision problem again, maybe similar to the DQ8 shadows glitch.
GS dump:
First image is rendered from the point of view of the flashlight, its alpha channel is turned into a texture, then alpha blended with the second using the "(0 - Source) * Source Alpha + Dest" formula (Dest - Source basically). The difference of the two image is off by 1 in a few places and leaves those diagonal marks on the wall. Difficult problem.
The pictures are swapped, I thought I uploaded the texture first.
Funky trick.
Could you check this with the SSE2 build? I think it is the evil pmulhrs unstruction that rounds its result, I use it to interpolate the texels when sampling is bilinear.
Also fixes the intro of mister mosquito.
Can i ask a little question?, what's the meaning of "Out of memory while allocating 'ELF headers':(pxActionEvent) Called from 'SafeArray::ctor' [size=-1](thread:EE Core)", its a little question... thanks :)
w0w this is awesome i got 40fps speed up on valkyrie profile DX11 Hardware mode 3x Native @ 2.6Ghz Athlon II X4, HD5770
Please bring it to the forums at http://forums.pcsx2.net/index.php
It shouldn't be that high but if you see an increase like that, nice :p
Tried SSE2 release and debug and got the same result :/
Killzone still broken in SW renderer.. Hardware works OK, but without postprocessing.
When Killzone crashes, console says:
GSdx: out-of-memory, texturing temporary disabled
Something allocates too much memory in Killzone, even if I switch to the null renderer.
Just start a new game, after it tells you to press R2 to fire turn around with the right analog stick and watch memory usage going up in task manages.
Where is the edit button?
"Thou shall not edit" said google. O.O
PS: Gabest, your commits turn into forum threads. XD
Very nice update. Considerable speed in many games!!!!!!
Gabe, Killzone with HW mode works fine. This problem only in SW mode.(strange...)
And looks like this bug only in latest revisions...
It leaks memory in every mode, only in hw mode gsdx does not use that much system memory and it takes longer to run out of it. Start spinning around at the start and watch memory usage in task manager, every second it adds about 3MB.

Revision 5093

linux compilation fix

Revision 5094

GSdx-ogl: LINUX only
* Use the new map interface/separate texture coordinate inside shader
* support new format on texture
Note: it is quite instable with various crashes and GL error but at least it
compiles now :p
I will test then put something on it!
don't expect too much. It will probably crash on Nvidia too. With latest Gabest changement, some texture have a heigth of 0... I'm don't know if it is expected or not. If your CPU is compatible maybe you can enable SSE4.
With this "upgrade" I could see performance gains in hardware mode, but I can not tell which was build, because it was a time that did not update. But still getting this great work.
I played about in SMT:Nocturne for a a few minutes, I didn't get any crashes... until I hit F3, at which point glibc detected a double free: http://pastebin.com/adFanzGz
Honestly I'm surprised it did not crash much more! By the way, is the F3 crash 100% reproducible.
I can reproduce it, but it does not happen every time. I'd wager it happens around 2-3% of invocations.

Revision 5095

GSdx: Offset_UV can be defined again. (Need it to hack Wild Arms 3 text
placement issues)
Not the best way to offset UV, it can be set from other places too. And it affects all renderers.
Yea but it's simple to do it there.
In all the other places it was hard to do 1-2 years ago :p
I'd like to see your recommendations though, if you feel like hacking a bit :p
I could take a look at it, since I think I'm getting better at GSdx hackups. XD
Maybe some CRC thingy and only for HW when in not native.
What is it supposed to do? I don't see any difference in text. =S
From your nicer 0x3FEF3FEF version, and a long trip through docs and registers... the better place is on the shader. =_="
tfx.fx, line 623-ish, output.t.xy = (input.uv & 0x3FEF3FEF) * TextureScale;
Shouldn't be hard to also add it as an option to the hacks section. (is getting popular that pace)
Nice try I gave the shader mod a try but it seems to cause the characters to strangely glitch with it (alter code f, 3), it does fixes the text though..
rama's mod doesn't cause the character problem maybe it can still be fixed in the shaders.
Yup, effectively kicking out the poor Number 16 from U and V. Magic evil number, and no idea how rama found it. It works fantabulously though.
@konaj: It could made to be triggered by only certain conditions. Like the spritehack, to narrow its effect.
There, now's an option (patch included). No extra conditions though.
Updated: http://www.mediafire.com/?jqtjw33d27em56b
Now's a three stage thing, with the full option being the 0x3FEF one. The new middle option is 0x3FF7 with the following effect:
http://i.imgur.com/vsPWh.jpg (HW Native)
http://i.imgur.com/wNMtZ.jpg (HW x3)
http://i.imgur.com/49SMn.jpg (HW x3 + Wild Middle)
http://i.imgur.com/X00wb.jpg (HW Native + Wild Middle)
Not bad me thinks.
Indeed it seems to fix all but one of the weird transposing spites Gust games seem to have. What does the full hack do there?
Full fixes Wild Arms text.

Revision 5096

GSdx: this may fix silent hill shadows and mister mosquito intro blur, also
reduced texture cache keep-alive time from 30 to 10 frames and found two memory
leaks, killzone can run a few seconds longer before crashing, I think there is
something in pcsx2 allocating too much memory.
Mr.Mosquito is definately fixed!
Ohh and why ICO NTSC doesn't pass through sony trademark screen!
If possible of course.
Sorry about the complains in where but maybe this way somebody see it.
@8924th + f3r... : I think all that is better suited for the forum instead.
@KrossX3: well obviously, but i was hoping someone would provide a quick answer without the need of extra hassle. I'll make a thread anyway.
Ok. I'll delete the comments later, but I hope gabest11 notice it. I highlight him cuz he's on the spot lately with all this awesome improvements in GSdx.
[email protected]
no. i cheked now the jak 3 shadow projection and is not fixed but it
dosent matter because you can use the alpha hack or just add few number to the skipdew hack and the shadow will get off
thanks for the great releases and sorry for my bad english
f3r.DLK: There was a CDVD update breaking it, ask rama about it :D
r4952 I think
I forgot :p
Wasn't it some non-issue anyway?
Checking the SH:O shadows :p
Shadows still look bad here, using SSE4 release.
After that update one region boots the other does not, you said it was a memory card problem, but does not seem so. I think I even uploaded the iso of the broken version for you.
The gs is fixed :D Is this silent hill origins or shattered memories?
hey gabest and Rama, i wanna help u with some pics if you let me :D, in ffxii gilgamesh's battle the shadows doesn't look like older revisions, so now, the shadows looks rectangular and less messy, look the pic plz (could be useful)
I think that the shadows looks less spiky, in the area where you are modifying the code, would be the answer for the ffxii's issue, indeed, thanks as always for your effort :)
I browse and build some revs and the last one I could play ICO NTSC was r4960 so r4961 broke it.
yep that's the one!
If you rama could take a look at it when you have the time it would be nice, for the sake of this great project of course ;)
[email protected]: is this hw mode?
gabest: yessir!, with 3x escalation, dx11, SSE2 (AMD), anyways, with native res in hw mode still have that issue, in sw mode that issue dissapeared, like AC issues...
i saw that meanwhile the battle, the black rectangle moves when gilgamesh moves, i mean, if he see toward me, half of the scenario turns black, I let you two pic to see with detail the situation, and im really happy to help you, sorry for the inconveniences...
here's the pics:
Thanks :)
Gabest: I remember about ICO now. I could reproduce it on my PAL copy.
The thing is a random fluke (which should still be investigated / fixed, of course). Simply change the PAL/NTSC framerate a bit (need a PCSX2 dev build) via the options and it works again. The problem is very likely from missing timing due to the IOP rec.
That said, using IOP interpreter should also fix it for now.
I've noted it in my todo.txt for later..
The shadows in SH:Origins are still looking like this:
Gabe, Killzone with HW mode works fine. This problem only in SW mode.(strange...)
And looks like this bug only in latest revisions...
...just to let you all know...Panzer Dragoon is now FULL SPEED. :D I don't know what you guys did recently but the game no longer suffers from drastic slowdowns.

Revision 5097

GSdx: there was a float-int conversion overflow in vertex trace, texture coord
min/max could have been detected wrong, silent hill origins should look better
Right, that took care of it :)
I can still see some errors when the light is almost perpendicular to a surface, but mosly fixed. http://imgur.com/DHD8T
These new silent hill games are looking very nice for a ps2 game, that's what I was thinking when I saw shattered memories and origins. Then I went to wikipedia to know more and that's what it says: "The PS2 port received slightly lower aggregate scores, owing to lower-than-average quality graphics for the console, and some camera and control issues."
Left from youtube, right gsdx.
I was wondering if my resizer was broken or the map looked that bad, but just the analog signal hides it really well by bluring. See the I in CRICHTON St. for example.
The colors also look different a bit.
The color tone is way nicer on youtube, yea.
That could be the result of lots of things though.
A shader for common color controls in GSdx would be nice for this :)
(That Chinese GSdx version called 'shadeboost' has that, and it's very nice.)
I tried changing saturation myself, pink becomes red, but not orange. It's some kind of NTSC color tone on youtube.
I can still see some errors when the light is almost perpendicular to a surface, but mosly fixed. http://imgur.com/DHD8T
These new silent hill games are looking very nice for a ps2 game, that's what I was thinking when I saw shattered memories and origins. Then I went to wikipedia to know more and that's what it says: "The PS2 port received slightly lower aggregate scores, owing to lower-than-average quality graphics for the console, and some camera and control issues."
too bad Silent hill origins ingame Vids still wont play unless they have been fixed without my knowledge and the same for other games with the same issues aswell
Speaking of shadows... I have no idea if it's related to this issue or not, but in Vexx parts of shadow on certain surfaces are missing in software mode, but everything seems fine in DX9 hardware mode.
http://i.imgur.com/yvjC3.png - sw
http://i.imgur.com/krw0w.jpg - dx9

Revision 5098

GSdx: fix for Vexx, a few vertices were bogus, s/t/q all zero.
On the shader subject (sorry for offtopic :p), seems KrossX is working on that:
I found a similar problem in Ratchet & Clank
I'm seeing some weird borders on sprites (like when walking) in SW mode since r5097. And I think it was noticeable in HW in last revision with some quality problem, now's fine and just in SW. (or maybe I'm just hallucinating)
shagkon: no idea yet
KrossX3: small problem, fixing it
Gabest, I've heard that Insomniac and Naughty Dog shared technologies. Shadows in Jak and Daxter games aren't emulated properly even in software mode. The bug looks different but maybe these games have something in common:
BTW, could this be a PCSX2 bug?

Revision 5099

GSdx: check sprite edges! (r5098)
Ha! Fixed! =D
Yakuza2 has had a black mini map in gameplay and some glitches in open cg using both hw and sw mode since svn 5080,anyone have any idea what had been broken in gdsx plugin?
The only change in that revision is some SSE4 code path, could you check with the SSE2 build?
lovecf4444, could you please post a savestate (or better, a memory card with save) at a point which shows this bug? Yakuza 1/2 have some CRC hacks already in place, so it's possible that recent GSdx changes modified how the hacks affect the game. You can use mediafire.com to upload it.
I have black mini map ingame and some black streak (when start loading or finish loading) in Yakuza 1 and 2 too, which ver dont have this, i have r5087 so i guest this issue definitely in 5087 to 5099, i do not test in pre ver yet?
I have that issue right when start playing game, in every chapter, so i think no need savestate at all.
in HW mode map it full black, but black streak it less (start and finish load its show up), switch while in game to SW mode, the map show but not normal and more big black streak.
you do not need any save to find out this issue.using svn 5099 and gdsx plugin,you will have the problem when you start to play from the beginning.
r5082 broke Yakuza.
r5081 is fine.
Minimap wasn't black in my test, but those yellowish triangles shouldn't be there. There is also another bug. Take a look a these 2 screenshots:
Oh, I tested this game in sw-mode.
@shagkon: in SW mode i have a same graphic like you, in HW mode map will be black. so r5081 dont have this, right?
OK, I can confirm that Yakuza 1 (tested NTSC) and 2 (tested PAL) are currently broken, and it's fixed if I revert r5082 using:
bool yakuza = (m_game.title==CRC::Yakuza || m_game.title==CRC::Yakuza2);
if(TEX0.TW > 10 || (!yakuza && TEX0.TW == 0)) TEX0.TW = 10;
if(TEX0.TH > 10 || (!yakuza && TEX0.TH == 0)) TEX0.TH = 10;
(instead of:
if(TEX0.TW > 10 || TEX0.TW == 0) TEX0.TW = 10;
if(TEX0.TH > 10 || TEX0.TH == 0) TEX0.TH = 10;
However, I can't tell which of cases is the more generally correct one (i.e. whether Yakuza should be the exception or tokyo xtreme racing). So unless a more generic fix is found, I suggest to make a specific exception as required.
Also, this is unrelated to the CRC hack (the glitches show with or without it), and it affects both HW and SW rendering.
Hmm well telling it that its the Max size instead of tiny is quite hacky, I wouldn't be surprised if that was causing problems. Or is this just sizes for the cache?
When FST == 1 the size can be set to 10, UV are absolute values, but yakuza uses FST == 0, so ST are normalized and get scaled up by the dimension when sampling the texture. The simple solution is to add && PRIM->FST == 1.

Revision 5100

GSdx: Yakuza fix.
Thanks. Also, other stuff which got broken on r5082 (menu selection background was almost invisible, and diagonal-ish glitches over FMVs) are now fixed too.
Thanks,yakuza fix confirmed.
> Tokyo extreme racer stop working on this build , leaving a black screen
> after intro logos.Is there any correlation between this issue and the
> yakuza fix ?
The .gs I received still works, no idea. Going to find the game and see. NTSC or PAL?
Which one is it? 3, drift, drift 2, zero?
Slus_201.89 this is the version i used to test.
I run killzone in HW mode and turn off speed hack but i still get screen freeze ingame. Everything ok except the screen of game freeze, i still heard sound, footstep and gunshot. I check back few revision and you guy said HW mode its ok:(
another problem is when i just ingame a few second, the game still can quick save but a few second next, i try to quicksave but pcsx2 turn up:"oh no, out of memory". I used win 7 64 bit, so maybe that's the problem?
This is NOT a help forum and any posts asking for help will be deleted. If you want help with a game, post in forums.pcsx2.net.
This place is for reviewing code and reporting bugs (properly, not OMG my game no worky111!!!)
I post it in forum but i dont have any help because i "dont use SW mode, still turn on some hack... even download crap pcsx2 in unknown site". I dont need help, just want gabest check this to make this emu more and more perfect. So keep delete if you have to, because maybe, i hope, gabest will recognize this problem.
What you posted is not a bug report, this is why they told you that in the forum. Learn to make proper bug reports, else gabest and everyone else will just ignore you.
i turn skipdraw on so does it count used hack?
"Bugs are things that do not work correctly in the emulation process", your video in game freeze but still heard voice, still can control, and its not a proper bug?
It IS a bug, your bug REPORT is not a report thus it is useless for anyone who wants to try and fix or find out in which revision it was introduced. And yes skip draw counts as a hack, that's why it's in the HACKS section.
[email protected]: That message appears when the emulator has ran out of available memory. It means that some game is causing a memory leak to occur within the emulator and it keeps accumulating memory that is not freed, thus the system terminates the emulator to avoid further problems.
Not much you can hope for in this case, Midnight Club 3 also has the same (probably) problem. Be patient or play some other game. :P
I read in forum is said speedhack, i thought its a graphic fix more than a speed hack. But if i dont turn it on, the system will crawl with it, so im so confuse about what option should be set.
Play with crawl system or with freeze like that? I dont know:(
8924th: Thank you very much:) I just want to know that everybody else had the same prob like me or my hardware bad:)
Which had absolutely nothing to do with this revision. Soon as one stops commenting a new one pops up /facepalm.
I just passed by here to say: WOW! This latest improvements on GSDX REALLY helped Ratchet and Clank Series by A LOT. Before i could play them at full speed only with frame skipping 1 / 1, and even with that it would came down from full speed due to some sort of bottleneck, but now. WOOW. It runs over 50 FPS, some parts even faster, way over 80 FPS, WITHOUT ANY HACK OR FRAMESKIPPING! (The only exception is MTVU hack, to use 3 cores, but even without it its full speed (except in Ratchet Gladiator, there it drops to 44 FPS in heavy scenes due to EE thread maxed out at 100%)). (Software mode - i7 2600K @ 4.6 Ghz). Seriously, congratulations on this! Keep it up, awesome job!!
[email protected]: I found the problem of tokyo xtreme racer zero, but then I noticed that the car was not looking good, too bright. The environment map texture constructed to reflect the surroundings is getting brighter with each frame until it gets pure white. The alpha blending formula is src * srcalpha + dst, and it is never cleared, that means in each step "src * srcalpha" is added to the texture and becomes 255, the max value. Yet another puzzling bug.
This is a little bit complicated for me to understand but I am glad you have found the problem.
Love: Think of it as a number that keeps going to its maximum, thus resulting in white texture.
thanks ,i think i got it somehow.

Revision 5101

Committing a hack KrossX prepared (thanks) ;)
It can be used to fix bad character sprites in Gust games.
I guess Issue 428 is fixed now? =D
Keeping the issue as the bug still should be fixed :p
This hack no fix TOD
Yup, it seems ToD doesn't trigger it. I'll check on it later.
It seems to diminish but not fix the errors in Atelier Iris as well.
@okuha: remove the check for TEX0.CPSM == 2 and it will work on ToD. Since ToD seem to always use CPSM PSMCT32.
Removing it will make it affect more cases in the other games though. ToD uses PSM_PSMT8, PSM_PSMT4 and PSM_PSMT4HL but luckly the sprites during combat are PSM_PSMT8.
Fear the random downvotes! :p
Indeed you'd think they'd at least have the courtesy to tell you what is wrong. Or maybe you just didn't fix what they wanted fixed right now...
Oh noes! I ish so sad now. ='(
I think it might be related to some Sakura Wars game perhaps.
@Dra: If you can post a gsdump (shift+f8) from that game where the lines are obvious, it would help to check out that game in particular.
scraggles80 is the new rookid??? o_O
God job guys!
It's mostly on the portraits and backgrounds. I think not filtering 2D fixes it but I'll get you some screenshots and gs dumps hopefuly in 4 to 5 hours if I get off work on time.
Here is a rar of 3 dumps and their screenshots with the spritehack on at the beginning of the game. I can also take some with it off if you need that as well.
I'm afraid that's just a side effect of forcing filtering. Except the portrait lines, those are just weird.
This hack is for the following case, where filtering is natively used (SW, HW, HW+SpriteHack, all in native):
http://i.imgur.com/Ebjf1.jpg | http://i.imgur.com/ccG1j.jpg | http://i.imgur.com/owQSG.jpg
You could try enabling 8-bit textures along with the sprite hack, since that would also enable the "nice blending" hack that got sneaked in on this revision. =P
Might help on some lines, but really you should just stop forcing filtering and use an AA shader instead or just leave it as intended.
Ha I guess I got caught up in your efforts to clean up filtering in the other thread and didn't realize this was for sprites only. It does help clean them up a little though.
Ha I fixed it. Completely pointless as by the point I finally fined it was Halftexel*(64.0/4096.0) but I was just tinkering by that point.
I might be completely wrong, but I think HalfTexel is only used to get the derivatives for the 8bit mode bilinear. So with that you would be near the point of having filtering disabled in 8bit mode. >_<
I noticed that it was becoming more and more unfiltered which certain levels created a nice effect others not so much. I did a little tweaking and the threshold is somewhere between 128 and 96 but as you said since it was less filtered there was really no point to go on further. I wasn't sure if it was lowering the threshold of what gets filtered or shrinking the radius of the filter though. Unfortunately no such luck in playing with shadow hearts even 64 had no effect there and I really didn't see the pont in going lower though that 2d background could be bypassing that section of code for all I know.

Revision 5102

Small mistake fixed.
My bad actually. I did that afterwards but I think I never posted that patch. Oops. =P
Sudo spotted it :p
where is the link to download please??

Revision 5103

Removed the mVU block hack. This hack didn't help speed a lot (generally only
about 2% if at all) but it caused slow downs and bugs in some games.
People enabled it for a performance boost and often got the reverse, so now it's
Glad to see that option gone, I never really used it since I know it causes alot of problems in games from crashing to texture glitches.
The only other problematic option is the EE/VU Stealing options since the max values only cause slowdowns. (maybe a limit at a lower value would be better)
Well, the cycle sliders affect games differently.
I have games that react drastically to a low setting and others that don't seem to change even at max values.
Those hacks are bad in any case but they help with games where we fail to time all the PS2 chips to behave exactly like real hardware would (Shadow of the Colossus).
I'm afraid we'll have to keep them :p
well i like the ee cycle rate hack its great helps alot with speed
Didn't the block hack help with Persona 3 and 4 quite a bit, specifically with the classroom slowdowns? Or maybe I'm misremembering, it's been a while.
Nah, it always was nearly not measurable for me.
It used to be more noticeable on AMD processors but that was back in 2009 or so :p
But Van Helsing still isn't working :/
and that has what to do with this revision amipc?
"it caused slow downs and bugs in some games." i thought that when its removed Van Helsing will run again but not. Also removing it didn't change anything in games i tested since i downloaded it.
Still i wait when somebody will do something that Dead or Alive could be run and Terminator 3 Redemption would be playable on newest revs not on the older ones.
It will come, just give it time. Hell, I've been waiting to play Dark Alliance 1 & 2 on pcsx2, but I have hope & patience that it will happen someday.
Just hoping or bringing it up constantly doesn't help much guys.
We could use some nice clues as to what goes wrong, or when something stopped working.
Ref: Got my email? :p
There are still some speedhacks left which aren't helping alot.
For me it's just MTVU and the default ones like INTC Spin detection and mVU Flag hack.
and fast CDVD doesn't change anything at all.
I was giving u clues writing in which revisions it stopped working but i was laughed at so i fuck it gently now ! Do it urself !
Yea, no then :p

Revision 5104

GSdx: KrossX updated the sprite hack to also work on other games with a similar
problem. It works with a 3 state checkbox now. Try to use full when half checked
doesn't fix your game.
Great works!
Any ETA for external shader integration? :p
Go go KrossX, you are the best :troll
Salu2 - Darkness Knight
Rrrrright... =_="
This was mostly to get the hack working with Tales of Destiny. Which was the other game I had in mind when making it.
@zwei: I think that would only happen when it stops being a mere abuse of the FXAA setup. XD
A gui integration of that would be nice :)

Revision 5105

Attempt to fix ICO NTSC CDVD flag bug that appeared in r4961.
Works with my copies of Time Crisis 2 and 3 as well.
yep everything seams to be for ICO NTSC and the other games that I have, but the Time Crisis games I don't know cuz' I don't have them!
Nicelly done!
TC2 and TC3 are fine. Glad they didn't get broken again. :P
CDVD_STATUS_PAUSE makes sense in this state.
I'm really just guessing at this point though :p
thanks look forward to ico again :)

Revision 5106

i18n: refresh po/mo
Thanks :)
I would really like an update of my sv_SE translation.
The diff is quite big now.
done ;)
I would like to update my tr_TR translation, but I don't know how to, as I don't compile PCSX2 myself, I don't know where to get these .po files. Is there any chance you can update Language/Translation Templates at Downloads section?
you can get all latest translation sources with a command like that:
svn checkout http://pcsx2.googlecode.com/svn/trunk/locales/tr_TR translation
Later you can update to latest source with the command "svn update"
You can use toitoise svn or any svn tool.
Just edit the po file and post them back in the forum.

Revision 5107

i18n: new language indonesian
I live in Indonesia and Bahasa is my specialty.
glad to see Bahasa was being added to the list of language in PCSX2.
cannot wait to spread the news to my community.

Revision 5108

i18n: update sv_SE too ;)
can you somehow try finding somebody that knows hebrew becouse i am israelian
and i dont know read english well.
thanks for the replay and for the great job

Revision 5109

A couple minor changes, including a bad looking block manager bug that wasn't
really all that bad :p

Revision 5110

GSdx: Added the color control functionality known as "ShadeBoost". Thanks to
KrossX for initial converting / GUI work and Pseudonym for normalizing / fixing
the maths.
Note: Not sure if it should be shader #7 or smth else :p
StretchRect(m_current, sr, m_shadeboost, dr, 7, false);
^ This #7
I'm not claiming to have actually reviewed this patch BTW, I just fixed really obvious bad maths. The code is still horrible.
Note: Not sure if it should be shader #7 or smth else :p || My thoughts too. XD
@sudonim1: I still dunno if those numbers weren't actually what made the "cutie" version... "cutie". But I cannot check since the resource seemed encrypted or something when I wanted to confirm.
Other than that, the code could've been checked more to make it stop being so horrible. >_<
Hi,guys,Wanna some help?
Nice :)
Are you the person who originally added this?
If so, we tried to contact you before but were ignored.
The code is fine, it's just too much duplication of already existing stuff :p
The shader# seems to point to one of the generated shaders of convert.fx, being 7 the ps_main7 one; ps_main0 seems a better choice though.
I've tested it now and I think only saturation is working closely to what I would expect from it. While Brightness and Contrast are doing whatever.
I think this needs a new shader altogether. It certainly ain't something hard to do now at least.
Muuuuuuuch much better => http://pastebin.com/DRDCXiGn
Me like it, lots.
Yes,I am the guy who originally added this.Wuould you like me to join your works?
@ACOMPALSOFT: You should really get rid of the spam in that forum. Yup, yup.
Thanks, this seems to work better for contrast here.
Sure, could you share some of your code?
Ideally via patches on pastebin.com, as KrossX3 did earlier :)
Of course,I already shared the codes last year.Even send them to your guys in the pcsx2 official forum. Maybe KrossX3 is right,I needs to get rid of the spam in the forum.
Give me a email addr,I will send the codes to it.
Can you register on our forums and send me a private message?

Revision 5111

GSdx: Use the simpler psmain0 shader in convert.fx for ShadeBoost. Thanks KrossX

Revision 5112

Null pointer protection and warning in LilyPad and SPU2-X savestates and a small
init fix in SPU2-X.
Hi rama !
I've tested this revision and found out that there is synchronisation bug in SPU-X plugin in async mode. Before this revsion sound in FM5 was timed correctly in Async mode and overall speed was 100%. In current revision - video runs ahead of sound. I never use timestretch mode because it slowdowns Emu about 1-2% and real PS2 sound works in async mode.
So - is it possible to revert or fix SPU-X plugin in async mode ?

Revision 5113

Better working shader for the new color settings. Taken from "TGM's shader pack"
you know i wanted to say that you can do the commend: allowhack=1 in the gsdx ini as a default because every time i download a new emu or i want to enable it so it taking me some time
it will be beter if it realy be as default.
thanks and sorry for my bad english.
you can copy the folder which contains the .ini's files into your new pcsx2's folder ^^ : that's configure automatically pcsx2
i know that and thats what i do every time but i think it will be beter if it will be as default
There is a reason you need to add that line in the ini,prevents noobs from enabling game breaking hacks by ticking every option they see. We obviously DONT want it to be on by default.
well could you possibly be more specific with the check boxs e.g (only enable if you understand) something shorter though seeming it is just a check box
What's so hard about putting a 1 in an INI file? And if you have to deal with the setting every time you check the emu, you're doing it wrong. XD
I'm all for working on this more.
I'm imagining a checkbox that enables an extra "hacks" dialog window, basically just what the shadeboost extension did.
It'll have a warning on it to inform users.
If they still enable it and break their games, it's their fault really :p
I actually thought about that too, mostly so that there's a space for descriptions or something (like the gamefixes section). And also so that I don't have to mess with both dialogs for hacks. XD
I would have to create even another class, like the one for the sadeboost though.
There, hacks moved to their own window. Feel free to change the hacks names and descriptions to something more... descriptive. XD
Since there's no updates page no more, I posted an update on Issue 428: https://code.google.com/p/pcsx2/issues/detail?id=428
Right, I will get right back to ya (if no one else does it first :p).
I'm just busy with real life stuff for a bit.
Looks like the CRC isn't picked up.
The fog you see is not a bug, it should be there originally.
It's just that later in the game the fog is annoying, so it's disabled via a CRC based hack.
That's what I meant :p
Try full boot if you're using fast boot atm, or fast if you're using full.
I`m using 64bit win7?can you help me, because r5113 is for 32bit??
windows x86 apps are compatible with windows x64 but the opposite isn't right
I love this Color setting, now all my Games look more Colorful or Colder if i want it, big thx for this!.
I think 64bit would make more Problems, its better to focus on 32bit versions and then maybe at r6000+ we get the 64bit version for more compatibility and Speed who knows...
I like the way how the Developers work on pcsx2, its a WAY better than the ones from psp Emulator https://code.google.com/p/jpcsp/source/list, cause i dont know why they dont want/need a Review... (my English sucks...)
64bit would unlikely bring better compatibility or speed. at most it might reduce crashing on games which hammer the texture cache, causing the emulator to use more than 2gb of memory.
wouldn't the LAA flag be enough for this?
It could. Someone would have to test it :p
The thing is that it may not be wanted.
Right now the crash prevents GSdx taking down the entire pc in case of a problem with the cache.
Windows is defaulting to a variable size swap file.
This swap could grow indefinitely, with very little the user can do to stop it.
Kind of scary situation :p
Nice work, i have a request to make: any chance an option resizing the window to the game native resolution on the fly? I saw Dolphin do it, and some other emu - it helps since I have to manually specify the resolution for the window for each game - and sometimes the videos have different resolution. I guess i'm a purist like that - I like the exact same res as the emulated console. Can this be achieved? Thanks :)

Revision 5114

GSdx-ogl: LINUX only
* request a minimum of 1 for texture dimension
* Use offscreen texture likes DX11.
* add more bits for extra texture format
* do operation on texture unit 0 to avoid ping-pong between unit 0/2
thank you for gsdx-ogl
I was testing opengl(hardware)
(C2D 3.0G geforce GT340)
in FFX, performance was not so good for 3d with below log.
and frame was about 10-20
Gif Path[1] - MTGS Wait! [r=0x7ff370]
Gif Path[1] - MTGS Wait! [r=0x3f6140]
Gif Path[1] - MTGS Wait! [r=0x7ff6a0]
Gif Path[1] - MTGS Wait! [r=0x2ce6a0]
Gif Path[1] - MTGS Wait! [r=0x7ffa00]
Gif Path[1] - MTGS Wait! [r=0x2c95d0]
Gif Path[1] - MTGS Wait! [r=0x7ff5a0]
Gif Path[1] - MTGS Wait! [r=0x4c5160]
Gif Path[1] - MTGS Wait! [r=0x7ff490]
Gif Path[1] - MTGS Wait! [r=0x0]
Gif Path[1] - MTGS Wait! [r=0x7ff880]
Gif Path[1] - MTGS Wait! [r=0x3e7080]
Gif Path[1] - MTGS Wait! [r=0x7ff9a0]
Gif Path[1] - MTGS Wait! [r=0x3b70b0]
I really expect gsdx-ogl will be same performance with gsdx(windows)
I'm glad it still working on nvidia hardware :p
For the moment, (when I find some free-time actually) the goal is to fix accuracy and crash (in particular on AMD gpu). Performance will come later but don't expect too much. GSdx was built around directx and optimized for directx.
Gregory look:
/home/willian/pcsx2-svn/src/pcsx2-build/pcsx2/x86/ix86-32/iR5900-32.cpp(1403) : assertion failed:
Function: void recRecompile(u32)
Thread: EE Core
Condition: startpc
whats happening?
did it appears on previous version. maybe speed hack issue or maybe i need to merge latest trunk change. only a game or all .
all games! strange! before not apper.
Willanholtz1. Most of change are cosmetic and others fixed some crashes. It feel like a buffer overflow somewhere.
So could you do that.
test r5113: svn update -r 5113
#It must work.
Then update only texture code.
svn update gsdx-ogl/plugins/GSdx/GSTextureOGL.cpp -r 5114
svn update gsdx-ogl/plugins/GSdx/GSTextureOGL.h -r 5114
Does it crash the code? Surely but I want to be sure.

Revision 5115

GSdx: Attempt to fix the resource files so MSVC likes them again. There's still
line ending inconsistencies in the .rc though.

Revision 5116

Team effort of KrossX and myself:
Finally adding that special game fixes / hack dialog I talked about for a while.
Committing this in several steps to clean up any issues easier.
How about reviewing the accurateScaleMulti [r2055] hack (making sure it's actually being used by GSDX) and adding it to the Hacks Window? :)

Revision 5117

cmake: sparsehash moves header file in newer version! Detect the 2 include
pathes and add a define. Fix issue 1222
Note: latest version is backward compatible with the old include path. This revision ensures that it will work for future version without the backward compatibility.

Revision 5118

GSdx: The "enable hacks" checkbox works to toggle all hacks.

Revision 5119

GSdx: Some descriptions and making the hack configure button always visible (for
I see you kept the MSAA and Skipdraw description. =P
They rock!
(Also didn't get to them yet :p )

Revision 5120

Adding KrossX's Wild Arms text alignment hack to the new dialog box. This hack
is actually very interesting for a number of games. It should work well in cases
where game designers adjusted everything pixel perfect for the GS, that usually
breaks with upscaling.
It should be generalized and renamed later.
Don't use this with Dx9! I copy pasted the bitwise operation for being lazy, but forgot there's actually no such thing in Dx9. =S
That would be in tfx.fx lines 777-781 and 783. I'll get into trying to find a way, so it works on a next commit instead of just commenting or reverting it out. Sorry~
I was just wondering why it crashed here in dx9 mode :p
Not exactly the same, but very close and not too messy me thinks. Otherwise, it was getting quite bulky to only detect that pesky bit.
2 line-by-line comments
line 778:
778: output.t.xy = (input.t & 0x3FEF) * TextureScale;
output.t.x = (input.t.x >= 16.0 ? input.t.x - 16.0 : input.t.x) * TextureScale.x;
output.t.y = (input.t.y >= 16.0 ? input.t.y - 16.0 : input.t.y) * TextureScale.y;
line 780:
780: output.t.xy = (input.t & 0x3FF7) * TextureScale;
output.t.x = (input.t.x >= 8.0 ? input.t.x - 8.0 : input.t.x) * TextureScale.x;
output.t.y = (input.t.y >= 8.0 ? input.t.y - 8.0 : input.t.y) * TextureScale.y;
I see.
Well, this will miss a couple of also bad items in Wild Arms but okay, this is dx9 legacy mode.. :p
On an interesting aside:
Your sprite hack fixes the text in Dragon Quest 8 when upscaling is used :)
Something not too bad, better than nothing or a crash, and open for improvement. Groovy. XD
The old, or the updated Spritehack? =O
Ehr, the one currently on SVN. Suppose it's the old since I didn't update it :p
I'm also done for today. Will work on this later, if you haven't by then :)
Roger that. Then I leave you this for later. =P
I think it does pretty much the very same thing as that bitwise operation, while still looking pretty decent. I didn't check how much costly it is though.
2 line-by-line comments
line 778:
778: output.t.xy = (input.t & 0x3FEF) * TextureScale;
output.t.x = (frac(floor(input.t.x / 16.0)/2.0) > 0.4 ? input.t.x - 16.0 : input.t.x) * TextureScale.x;
output.t.y = (frac(floor(input.t.y / 16.0)/2.0) > 0.4 ? input.t.y - 16.0 : input.t.y) * TextureScale.y;
line 780:
780: output.t.xy = (input.t & 0x3FF7) * TextureScale;
output.t.x = (frac(floor(input.t.x / 8.0)/2.0) > 0.4 ? input.t.x - 8.0 : input.t.x) * TextureScale.x;
output.t.y = (frac(floor(input.t.y / 8.0)/2.0) > 0.4 ? input.t.y - 8.0 : input.t.y) * TextureScale.y;
On-Hover descriptions: http://pastebin.com/qAmVZBnV
Seems more decent than I thought it would be. Although the descriptions... might need some work. XD
I checked the performance on my GTX260 using a GPU limited spot. Couldn't tell a difference with the new shader.

Revision 5121

GSdx: Fix for DX9 mode with the Wild Arms hack enabled.

Revision 5122

GSdx: Better DX9 implementation of the Wild Arms Hack. Thanks, KrossX :p

Revision 5123

Mouse over descriptions for the hacks. Thanks to KrossX again, these are great
Nice descriptions. XD
No offense but i liked the previous better XD.
Now people won't be able to tell whether a hack makes kratos a sad panda or not.
We're still working on it :p
all it needs is some shortcut keys - that would be the greatest :p
(ie right-ctrl+f9 toggle native mode, or right-ctrl+f10 for alpha hack..etc)
GREAT Work^^
The 'WildArmsOffset Half option' fixes "Simple 2000 Series Vol.81 - The Chikyuu Boueigun 2 (slpm62652)" white line beside the blood bar.^^
Could you extend the duration which they are displayed. I'm finding a few disappear too quick and i read fast, so thats saying something.
Otherwise great work :)
What about some of the other options that don't have a GUI setting are you planning to add something for them?
ie. accurateScaleMulti, pixoff_x, pixoff_y (not sure if these are still valid options)
CrcHacksExclusions (maybe a text field to list the crc's)
@shadow: There's no timeout or duration. As long as you don't hover over a new item, the current description will continue to be displayed.
you've bound the descriptions to locations on the ui instead of the setting item, which poses problems where that location doesn't match with the setting (such as in a high dpi situation)
Thats pretty much what I meant, I just didn't know it was bound in that way.

Revision 5124

Another refinement to the Wild Arms hack by KrossX.
The hack now only applies to one kind of geometry (sent using the unpacked UV
This works nicer in Wild Arms as it fixes "jumpy" characters.
Much better, thanks for fixing.

Revision 5125

GSdx: Sprite hack update.

Revision 5126

i18n: update japan. Add french.
when you will add the hebrew translation?
and way you Always add other translation please add mine hebrew!
in the 0.9.6 there is a hebrew and i understand better but the version is very old and it dosent run my favority games in hd so try to add this
thanks for the replay and sorry for my bad english.
Someone has to make the translation first...gregory is not the translator he just adds the work of the translators to the SVN.
Thanks again Greg, for keeping up with the translations :)

Revision 5127

i18n: nothing to see... Close issue 1237 .
I saw that! :P
At least it wasn't a three-headed monkey like some other revisions :P
This is true.. ;p

Revision 5128

Tests with Grandia Extreme's debugger suggest that SBUS interrupts *never* fire.
Interesting, wonder what it's used for then...
My best guesses were that it's used during reset or if something goes badly wrong on the IOP side. Because the registers seem to be mirrored it might be possible to figure out when it should actually fire from looking at the IOP modules, but the code to send an interrupt is a bit weird.
In any case it doesn't actually seem to be important.

Revision 5129

Fix Grandia Xtreme flicker :)
Could help other games as well, please test.
Perfect now i can finally play that :) .
Good Job as always.
Do you have any specific games in mind so i can test?
Try it with games that you know have issues with Z or generally missing stuff :)
Yup, this seems to fix the flicker in game. The opening Game Arts movies still flicker in hardware mode though, but using software mode make everything look fine.
Great job! :)
Thanks. Unfortunately it does nothing to the FMV flicker anywhere. That was the first thing I tested :p

Revision 5130

Change a texture cache hack to fix half the flickering FMV games.
It could have issues though, or randomly fix other stuff. Please test :p
Doesn't seem to fix the Grandia Xtreme videos. But I noticed the Enix/Game Arts screens are all part of a video file, more specifically a .MOV file. I wonder if it's the codec (MPEG-1/2 Video (mpgv)) or just how the game renders the file. The game doesn't allow you to open the debugger until after the videos have finished playing though. :\
Oh, and a quick way to fix the video playback in hardware mode I noticed is by setting the deinterlace mode to 5 (Blend tff). So there's that...
The blend modes takes 2 frames and present their average.
You get a mix between the video and the black frame = darker video.
nice seems to fix
dirge of Cerberus videos (in native mode)
games that still have problematic movies in hardware mode
ffx-2 - flickering
rule of rose - black screen in hw mode
shadow hearts 2 - flickers when subtitles are on screen
FF12 is not starting anymore !
seems the game works for some people .. (used to work fine but with video flicker on r5127 )

Revision 5131

debian: update control file to support multiarch in latest ubuntu

Revision 5132

pcsx2: gcc 4.7 compilation fix

Revision 5133

Quick and sloppy fix for a sloppy hack, fixing FF12 pal.
Thanks, pseudonym.
soul calibur 2 is now broken :/
This revision could not have broken the game.
Also it works just fine here.
ff12 now some time starts and freez after 15-30 seconds in videos
it could be only me ... running this on Q6600 processor and old nvidia 8800GTS DX10 mode with costume resolution (1280*786)
so launch soul calibur 2 and see what happens dude ! you won't see anything except health bars !
Soul Calibur 2 NTSC working fine here. Time to disable your speed hacks dude...
which speedhacks? cuz i disabled them ;>
And did you check the revision before this one to ensure that it was this one that causes problems for your game?
the r5127 is the best so far ( still video lines in ff12 ) but works without main problems... etc

Revision 5134

GSdx: Updating the CRC list with some Korean titles. Thanks for the list,

Revision 5135

GSDx: Found the likely actual cause for the FFXII hack problems, probably
introduced with index buffers. Also made the hack a little more crash proof and
maybe fixed an off by one pixel error.
> le
what the hax is the -1 for ?
Likely, problems with his game which have nothing to do with this revision
Nope. I said what was wrong with it. the "le"
Which makes no sense in english whatsoever. English please.
maybe your /le sigh comment? lol
Exactly. I cannot support a revision adding a over-used internet phrase. Hence the -1
A -1 is to be given to revisions which break a game or cause any other regression, NOT because you are with the grammar police.
It is his way of adding his touch to the source code, if i want to add a "My mum does the groceries every [email protected]#ing day." sentence in my source code i will do so.
Learn to suck less or learn to code so you can contribute to the project and remove the comment yourself.
Thanks sudo :p
Le sigh did not come from the internet, but this argument is silly and off topic. It's not a helpful comment regardless, I just felt like touching it.
Notes only, do we need him what to write in the comment as long as the amendment did not break any game
I was rather expecting when I saw reviews on the revision that somebody would've said the problem (FFXII crashing) is either fixed or not fixed.
That had to of been the most stupid -1 I have ever seen. We have people trying to help fix games and this clown gives him a -1 for something like that.
Come on, cut it out already.
I'll be deleting useless comments hereafter.
Positive to compensate negative. Nice work, pseudo.
Another positive comment, later i will see if the fixes made effect in gilgamesh's battle, anyways, thanks so much for your effort :D
@sudo I see your point and the negative is removed.
The change will only make a difference when FMV are played in FF12 or Metal Slug 6.
It's code which is only executed when the game is FFXII (or more
specifically when the game's main binary is FFXII's), it can't break
anything else. Also, it's been in GSDx for a long time, I was just
fixing it so it doesn't CRASH PCSX2.
got an unrelated question here a few revisions ago a fix for flickering FMV's
was made any idea how come its not working for robot wars alpha 2 almost all cutscenes are still flickering or am I talking about two different things here
Nice work sudo!

Revision 5136

Game database update.
Lots of Korean titles added by 99skull.
Thanks :)
"Davil May Cry"?
My mistake.:) It's "Devil" not Davil

Revision 5137

gsdx-ogl: LINUX ONLY
* Keep the state of the draw buffer (save few opengl call)
* AMD fix the shader unloading (12.2 and above). So disable the workaround
Compilation fails
There's an extra + before 'GLenum draw;' in GSDeviceOGL.h
Also, I've uploaded a bunch of Persona 4 dumps on my dropbox.
I'd appreciate if you could fix the renderer up a bit, especially where the z-buffer is concerned http://dl.dropbox.com/u/23891252/dump.7z
Gabest I looked into things a bit and it appears wine gives the DX9 mode a 32bit Z-Buffer (that deduction was thanks to the MSAA values in the hacks menu...), which prevents the logz option from being available and working even when forced on in the ini file... I think...
Persona 4 looks quite similar where the Z-buffer is concerned to the dumps and screenshots uploaded above in DX9 (The other artifacts aren't present).
Even with LOGZ forced on via hex editing (s/VS_LOGZ/1 / on the embedded shader), there is still significant Z-fighting, though it's far more tolerable. ie: http://dl.dropbox.com/u/23891252/gsdx_20111231031019.jpg
I really would appreciate if you could fix it up a bit :)

Revision 5138

cmake linux: don't build zerospu2. Too much issue on linux, uses spu2x instead.
debian: fix nvidia cg dependency for latest Ubuntu
"# Comment the next line, if you want to compile spu2x", you meant "...to compile zerospu2", right?
Well, yes. Sometimes my hands don't listen my brain :p
Since this version, I have the following problem when compiling under Debian:
Building CXX object plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/GS.cpp.o
In file included from /root/pcsx2-read-only/plugins/GSdx/GS.cpp:43:0:
/root/pcsx2-read-only/plugins/GSdx/GSDeviceOGL.h:808:1: error: expected unqualified-id before ‘+’ token
make[2]: *** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/GS.cpp.o] Error 1
make[1]: *** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/all] Error 2
make: *** [all] Error 2
Any idea?
Well it is a developpement branch after all. But the truth I forget a "+" when I fix some patch conflict. Just remove the + and it will be good.

Revision 5139

Some games use volume slides combined with reversed phase.
Gigaherz tweaked the code to handle this nicer (fixes Mashed Drive to Survive
this revision also fixes the looping music, noise and restarts in Star Wars Jedi Starfighter.
Good Job.
Looping music, hmm. I suppose that game could read-back the current volume to determine if the music should be stopped.
With the broken code, the volume could stay at bad levels indefinitely.

Revision 5140

gsdx-ogl: fix build failure due to a leftover of a patch conflict
Excellent, thanks!

Revision 5141

A recently added fix for warnings under Linux is creating an assert on Windows.
The problem only affects debug builds but it should get a review.
I'm not at home right now to look more in depth at it, but as I recall, what was happening is that when all the radio button menu items in a group are deleted, wxwidgets deletes the group, but when you start adding radio menu items again, it trys to add them to a group that doesn't exist. Since the group doesn't exist, it starts a new group, but it also spews a couple warnings about it in Linux.
And this is called every time that the menu is changed, which gets pretty annoying. The line in question is something I got from a discussion of the problem that works around it.
You can make it Linux only if you want. And I'm sure there are other ways we could work around it. We probably don't *really* need to recreate all the items in the menu every time it changes, after all.
Okay, I think we'll go with making it Linux only then.
The list has to be kind of dynamic as it does have to detect when games
have been moved.

Revision 5142

Workaround for the MTVU deadlock on exit issue. There are actually several
issues which deserve closer examination here but this fixes the symptom of
zombie pcsx2 instances.
Nice find :)
yep no longer creating zombie threads, tested using a homebrew which usually reproduces it....nice fix :)
Good job, this'll do nicely for now

Revision 5143

Workaround for the debug build assertion problem discussed in r5141.

Revision 5144

MTVU: Move code out of header.

Revision 5145

Fix for Issue 1145 - Issue introduced with VSync changed broke Dynasty Warrior
games, this should resolve it. Id swapped the VSync order around but still
swapped which Field first, so it started out of sync, silly me!
.....as i said on facebook...... ;p
As i also said, keeping people on their toes xD
by people you mean yourself right? :p
Thank you refraction!
That to :P
You're welcome Makotech :)
And holy hell, DW3 runs insanely fast on the newest version. With a 4.5ghz i5, it use to run <60fps, now its pretty much at my fps limit all the time, 120fps.
Does the homebrew test still show the same picture as a PS2 with this change?
It should do, the interrupt timing and such hasnt changed, only the interlace field order. (and tbh i seem to have missplaced that test :P)

Revision 5146

Fixed PGO builds, MSVC does not like inline asm for function calls.
Works :)

Revision 5147

VIF: Reworked the VU delays in to scheduled events to simulate VU run time
without killing Metal Saga or Fahrenheit. Adjusted the COP checks on the VU's
to use the same method as the VPU_STAT is never set essentially so the VU is
never "running".
Path3 Masking: Fixed a bug which caused persona 3 not to boot, previous a hack
had been put in place to get around this.
VIF: Fixed a VIF error with the rare game Realta Nua, now goes through the
prologue correctly. Game requires the EE timing hack to get rid of most of the
noise (Path3 masking problem with new GIF unit, unfixable).
Expecting bugs, I will be monitoring this.
awesome, so this possibly means a speedup eh? :D
awesome, so this possibly means a speedup eh? :D <-- No it doesn't. I wonder why no matter what the changelog says, people expect speed ups -_-
+1 for now, I will do a quick run through of my games to see if any problems :p
(btw breaks some save states, might want to increase state version)
I had no problems with booting the game?Oo r5128
NTSC-U SLUS_216.21
Oh yes crap, forgot to bump savestate version! Sorry :p
Ehr, yea, we need to work on this.
The slowdown is kind of unacceptable :p
(Seeing just about -50% fps in any 3D heavy title :p )
First of all, we'll want to revert it all, then break it up to smaller commits and at the same time, check what eats the CPU alive here :p
50%? seriously?
try increasing the vif wait cycles on the loop, might be hammering that..
On another note tho, not seen these drops in speed you've mentioned.. is there any specific games rather than saying "any"?
Try a Xenosaga game. 2 is best since it boots you directly into 3D.
i have 3, will that do? im committing a change so it doesnt spin on the vif, itll just wait idle till the scheduler kicks it back in.
Okay, games are hammering the "if(vif1.waitforvu == true)" case in vif1Interrupt.
Increasing the cycles to wait to a game breaking 1000 fixes 80% of the slowdown, but that can't be what we want.
yeh ive got a fix for this incoming so vif won't spin, just testing nothing is broken ;p
Looks like some of the slowdown is from the simulated VU length, not sure what to do there really.. pondering possibly linking it to the cycle stealings VU speedhack or something. if not, have another one called "Instant VU Finish" so it hasnt got a wait time.
im not just guessing i thoguht when you reworked vu delays you might of made optimisations to it :\
its not the fact that the new code is slow, it's the fact it now has to wait, where before it didnt.
Vif1 DMA regression in this revision. Agressive Inline & Dave Mirra BMX want to IRQ Interrupt on the end of a VIF DMA tag, this does not handle it.

Revision 5148

l10n: realigned translation with latest trunk.
Current (unfinished) translation status:
locales/de_DE/pcsx2_Main.po - 522/ 4/560 ( 93%) -38
locales/hu_HU/pcsx2_Main.po - 522/ 4/560 ( 93%) -38
locales/id_ID/pcsx2_Iconized.po - 49/ 12/74 ( 66%) -25
locales/id_ID/pcsx2_Main.po - 498/ 5/560 ( 88%) -62
locales/ru_RU/pcsx2_Main.po - 554/ 4/560 ( 98%) -6
locales/tr_TR/pcsx2_Main.po - 555/ 4/560 ( 99%) -5
what will be with my hebrew translation?
if you can tell me what i need to do to translate in the code
i can translate it to hebrew.
thanks and replay me quicly as you can
Sure. Some reading fist: https://code.google.com/p/pcsx2/wiki/UsingPoedit and https://code.google.com/p/pcsx2/wiki/TranslationGuide
In short:
1/ Get svn trunk
svn checkout http://pcsx2.googlecode.com/svn/trunk/ pcsx2-read-only
Translation master file are located inside locales/templates
2/ Translate pcsx2_Main.pot with poedit.
3/ Translate pcsx2_Iconized.pot with poedit. Note you need to go inside source file to see the "string to translate"
4/ Submit your work in the translation forum (ask write access).
I live in Indonesia and know the language very well.
I would like to contribute but my lack of skills in understanding program (poedit or the like) make me unable to help at this moment. However, if it just translating language from ENGLISH to BAHASA (Indonesia) it isn't that hard for me as I have done some translation for some old school games in the past.
PS: I'm learning on how to use Poedit at the moment. trying to download locales language through the SVN (hope I didn't get the wrong files)
I wish I can help it ASAP. With my low skills, It maybe will take some times to finish it.
cool.be sure to complete existing versions, it doesn't worth it to begin from scratch (100 string vs 600...)
Hello is there any update/status of the indonesian and hebrew translations? It would be a nice improvment for next versions :-)

Revision 5149

-Bumped savestate version, forgot to do that in my last commit.
-Fixed a bug stopping GT4 running.
-VIF now waits if the VU is busy rather than spinning, causing huge slowdowns.
-Filled in some bits i missed
Clarification please
Does the fix cause slowdowns, or fix the spinning that was causing slowdowns?
it removes the spinning which caused the slowdowns bitch :P
Well, most of it
you put the comma in the wrong spot :p
bite me xD
that should bring performance up in quite a few titles though yes?, since additional idle cycles will be available

Revision 5150

Handle exceptions raised inside the access violation exception filter which we
use for various emulation tasks.
This was what made the MTVU shutdown issue undebuggable.
Incidentally I don't think this is an issue for linux, there's supposed to be magic there preventing recursive calls to signal handlers. I would definitely not say that signals are superior to SEH because of this though, and it wouldn't matter if they were because we have to work with whatever's available on the platform.

Revision 5151

Removed the cycle counting from the new changes for now as there is a
considerable speed hit, possibly later we can put a speed hack in there or game
fix to emulate the timings correctly, unfortunately it can be a little too
Seems the best solution for now :p
I'm sure better accuracy is bound to fix something, but were there any games specifically fixed by the change?
Not that we know of, but there are thousands of games out there.

Revision 5152

zzogl-pg: import GSdump feature from GSdx
* Only available on debug build
* ctrl F9 -> dump a couple of frames
* ctrl shift F9 -> start/stop a stream of frames.
* Build a replayer too, called pcsx2_ZZReplayLoader
Note: dump are saved in /tmp.
Cosmetic issue in linux_replay.cpp:
Copyright (C) 20011-2012
Most likely 2011 :P
Also I would guess the vcproj/vcxproj files would need to be updated for the two new files like the Cmake file.
Not sure I understand the copyright issue. It is not the same as GSdx so 2011-2012 is fine. Well I don't have windows, so I don't want to screw it.
Anyway, may I ask you why you didn't come the official debian maintainer of PCSX2? From my point of view you did a great jobs.
I plan to get some of your improvement. Here some minor note:
1/ Normally you can drop this patch:patches/11_cmake.patch. It must work with all versions. Well maybe they fix the issue in natty so I can restore the normal behavior. It would be better. Anyway, I will probably drop the support of Natty.
2/ If I remember correctly, you need a "locale" (or locale-all) package to select the language at startup. I suggest to add it at least in recommend.
3/ Don't mess with cpp flags. PCSX2 suffered severals crashes on the past. Moreover I'm a bit afraid with default hardening flags (for performance reason). PCSX2 have got a lots of trick to increase performance, sometime there are not compatible with gcc.
Oh the copyright issue was the extra 0, it said year 20,011 which is 18,000 years in the future and I thought it should be 2011. That is why I said cosmetic. For the windows part I guess I could submit a bug report with a patch like last time if it broke.
>Anyway, may I ask you why you didn't come the official debian maintainer of PCSX2?
You mean help you guys maintain the debian folder or actually try to file an ITP (intend to package request) in Debian to actually include it in the official repository? I don't mind helping you guys maintain the debian folder. If you mean include it in the Debian repository then from the top of my head the package probably needs at a minimum a complete copyright and the shader file (ps2hw.dat) to be either precompiled at build time or at load time. Ftp-master will surely reject the package otherwise.
I was updating the copyright file some weeks ago but I don't remember if there is missing info or if the files to compile ps2hw.dat are the ones with the missing info.
1) Oh the 11_cmake path is because w/o the patch it would not compile in lucid i386/amd64, maverick i386/amd64, natty amd64, and oneiric amd64. What I did was create a ppa with build-dependencies and upload cmake > 2.8.5 there. That fixed the failure to build in lucid and maverick but it still would not compile in natty amd64 and oneiric amd64. The patch fixes this. In the precise version that I have not uploaded the patch was dropped since it was not needed since it's full multiarch and only i386 (I had to create transitional packages for amd64 to point to the i386 version). I was planning to drop maverick (EOL in april) and Lucid (superseded by precise). Natty EOL is in October so is not that bad to wait 6 months.
2) Oh the locales package was in the build-depends line. This package is a pseudo-essential package so it's always installed by default (Ubuntu only) and I was getting a "locales: already installed". It's mainly included in build-depends when you need a particular locale during build time if this is the case I could add it again. Basically the built packages with or without it in the build-depends are identical in this case and have the same dependencies. I could add it in the Depends line but I could not find a single l10n package that depends explicitly on locales and I would assume all of them need locales to change the language.
3) Sounds reasonable, I will take them off.
Oh I see what is the issue with the locales now that I'm in my computer. It should be in the depends fields only.
Also I just remembered that since zzogl links against a non-free library (nvidia cg toolkit), it needs a GPL exception that is agreed by all authors involved in said plugin to be allowed to be redistributed. This is explained in:
and given an example template in:
Without that exception or a change to a different license (like LGPL) any redistribution of the program/plugin would be in violation of the currently used GPL license.
Basically license issues and ps2hw.dat block the inclusion into Debian. I also asked and if those issues are fixed it could get included. For reference the wheezy freeze will be this summer (probably June).
Yes I mean ITP.
There are some code inside zzogl (ie plugins/zzogl-pg/opengl/ZeroGSShaders) to generate ps2hw.dat. I don't know how it work but I can look. Sigh.. I think I will need to build the binary with cmake and run it before the compilation of zzogl...
However the copyright issue for zzogl is a killer. Is there any others copyright issue?
One question, from the top of my head, cg have some exception to be redistributable. Could it relax the viral side of the GPL?
Like we said, there is no issue only solution ;)
1/ I merge my gsdx-ogl branch to trunk. The SW renderer is working. The HW renderer is not finished. It would be better than nothing.
2/ I'm still working on gsdx-ogl HW but I'm not sure it can make it work properly. It seems not too bad on nvidia drivers but AMD one is very unstable (could also be some buffer overflow inside my code). Well let's dream to be able to use the free driver next years :)
3/ There is a dev branch of zzogl. It would need careful test and review before I merge it back to the trunk. But it contain a glsl backend to replace nvidia cg. The backend does not work yet on nvidia. But I understood a big part of openGL. I might be able to fix it.
We probably need to create an issue for this or maybe reuse Issue 596 since we are going kind of off-topic from the original commit (besides the year 20,011 issue, heh).
Yes I saw the files inside "plugins/zzogl-pg/opengl/ZeroGSShaders" but those files where being deleted because they have unknown copyright or at least incomplete copyright headers. I read "plugins/zzogl-pg/opengl/README.txt" and apparently there is code already to load the shaders without pre-compilation since it says "'Dev' versions of ZeroGS directly read ps2hw.fx". If this code still exists and it's easier to manage than the precompilation then it could be used to load the shaders from "/usr/share/games/PCSX2/Shaders/ps2hw.fx" or something similar. Not sure if this would avoid the copyright issues related to "plugins/zzogl-pg/opengl/ZeroGSShaders" since I have not looked at the relevant code.
copyright issues:
>Is there any others copyright issue?
That I'm aware of no but I have not seriously checked. It's hard to currently keep track which files use which license and keep track of which license the new files have therefore I have avoided a complete check of the copyrights. I'm not sure if there are any other license compatibility issues due to using so many different licenses together but when the big issues get resolved this could get checked.
>Could it relax the viral side of the GPL?
No the issue is strictly on the PCSX2/zzogl side. To keep it simple, as mentioned in (http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs):
"If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that."
It's just a matter of stop using the nvidia libraries or just giving permission to third parties to link to the nvidia library. Therefore some solutions are:
1) Stop linking to the nvidia cg toolkit (hardest solution but you mentioned there is some work done).
2) Distributions remove zzogl from the source and use an alternative. (Taking into account that libsdl1.3 is not in Debian and that the 3rdparty directories would have to get removed too)
3) Add an exception clause allowing 3rd parties to redistribute zzogl linked to the nvidia cg toolkit. This is the 2nd example in http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs but all authors involved must agree.
4) Change the zzogl license to LGPL or dual license (GPL/LGPL) which I believe allows linking to non-free by default but again the authors must agree.
I'm not sure if there is any other way to solve this. The main problem is that currently any distribution, 3rd party ppa or any other 3rd party redistributing PCSX2 with zzogl is breaking the GPL license (some people argue that it's not) and could get in trouble. Also hopefully only zzogl is affected and the other GPL-2+ code is not because that would make it more complex and probably require the remaining GPL to go to LGPL which probably is not desired or even possible.
If it helps, I still have an e-mail giving blanket permission to do whatever I want with zerofrogs plugins from a few years back from zerofrog. I'd think relicensing would be included.
Yes, it should help to fill up the missing headers and use the files to compile ps2hw.dat if this is the desired route.
Also, I would think it would allow relicensing to LGPL or adding the GPL exception clause to allow linking to non-free libraries with no source and the redistribution of the resulting binary. This assumes the other authors involved would agree.
Well, main people that have worked on zzogl, IIRC, would be zerofrog, Zeydlitz, gregory, and me. So if we wanted to go that route, Zeydlitz is the main person we'd need to contact...
Hum, cg could potentially be a system library (there are exception in gpl for those). Technically cg is a language, a compiler and a runtime library to interface the program to the GPU opengl/dx implementation (which are proprietary). Anyway the fastest would be to add the exception. I'm not sure LGPL is good, LGPL seems to be for non-free program that uses GPL library. By the way, why others plugins/library (because there are the same) GPL2 are unaffected? Because of indirect linking, in the end there is only 1 program.
1) Yes it is the longterm future: drop cg. With Arcum's help, I think I can do it. We need to port the opengl4 error reports from GSdx-ogl (very easy). Then with apitrace and GSDump it would be much more easier to spot the black screen issue.
2) Actually there is already SDL1.3 on debian (experimental). But don't worry, everything is more or less ready to drop it. The major drawback is that you need a OGL3 GPU capable and a OGL4 driver capable (not the GPU because I used only SW GLSL 4 features). Technically I could downgrade the requirement but the idea was to port the HW render.
Definition of a System library is very specific and it does not apply for nvidia cg toolkit. It's basically libraries in gcc and/or things required by the kernel or other essential programs. Anyway dolphin has not been included in Debian due to nvidia-cg-toolkit so there is precedent.
Yes the fastest is probably the exception.
Oh from what I understood LGPL would would work (I might be wrong since I'm not a lawyer or an expert in licensing issues) but at least the Wikipedia page supports this:
"The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.[1] "
Wikipedia is not a real proof but at least is a source :P.
Regarding the plugins http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins talks about them. At the end of the day everything falls under the GPL-3 or GPL-3+ (have to check which one you guys use the code.google main page just says GPL-3) since GPL-3/GPL-3+ is the only one compatible with all the licenses used. I'm not sure if an exception at the plugin level would propagate to the whole project if zzogl uses shared data structures and function with PCSX2 as explained in the link. I would think so since the licenses are compatible but I can never be sure since the GPL is a mess heh. Well if the package gets rejected I will surely know.
Oh I did not see sdl1.3 in experimental nice catch.
I also started a few days ago a packaging effort from scratch with the goal to see what is missing before it could get into Debian. It's mostly done already. The only real issues are license issues but the rest is fairly trivial. The relevant sections of the TODO list have:
* debian/copyright:
- Run "licensecheck --recursive --copyright *" and check that the copyright
file is complete. Submit patch that is already done to fix various headers
with typos that make licensecheck give wrong info.
- Verify if whole project is GPL-3 or GPL-3+.
- zzogl is GPL-2+ but links with non-free nvidia-cg-toolkit.
- ps2hw.dat is distributed as a precompiled shader instead of building it or
loading it on demand.
- pcsx2.man is GFDL. Not sure if DFSG.
Safer to GPL-2/GPL-2+/GPL-3/GPL-3+ or just do like most other man pages.
Files that need headers or be removed when making source DFSG (9 files):
linux_various/detect_missing_file_in_cmake.sh: *No copyright* UNKNOWN
pcsx2/MTVU.h: *No copyright* UNKNOWN
pcsx2/gui/Resources/rebuild.sh: *No copyright* UNKNOWN
plugins/GSdx/config.h: *No copyright* UNKNOWN
plugins/zzogl-pg/opengl/ZZHacks.h: *No copyright* UNKNOWN
plugins/zzogl-pg/opengl/shaders.sh: *No copyright* UNKNOWN
plugins/spu2-x/src/DplIIdecoder.cpp: *No copyright* UNKNOWN
tools/bin2app.sh: *No copyright* UNKNOWN
tools/bin2cpp/bin2cpp.cpp: *No copyright* UNKNOWN
Missing Headers (files are 2 years old there are new versions out too)(4 files):
1) Files:
Copyright: 2007-2012 MITSUNARI Shigeo <[email protected]>
License: BSD-3-Clause
plugins/GSdx/xbyak/xbyak_mnemonic.h: *No copyright* UNKNOWN
plugins/GSdx/xbyak/xbyak_bin2hex.h: *No copyright* UNKNOWN
plugins/GSdx/xbyak/xbyak_util.h: *No copyright* UNKNOWN
plugins/GSdx/xbyak/xbyak.h: *No copyright* UNKNOWN
There are some files like those in Gsdx/zzogl that have individuals and not the team "PCSX2 Dev Team" so I have to put those individually and that is a work in progress.
Finally there are various files with LGPL-2.1+/GPL-2+/LGPL-3+/etc but only the full license of the GPL-3 is included with the source. I would think that the source has also to distribute the full thing for each of the other ones used in individual files (well the ones that requires this).
Ok, they already take the decision. Copyright detail on the issue 1257 . For the plugin we are in this case (in short take it as a library):
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
Arcum, can you update the Visual Studio files to add gsdump.cpp/h? Besides what do you think to duplicate zzogl-pg. Something like that
svn cp zzogl-pg zzogl-pg-cg
svn merge zzogl-dev -> zzogl-pg
With the support of replay it could help to compare the 2 when users have issue. Unfortunately I'm not sure dump will be compatible between the 2 versions, because the first part contains the savestate...
Is it ok for you to put "LGPL-3+ PCSX2 dev Team" on those 2 files?
trunk/rebuild.sh: (well this one is trivial)
They're both trivial, really, but I have no issue with an LGPL-3+ licence on those shell scripts.
And bringing the dev branch of zzogl in as a separate copy isn't a bad idea. There were a bunch of changes to that branch and I really have no idea what half of them were any more...
(Oh, and I don't think I have Visual Studio installed in Windows after the last reinstall, so while I could update the files to add gsdump.cpp/h, it would be guesswork with no testing. :(
Me too I don't remember anymore the zzogl changes! Anyway, Micove said that all the project need the linking exception so it would be easier to finish the GLSL part of zzogl.
Ok don't worry for VS, I will try it within wine.

Revision 5153

Update Portaudio to revision 1826. Hope the Linux side is fine :p
Happily building this revision in Fedora Linux. My last rebuild was r5100 - Really noticable speedups in many games - Great work guys :)
Okay, that's great.
Portaudio had a lot of warnings fixed, so I suppose the revision we've been using up till now was pretty much experimental and that it's improved now.
Well. I don't know how gbirchley build PCSX2. But cmake build of PCSX2 don't rely on 3rdparty software (you can only force zlib,soundtouch and sdl). So you can happily update everythings :p
All right, thanks for the notice :)

Revision 5154

* update missing copyright on
+ plugins/GSdx/config.h
+ pcsx2/MTVU.h
+ plugins/zzogl-pg/opengl/ZZHacks.h
+ plugins/spu2-x/src/DplIIdecoder.cpp
* put a copyright for trivial script file
+ pcsx2/gui/Resources/rebuild.sh
+ tools/bin2app.sh
+ plugins/zzogl-pg/opengl/shaders.sh
* remove autotool from zzogl
* apply the patch for issue 1257 . Thanks very much Micove for the hard work.

Revision 5155

* change the man page to gpl3
* add missing copyrigh for zerogsshader
* re write bin2cpp tool (in perl) to avoid any copyright issue => hex2h.pl

Revision 5156

cmake: svn remove my executable permission so directly call perl interpreter
That's not necessary
If present on a file, the client will make the file executable in Unix-hosted working copies. See the section called “File Executability”.
you just need to add svn:executable property to the script(s).

Revision 5157

copyright: soundtouch was LGPL2.1 not LGPL2.1+, add an header to
cmake: keep all library for the linking of plugins
hex2h.pl: add svn:executable

Revision 5158

Small fix to mVU. Doesn't seem to help any game though.

Revision 5159

* build the utility to prebuilt cg shader (zzogl-shader)
* build the shader (ps2hw_cmake.dat) that would avoid copyright issue for

Revision 5160

Change various logs to sound "nicer".

Revision 5161

copyright again:
* add some missing copyright header
* (l)GPLv* requires to have a full copy of the license. We already have them in
various sub-directory but files in source root are easier to find

Revision 5162

zzogl-dev: merge from trunk (4924:5161)
:3 could you fix VS2008&10(soo buildbot) while you're at it?
here's a patch, added the two files from r5152
Thanks very much. I commit it.

Revision 5163

zzogl: fix Visual studio build. thank Miseru for the patch
Just thought it'll be bothersome for you on linux, thanks and keep up the good work.:)

Revision 5164

GSdx: F9 is now switching better between HW and SW renderer.
Previously: GSdx was switching between the configured renderer and the best SW
renderer (best = DX11 if supported).
Now: If using DX: Switch SW/HW renderer and use the same DX version. If using
SDL: same as before.
huh, I don't like this. I use DX9 for everything - it's faster and more accurate in a few games for me. But when I hit F9, I would like the best soft renderer (DX11 I guess). Any way I could toggle this in the ini or something?
Well, i agree with comment above. There should be a choice (in plugin options) in what mode I want to switch (9 or 11).
There's no difference in SW renderer between DX9 and DX11. Now it just keep the same DX version when switching.
ok, then I see no downside.
Good, this makes more sense now.
Just need to fix the PCSX2 log line which still says "switching to software" on the first F9, no matter what it really does :p

Revision 5165

zzogl: duplicate zzogl. The idea is to merge the dev branch to allow
building/testing the 2 in concurency
Then it would be easier to separate CG/GLSL for copyright issue. CG is not
compatible with the GPL...
Old version will be zzogl-pg-cg
Future version will be zzogl-pg
Well I'm not surprised that I broke everything for windows build. But the issue is quite strange, I only duplicate the plugin, I don't understand why it miss some dependency?
I just compiled this revision in VS2010 and it works.
Just make sure $(CG_INC_PATH) and $(CG_LIB_PATH) are included in the "VC++ Directories".
This is explained in:
Same principle applies to 2010.
$(CG_INC_PATH) and $(CG_LIB_PATH) could get added to the props/vcproj/vcxproj files but that is a different issue.
Opps wrong link:

Revision 5166

zzogl: painfully merge the zzogl-dev branch
* new memory management
* asm was replaced by intrinsic
* new GLSL backend (AMD only) Cmake is probably broken anyway with the 2
* and lots of others stuff that I forgot about it ;)
In /trunk/cmake/BuildParameters.cmake there is now a:
# Select nvidia cg shader api by default
Should it not to be:
There are other cmake issues between the two branches but you are most likely working on them already.
Actually I was sleeping ;) If you can write me a short summary of the issues. It will save me some time.
Not sure what are the above "other cmake issues", but for me it won't build, complaining to have more than one target "zzogl-shader" (add_executable) in CMakeLists.txt (zzogl-pg-cg and zzogl-pg)
Ok. I forget this one.
You can easily fix it:
Update line 10 of plugins/zzogl-pg-cg/opengl/ZeroGSShaders/CMakeLists.txt
set(Output zzogl-shader) => set(Output zzogl-cg-shader)
Indeed solved this issue. Sadly, failed again at another point, while buiding zzogl-pg (http://pastebin.com/LpVaACUX)
Ok I fixed the 3 issues. I built the 2 plugins in both debug & release mode.
Micove wants to delete the 2 symlink pcsx2/bin and pcsx2/3rdparty because they don't have any timestamps so he can't create a deterministic source tarball. If I correct (svn info pcsx2/3rdparty), you created them a long time ago. Are they still useful?
They were created due to issues with the build system in Linux after a reorganization, IIRC. We have an entirely different build system now. As long as the cmake build system doesn't use those links, you can delete them. You might make sure a clean build works properly afterwards, though, just in case.
Ok thanks. I never built pcsx2 with those symlink, I found them too annoying when I used "grep -r" on pcsx2 directory. So it would be fine but I will double check it.
I wouldn't have used them if I could have avoided it. I had to do some really nasty hacks along the way to keep it compiling with autotools. That's one of the reasons why I was so happy to use codeblocks and then cmake...
It seems /usr/bin is builds with the binaries below, different from the usual only 'pcsx2'. Is it correct?
pcsx2 pcsx2_ZZCGReplayLoader pcsx2_ZZReplayLoader zzogl-cg-shader zzogl-shader
Yes it is correct. However std user only need pcsx2.
*ReplayLoader are only useful for development/debug.
*-shader executables build the nvidia shader ps2hw_camke.dat (because of copyright issue, debian doesn't allow to ship directly ps2hw.dat). Actually I think I can remove them of the cmake installation.

Revision 5167

zzogl: bump the version to 0.4 because of the previous merge

Revision 5168

zzogl & cmake: fix build failure of previous heavy change

Revision 5169

zzogl & VS: thanks Micove for the patch.
* fix failure with VS2008 & 2010

Revision 5170

zzogl: remvove old empty files

Revision 5171

GSDx: dehacked hover description code for hacks
Im sure there's some sort of irony in hacking a hacks dialog ;p
Well whoever wrote this code initially wasn't very familiar with the Win32 API. Thanks to this I spent a lot of time wondering why my code wasn't working before realising that they'd used WM_MOUSEMOVE which was being processed by the controls themselves and the old code was only working because of the hardcoded rectangles which were larger than the controls themselves.
hey, stop hacking hacks into gshack
Nice! XD
Proper hover seemed such a pain compared to the rectangle way when I was thinking about it. =P
And it also didn't work well for different DPI settings.
It's really not a pain, and even doing proper tooltips shouldn't be that hard (you pretty much just initialise it and tell it what the tooltips are for your controls) but this can stay for now.
Hmm...I compiled this using VS2010 (SP1, etc.), from a clean slate (no previous .sdf file).
Turns out the HW Hacks description isn't showing up.
This is on the release build, if that matters at all.
Any ideas?

Revision 5172

spu2x: revert commit 5157. Soundtouch author change in mind and go for LGPL2+ so
we come back to LGPL3+ to avoid license proliferation.
* rename the man page as requested by arch users.
* Delete pcsx2/* symlink. Was only useful for autotool removed few years ago.
* commit the top metadata of my previous branch merge.
File 'src/pcsx2-build/cmake_install.cmake' is missing'pcsx2.man' already, twice. This breaks compilation.
Thanks for the report. I hopefully fix it :)

Revision 5173

Set some svn:eol-style properties.

Revision 5174

linux build: use turbo ;)

Revision 5175

cmake: doc renaming broke the package mode

Revision 5176

GSDx: I screwed up when doing an untested last minute manual cleanup of gsdx.rc,
the mouse over descriptions will actually work now.
Yup, that fixes it.

Revision 5177

GSdx: A couple minor tweaks to the hacks dialog text. Nothing much changed but
sounds nicer to me :p
Less hacks, More Accuracy
484 string. Comment begins from a small letter. And why not to tell "DX9 mode only"

Revision 5178

Auto interlace mode, no more flickering! :p
nifty going to go test :p
Wow great!
Salu2 - Darkness Knight
Good idea :) well done :)
Wow, just yesterday I was thinking how annoying it is to keep pressing f5 when switching between sw/hw. Excellent work
hey guys look this error:
-- Installing: /home/willian/pcsx2-svn/pkg/usr/lib32/pcsx2/ps2hw.dat
-- Installing: /home/willian/pcsx2-svn/pkg/usr/bin/pcsx2_ZZCGReplayLoader
-- Installing: /home/willian/pcsx2-svn/pkg/usr/bin/zzogl-cg-shader
-- Installing: /home/willian/pcsx2-svn/pkg/usr/lib32/pcsx2/ps2hw_cmake.dat
==> ERRO: Uma falha ocorreu em package().
What's happening? Since the build r5170, and i not can't compile the branches gsdx-ogl on linux.
good thing. still...
when you's to do the progressive rendering hack for interlaced games? that way you could kiss the stupid scanline graphics goodbye.
come on. it's not that hard. ;)
I don't need press f5 frequently any more, good job.
You don't compile the gsdx-ogl branch. My zzogl change was only in trunk...
Anyway, can you try latest version and give the full error message.
Got any material on how to do it?
Anything that gives a head start and I might try it :)
Wow!!! Great!!

Revision 5179

Preliminary NTSC progressive scan support.
The detection is based on a quickly reversed smode1 flag and needs to be done
The timing itself also needs reversing and has only been tested on the VP2 intro
(That video now runs without audio / video desync when progressive scan is
enabled :) )
well done :)
I guess I should test the same for Star Ocean then though being of the same company it should work.
Yup it works in Star Ocean as well
Nice work!!
Hmmm... I think one should test this revision with Silent Hill 2 cutscenes... I'm too tired right now to do that...
Hmm, I'm away the weekend and there's a problem with this code.
Basically the timing is wrong now (again), it just lucks into working.
Sudo knows what to do and I'm sure we can do it properly when I'm back :p
Another game we can test is GoW 2.
Small offtopic note:
in the GSdx hacks section, WildArmsOffset:
it reads "precission" while the right word is "precision" :P
works fine on StarOcean 2 TtEoT

Revision 5180

gsdx-ogl: sync from trunk 5179:5091

Revision 5181

gsdx-ogl: * implement shadeboost (only test the compilation)
Note: gui must be updated with new user hack
To remember thing to look for the gui update:
Hack gater:
* UserHacks
New hack:
* UserHacks_MSAA
* UserHacks_SpriteHack
* UserHacks_WildHack
Gregory trunk and gsdx-ogl same mistake!
Look: http://pastebin.com/Qm97M7CC
Hi greg, it appears you forgot to upload shadeboost.glsl
@willianholtz1, how do you build exaclty PCSX2. I think the issue is somewhat related to my previous renaming of pcsx2.man to pcsx2.1
@gregory, you're right. I'll fix it soon in pcsx2-svn. Thanks.

Revision 5182

gsdx-ogl: forgot to add the glsl file...

Revision 5183

wiki 64b: ia32libs is deprecated, multiarch works far better

Revision 5184

gsdx-ogl: Update gui with latest option
* put shade boost in HW setting (not sure it is HW only)
* Remove logz, useless since openGL support 32bits Z buffer
* Update hack section with a table. Note don't put MSAA (not yet implemented) to
have a nice square
Note: user hack is enabled with "UserHacks" instead of "allowHacks"

Revision 5185

gsdx-ogl: fix potential build failure on MS

Revision 5186

gsdx: merge the opengl branch to ease futur development and allow GSdx by
default on linux
* for the moment only the SW render is supported, hopefully HW will come some
day. And linux only for the moment.
* Require an OpenGL3 GPU (==Dx10) ie Nvidia >= 8800, AMD >= HD2000)
* Require an OpenGL4.2 compatible drivers => no opensource driver supported
neither Intel driver.
* Build by default without SDL support which will dropped later. You need to add
this define "ENABLE_SDL_DEV" on Win.
Linux users, you don't need anymore this define -DFORCE_INTERNAL_SDL=TRUE. You can directly use OpenGL without SDL.
Cannot be define "ENABLE_SDL_DEV" the definition of /trunk/plugins/GSdx/config.h?
Hum, that a possibility. If we don't remove completely SDL in a couple of commit, I will do that.
gsdx build failed - -
If you have a log file it would help me.
By the way did you try to add #define ENABLE_SDL_DEV in plugins/GSdx/config.h?
Yes But under Windows gsdx generation failed
Well I don't have windows so it is difficult to check. The issue is probably minor, most code don't have any impact on window. If you can copy past the error of VS why it doesn't compile, I would fix it.
very nice!
@yxmline, thanks you very much. I commit some fix, hopefully it would be enough.
@gregory: If I disable "-DFORCE_INTERNAL_SDL=TRUE", onepad will require system's sdl (1.2), but GSdx seems to build without problem. On the other side, I don't know the disadvantages of still using "-DFORCE_INTERNAL_SDL=TRUE".
Which one should I choose?
hip hip hura for OpenGL!
"-DFORCE_INTERNAL_SDL=TRUE" => onepad links vs SDL 1.3 and GSdx links vs SDL1.3
"-DFORCE_INTERNAL_SDL=FALSE" => onepad links with the standard SDL of your system. Could be 1.2 or 1.3. Note forcefeedback only works on SDL 1.3. GSdx with build without SDL (library and feature).
@gregory: just to confirm: not even nouveau will work with gsdx. Users would need drivers like catalyst/fglrx (for ATI) and nvidia (proprietary). Right?
Yes. However open source drivers make atonish progress recently. I expect olg3.3 to be supported by end of the years. Unfortunately I need some GLSL4 features that why we need opengl4 compatible drivers. For example, separate shaders build.

Revision 5187

gsdx: fix some Visual Studio build error of the previous merge.
thank you

Revision 5188

* add some code to support OGL4 debugging. Not enable on CmakeList.txt by
* LOAD_PS/LOAD_VS were using a "std" argument instead of a reference.
* reuse the opengl context creation developed for GSdx. For the moment only
enable OGL2
* Add some documentation for the zzShader API
Unfortunately GLSL is still broken.

Revision 5189

wiki: create a small wiki for GDB command.

Revision 5190

cmake: add a bunch of Micove patch. Thanks.
* Add 2 new dev options: REBUILD_SHADER (nvidia cg) & BUILD_REPLAY_LOADERS
* zzogl-pg-cg will use the shader of zzogl-pg.
When I try to build this revision on VS2010, I receive the following error:
Error 37 error C1083: Cannot open include file: 'Cg/cg.h': No such file or directory d:\users\jhoc\pcsx2\plugins\zzogl-pg-cg\opengl\ZZoglShaders.h 42 1 ZZOgl-cg
Does somebody knows what I'm doing wrong?
I tried to find this file (cg.h), but I didn't find that...
Hum you probably need to install the nvidia cg toolkit: Look this wiki

Revision 5191

GSDx: Added missing initialisation primarily for the software renderer, fixes
R-Type Final crash when using fast boot. Debugged by rama.
Ty :p

Revision 5192

i18n: the regulary update of po files
# some translations miss few bits:
locales/de_DE/pcsx2_Main.po - 522/ 6/560 ( 93%) -38
locales/hu_HU/pcsx2_Main.po - 522/ 6/560 ( 93%) -38
locales/id_ID/pcsx2_Iconized.po - 49/ 12/74 ( 66%) -25
locales/id_ID/pcsx2_Main.po - 498/ 7/560 ( 88%) -62
locales/ru_RU/pcsx2_Main.po - 554/ 6/560 ( 98%) -6
locales/tr_TR/pcsx2_Main.po - 555/ 6/560 ( 99%) -5
I finished translation of po files in Korean.
Could you add this files?

Revision 5193

Translation updates for de_DE
Well, that didn't work.
How important are these translations? Because some of them are kinda bad...
They should convey the message :)
Also note that a lot of these new strings are debugging related, nearly defeating the point of translating them.
No end user will care about options that only show up on debug builds having the best translation :p
Okay, well then I won't start retranslating :p
If you know how to use poedit and can give me your .po and .mo files, I'd gladly put up better translations :)

Revision 5194

Fix locale update mistake (hopefully)

Revision 5195

Created release branch
Now, here's a great mark for pcsx2. :)
Wow!!! Didn't expect that...
Wow, i've waited a long time for 1.0
Damn VERY VERY GOOD thanks Guys for your work really:)
Someone said the magic word!
Well, we needed to get started on 1.0 some day.
Doesn't mean you guys should hold your breath, it's just branched yet :p
Just because we're calling it 1.0 that doesn't mean it's perfect by any means, there's lots of work left to do. We just kind of ran out of numbers and MTVU alone justifies a major release.
woot! Even though there are bugs, this is a remarkable point. Much was implemented and a lot was improved. Let's drink to that! :D

Revision 5196

Config: Exclude MTVU from the presets.
Previously: All presets set MTVU to disabled.
Now: Presets don't affect MTVU (except for the first preset, which disables
speed hacks altogether, so MTVU gets disabled implicitly)

Revision 5197

Config: Improvement for r5196: MTVU now completely unaffected by presets
(including the first).
How about making the vsync setting independent too?
MTVU causes Timesplitters Series to freeze on loading
[email protected]: Thats just tough, dont use it.

Revision 5198

i18n: update id_ID (indonesian), add ko_KR (Korean)
A new sv_SE update (whenever your up for it):
thanks :)

Revision 5199

gsdx (Linux): fallback to opengl SW when SDL is selected but disabled
pcsx2: don't print window title in fullscreen because it create a white frame
flickering. Seem like a wx regression

Revision 5200

cmake: apply some updated pathes of Micove
* drop hack for of Natty and use the std FindGtk2 module, time to upgrade to
* Bump cmake requirement to 2.8.5 to avoid multiarch issue
* Create new cmake variable GLSL_SHADER_DIR for glsl file. Default value
I got a Crash in Magna Carta Tears of Blood i think its cause of some GSdx changes after Gsdx r5113(here this Game works fine), first i got this crash in gsdx r5160 and this game crashes in the Gsdx r5200 too.
The Crash occurs after the Logos
if no crash would occur the Game would check Memory Card and then it would start a FMV Seq. Its definitive a Gsdx Problem i am sure (cause i only changed the Gsdx versions and it worked whit r5113).
I tested in PCSX2 r5163 and PCSX2 r5200(there is all original no older Plugins).
i hope this Infos could help you:-)
What is the first version that crash? So it would reduce the range of version to check.
r5113 is good.
r5160 is bad.
Damn this sucks i tested all gsdx version´s from r5113 to r5164 and i found out something strange like i said r5160 is bad but r5164 is ok.... i hope that helps, oh and r5171 is then bad too...
Also i think now its a change that happens in r5160 thats not in r5164 also i am confused now-.-
What is the status of 5113 to 5164 exactly?
5160 only change log. Unlikely to crash. 5164 change the config when you toggle hardware/sw. Maybe you have an issue with you configuration.
Yeah now i tested again and like you said looks like it´s an Hardware issue and that crash happens now at r5130...(DAMN ignore the the other post then...), and it Crashed only in Direct3D 11 (Hardware)
and NOT in Direct3D 9 (Hardware) also Software works fine too.
Btw if that Crash happens there is no Log information for it.
Gsdx r5129 Direct3D 11 (Hardware) works fine!
Gsdx r5130 Direct3D 11 (Hardware) will Crash!
I Think all Gsdx revisions will work fine in Direct3D 9 (Hardware)!
Sorry for so much misunderstanding its Hard to explain cause my English is not Perfect, and thanks for your fast Answer!

Revision 5201

zzogl: Try to use opengl3/4 feature for GLSL api. The API is easier and I had a
better experience with GSdx-ogl
* Clean the zzsetparameter API to always use the program for uniform that
depends on the program. Future goal is to use a nice OO interface
* Use uniform buffer. Would allow future optimization and remove most
initialization stuff. Don't support yet the 2 zzogl contexts.
http://www.mediafire.com/?hm61esgce9b3958 a fix for VS in case it's needed, had to "return false" under that //fix me' function to save BMP as it was giving error too.
Thanks you very much. I completey forgot about visual studio.

Revision 5202

zzogl: fix visual studio...

Revision 5203

gsdx ogl: find a way to workaround the buggy amd driver to support dual blending

Revision 5204

debian: update of the package round1
* Use some (lots) of improvement from Micove package
* Merge all binary package into 1 would be easier for everyone

Revision 5205

debian: round 2
* rename file to easily switch between stable/unstable
* fix various lintian errors/warnings
longtitle="A playstation 2 emulators"
Shouldn't that be "emulator" ?
Well spoted

Revision 5206

i18n: tr_TR pcsx2_Iconized is wrongly translated. I fuzzy all strings to have an
english string instead of lookup key
various: apply some patch of Micove to disable debug logging in GSdx release
curiosity: why pcsx2_Iconized have aliases, instead of the actual strings?
It is because string have a big length. So if we change a comma or a typo, it would require a new translation. With the "alias" is pretty transparent. See details here https://code.google.com/p/pcsx2/wiki/TranslationGuide
Won't this transparency also hide big changes in the strings as well? When a string is slightly changed, poedit will fuzzy up the string and show a suggestion.
What I mean is if do not completely re-write the string in the source code, poedit might provide a good suggestion based on the old strings still available.
If I'm not clear enough, try this: get a string in pcsx2_Main.pot and add some dots, save and then update a po file with the pot. Poedit should suggestion the old translation.
From my understanding, poedit just fuzzy up the string and don't provide a new strings. Maybe I'm wrong. But yes you're right it would hide also others change which lead to the famous "it isn't a but a feature ;)".
Anyway, I'm not a big fan of this feature. I think the best would be to open a poll on the forum and to ask translators/dev what they prefer. Then it would possibly a big work to transform iconized to a standard po.
Great idea. Thanks
Maybe I misunderstood, but I thought that you would start a thread about it. Do you want me to start one or no need... ? (p.s. I've got no permission to create thread on dev forum)

Revision 5207

gsdx ogl:
* split GSDeviceOGl header. Will allow easy sharing with zzogl.
* fix some gcc warning
* import Uniform buffer and Vertex array from GSdx

Revision 5208

* use 128 vertex buffer instead of 512 that will avoid to fill the GPU vram
* Use separate shader infrastructure for GLSL 4 as Nvidia cg. Beside code is
much easier to understand

Revision 5209

gsdx, zzogl: avoid nested class inside GSVertexArrayOGL.h
zzogl: rework the shader interface to use struct like CG. Shader are still
broken because some variables (gl_color & gl_secondary_color) are not supported
in vertex shader...
/home/willian/pcsx2-svn/src/pcsx2-build/common/src/Utilities/Linux/LnxHostSys.cpp(64) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x00000020
[00] ZZshSetParameter4fv(ZZshShaderLink&, int, float const*, char const*)
[01] SetTexVariablesInt(int, int, tex0Info const&, bool, FRAGMENTSHADER*, int)
[02] RenderCRTC()
[03] GSvsync
Did you use the GLSL api? If yes, it is normal otherwise I'm in deep trouble1
yes i use, if remove will better?
Yes it would work. I'm rework a big chunk of zzogl to support properly GLSL. There are lots of stuff that was deprecated by openGL that I need to remove.
if i remove GLSL api, not appear images. of course, only zzogl-PG.
You have a black screen if you remove GLSL api? Which games? Can you check that it works with zzogl-pg-cg (ie the version 0.3.0). Normally you can build both
whatever http://img823.imageshack.us/img823/9265/bsnes7.jpg
Ah ok. You still have a segmentation fault! Is it a debug build?
yes. http://pastebin.com/nsGnWMZE..
how send for you my debug?
Hum those messages only appears under GLSL4. Somethings is not clean somewhere.
Anyway, I fix the crash issue on r5210 but you will get a black screen if you use glsl. At least it won't crash.

Revision 5210

zzogl: plug vertex array object and remove most deprecated variable from shader.
Only remains gl_FragData

Revision 5211

* fix properly context, directly save the state in the shader
* replace the last deprecated variable in the shader. Remain the issue that host
enable 1 output and the shader write 2 outputs
* It seems that VBO does't depends on the VAO but vertex format depends on both
VBO/VAO so I set the format multiple time. Not sure the behavior is fully

Revision 5212

* some parameters was set after the shader setup. Extend the API to do the
shader setup before the draw
* remove the useless shader compatibility bits
current status on god of war:
In release mode, code try to bind some invalid texture!
In debug mode, don t see previous issue. some random triangles are drawn with stange color. Nevertheless I think it is nearly working.
There seems to be some memory corruption/buffer overflow in release mode.
Find a nice openGL extension to do some advance profiling:

Revision 5213

gsdx linux: uses OGL device by default instead of GSnull. Issue arise when
renderer is 0 -> device is GSnull but GSRenderer is ogl
debian: fix some typo
It still gives me a white screen on either hardware and software mode. I'm running it on a GeForce GTS250 (binary drivers).
can you post your gsdx ini and log files.
ModeHeight = 480
ModeWidth = 640
ShadeBoost = 0
ShadeBoost_Brightness = 50
ShadeBoost_Contrast = 50
ShadeBoost_Saturation = 50
UserHacks = 0
UserHacks_AlphaHack = 0
UserHacks_HalfPixelOffset = 0
UserHacks_MSAA = 0
UserHacks_SkipDraw = 0
UserHacks_SpriteHack = 0
UserHacks_WildHack = 0
aa1 = 0
aspectratio = 1
debug_ogl_shader = 1
dump = 0
extrathreads = 0
fba = 1
filter = 0
fxaa = 0
interlace = 7
logz = 1
mipmap = 1
msaa = 3
nativeres = 1
paltex = 1
renderer = 13
resx = 1024
resy = 1024
save = 0
saven = 0
savez = 0
shadeboost = 1
upscale_multiplier = 1
vsync = 0
windowed = 1
I didn't find any log file related to gsdx.
Ah yes that true. do you see any error messages print on the terminal (you need to launch from a terminal)
gsdx hardware mode:
[email protected] ~ $ pcsx2
Interface is initializing. Entering Pcsx2App::OnInit!
Applying operating system default language...
Command line parsing...
Command line parsed!
glX-Version 1.4 with Direct Rendering
GL_ARB_shading_language_420pack is not supported
convert.glsl (entry vs_main, prog 2) :
convert.glsl (entry gs_main, prog 3) :
convert.glsl (entry ps_main0, prog 4) :
convert.glsl (entry ps_main1, prog 5) :
convert.glsl (entry ps_main2, prog 6) :
convert.glsl (entry ps_main3, prog 7) :
convert.glsl (entry ps_main4, prog 8) :
convert.glsl (entry ps_main5, prog 9) :
convert.glsl (entry ps_main6, prog 10) :
convert.glsl (entry ps_main7, prog 11) :
merge.glsl (entry ps_main0, prog 12) :
merge.glsl (entry ps_main1, prog 13) :
interlace.glsl (entry ps_main0, prog 14) :
interlace.glsl (entry ps_main1, prog 15) :
interlace.glsl (entry ps_main2, prog 16) :
interlace.glsl (entry ps_main3, prog 17) :
shadeboost.glsl (entry ps_main, prog 18) :
#define SB_SATURATION 50
#define SB_BRIGHTNESS 50
#define SB_CONTRAST 50
ALSA lib pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2212:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
* SPU2-X: Enumerating PortAudio devices:
*** Device 0: 'HDA ATI SB: VT1708S Analog (hw:0,0)' (ALSA)
*** Device 1: 'HDA ATI SB: VT1708S Digital (hw:0,1)' (ALSA)
*** Device 2: 'front' (ALSA)
*** Device 3: 'surround40' (ALSA)
*** Device 4: 'surround41' (ALSA)
*** Device 5: 'surround50' (ALSA)
*** Device 6: 'surround51' (ALSA)
*** Device 7: 'surround71' (ALSA)
*** Device 8: 'iec958' (ALSA)
*** Device 9: 'spdif' (ALSA)
*** Device 10: 'pulse' (ALSA)
*** Device 11: 'default' (ALSA) (selected)
Just updated the nvidia drivers to 295.53 and now it works. Harware mode is really blurry (just tested on Shin Megami Tensei: Nocturne), practicaly unplayable and software mode works fine albeit really slow (30fps) as expected;
very good news. Hw mode is not yet finished. The amd driver crashes so it rather difficult to develop. Maybe latest works better i need to check.

Revision 5214

GSdx: CRC Hacks: Import from Cutie - PLEASE HELP WITH TESTING:
- 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.
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
<game name> - <better/worse/same> (reason) - tested <little/medium/much>
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.
Modified hacks (hopefully improved):
New hacks:
good job. dude!
Hi bro, this hack fix the overbrighted problem in haunting ground? Please fix that problem, i been waiting like two years... =D thanks...
Final Fantasy X had very few issues. What did this fix?
Thanks for your job!)When will fixes for Read Dead Revolver and Ace Combat games?
Haunting Ground - better (overlay fog and blury rooms are gone) - tested medium
I cant download this revision, in orphis page says: not build, help...
haunting ground fixed? yeeeesss... please help me to download this revision, in orphis page says: not build, help me...
Tales Of Legendia - better (top left textures are no longer missing, better fps) - tested little
I'm guessing ffx and ffx2 fixes the depth textures (blurry background) tested alittle but to early to tell. I need to compare with the last gsdx :)
finally the haunting ground overbrighted bug is gone thanks bro, great job...
at last...:)
Naruto Ultimate Accel 2 - better (blur and ghosting are now gone) - tested little
IMPORTANT (HELP NEEDED): If you don't notice any change in your game despite it being on one of the lists above, it could be due to several reasons:
- It's minor and you just didn't notice it.
- It fixes a specific area which you didn't test.
- It was designed for a different region than yours.
- Your CRC is not in our list, so the game is not identified and the fix doesn't apply with your DVD.
If you don't notice a change, please report:
<game name> - better/worse/same (<CRC - as appears on the console when starting the game> <region e.g. USA/Europe/Japan/etc>)
Tourist Trophy - same (0xFF9C0E93 USA) - tested a little
Now, if you check our CRCs list here: https://code.google.com/p/pcsx2/source/browse/trunk/plugins/GSdx/GSCrc.cpp
you'll notice that this CRC is currently missing (only one CRC exist for TT on that list, for China).
Thanks for helping out.
Resident evil 4 utsc version graphic improvement confirmed. In previous version of gdsx ,the black raivens at the beginning of the senario can hardly be seen from distance. Now , the raivens are distinguishable from the background.
Valkyrie Profile 2 - Worse (<CC96CE93>: artifacts show in cutscenes, other strange effects) - tested medium
With this game just using the standard "Alpha hack" provided better results in previous gsdx, I'm for a revert on this crc hack.
Final Fantasy X - better (941BB7D9 PAL-G) - blurry background removed - tested little
Soul Calibur 3 - better (027C604C US) - stages being too dark fixed - tested little
Thanks for all the hard work.
konaj...: Thanks. We'll probably revert the VP2 hack, but let's first wait a little for more comments and then address few of them together.
Everyone, thanks :) please keep posting reports...
There is same CRCs in NanoBreaker and DevilMayCry3.
Soul Calibur 3 - better (37B99B14, KO) - dark screen fixed - tested some stage.
Soul Calibur 3 CRC hack fix worked to Soul Calibur 2 too.
Soul Calibur 2 - better (83AFB38A, KO) - dark screen fixed.(skipdaw=2 same effect)
i delete duplicate CRC. Add some korean CRC and copy soul calibur 2 hack fix.
Could you add this code? i maked a patch file.
Line327 {0xA79B0491, NanoBreaker, JP, 0},
Line418 {0xA79B0491, NanoBreaker, JP, 0},
Line341 {0x25FC361B, DevilMayCry3, US, 0}, //SE
Line342 {0x2F7D8AD5, DevilMayCry3, US, 0},
Line343 {0x0BED0AF9, DevilMayCry3, US, 0},
Line384 {0x25FC361B, DevilMayCry3, US, 0}, //SE
Line385 {0x2F7D8AD5, DevilMayCry3, US, 0},
Line386 {0x0BED0AF9, DevilMayCry3, US, 0},
Line345 {0x18C9343F, DevilMayCry3, EU, 0}, //SE
Line346 {0x7ADCB24A, DevilMayCry3, EU, 0},
Line387 {0x18C9343F, DevilMayCry3, EU, 0}, //SE
Line388 {0x7ADCB24A, DevilMayCry3, EU, 0},
Line348 {0x79C952B0, DevilMayCry3, JP, 0}, //SE
Line349 {0x7F3DDEAB, DevilMayCry3, JP, 0},
Line389 {0x79C952B0, DevilMayCry3, JP, 0}, //SE
Line390 {0x7F3DDEAB, DevilMayCry3, JP, 0},
add CRC
{0xF088FA5B, DeathByDegreesTekkenNinaWilliams, KO, 0},
{0xFDA2F2DF, Dororo, KO, 0},
{0x924C4AA6, GodHand, KO, 0},
{0x4FAE8B83, SakuraTaisen, KO, 0},
{0xC2E3A7A4, SakuraWarsSoLongMyLove, KO, 0},
{0x47C2C34A, Siren, KO, 0},
{0x83AFB38A, SoulCalibur2, KO, 0},
{0xE1B01308, SoulCalibur2, US, 0},
{0x37B99B14, SoulCalibur3, KO, 0},
{0x2088950A, XE3, US, 0},
I didn't notice any issues in Godhand. What this CRC Hacks must fix in this game?
God of War 2 - better (0x2F123FD8 NTSC-U) - tested little
Good job, but there are some PAL crc's that need to be added, please let me know if I can provide them to you.
After testing Spartan (SLES-53393) CRC: 0x72E1E60E the hack only works if you choose 50 hz, not in 60hz mode, still the game looks darker than in software mode.
PS: 2 things for the hack for Jackie Chan PAL version, first the crc is the PAL one, and appears as No region, and second and more important the game is not fixed since the half screen garbage bug is still there.
ICO - same (0x788D8B4F EU) - tested a little
I notice the CRC of mi game is not listed in your CRCs list.
The bug is fog all around of the world game. (sorry for my bad english).
Info of my game:
(SYSTEM.CNF) Detected PS2 Disc = cdrom0:\SCES_507.60;1
(SYSTEM.CNF) Software version = 1.00
(SYSTEM.CNF) Disc region type = PAL
ELF (cdrom0:\SCES_507.60;1) Game CRC = 0x788D8B4F, EntryPoint = 0x00100008
great revision bro!!!
god of war 2 realy works better! the fps is higher then the older gsdx.
thanks and keep up the great work!!!
GTA Vice City Stories works nearly 2x faster on Hardware since 0.9.8 release. There is also corrected bug with lower FPS than in older version.
Haunting Ground overbrighted effect fixed, working like a charm
- Guys, please post the CRC/region if it's not on our list, and we'll add it.
- Reminder, if you notice a change, please describe it briefly (one line is usually enough).
- If the change improves partially, please describe it as "better", and add a comment (e.g. "only improves on 50Hz but not on 60Hz").
- Reminder: (updated) report format:
<Name (CRC Region)> - <better/same/worse/not-sure> (reason) - tested <little/medium/much>
Tourist Trophy (0xFF9C0E93 USA) - better (removes garbage when brightness is not 0) - tested a little.
God of War 2 (0x2F123FD8 USA) - not-sure (removes some character ghosting, removes water wobbling effect and lines) - tested a little.
Thanks, keep it coming!
Eternal Poison (2BE55519 US) - Same (Text is still faded on some dialogs) - tested little
Not sure what has changed from the previous crc hack it seems to still have the same issues.
GTA San Andreas - Condition - Same. I notice no improvements or worsening for the game. I did a quick 10 minute play around and I still see the ghost effects on screen when its a sunny day in-game. Tested with speed hacks on/off and fast and full boot.
CRC: 0xA1B3F232 (PAL version).
New CRCS to be added:
AlpineRacer3 SCES-50887 crc: 0x7367D841
Death By Degrees Tekken Nina Williams SCES-52586 0x59683BB0
SoulCalibur3 SCES-53312 OTHER VERSION 0xBC5480A3 (tested with skipdraw 2)
Game tested:
Spartan SLES-53393 - 0x72E1E60E PAL- better (only improves on 50Hz but not on 60Hz ,Show text in intros and better graphics) - tested a little
SoulCalibur3 SCES-53312 - 0xBC5480A3 PAL - better (dark screen fixed) - tested medium
Final Fantasy X (0xA39517AB EU) - better (fixes "blur") - tested little
What the hell? From these comments what I'm hearing is that these hacks are removing fully intended and functional effects like depth of field. Many if not all of them have to be removed, "improving" a game by removing effects that were meant to be there is not emulation.
Well if you stopped bitching and did the "fixing" gsdx you keep claiming you can do, we wouldnt HAVE to remove the effects.
No, I'm saying these comments are talking about removing effects which work PERFECTLY.
Devil May Cry (0x79B8A95F NTSC-U) - worse(black box appears. it blocks main part of the screen) - tested little
Ill let you off then ;p
but why negative this post because people are making silly comments? that does not make sense.
Because the comments seem to show that some of the hacks in this patch
do not address bugs, they just remove effects that people decided they
didn't want.
I don't see soulcalibur 2 ntsc-j on the list of crc's... I'll get it for you tomorrow when I can test this revision
"they just remove effects that people decided they
didn't want." - Why not just move those to the cheats then?
Incidentally I haven't noticed any dialogues for en/disabling individual cheats, if this isn't already implemented then perhaps this is a job for someone who is looking for a change of pace.
Valkyrie Profile 2 - Worse than before - Tested Little (Mainly the beginning)
GSdx of Revision 5210 still had some black lines for me however 5206 of Cutie fixed the lines however this current GSdx of Revision 5218 doesn't have any black lines but now there are lots of random dark spots(squares).
Sakura Wars So Long My Love - Better & Worse - little
Lighting is fixed now, however there was part of a cutscene during a battle where one straight column on the left side of the screen was misaligned and blurred pretty badly and some textures during battle randomly went missing and came back. I only tested one battle and a couple scenes, so I can't really say much.
Rogue Galaxy - Medium - Same, No difference noticed.
I do agree with sudonim1. Correctly emulated effect(but undesired by the user) should not be removed this way.There should be more a "specific game hack/cheat" function.
Probably could just add a checkbox for 'cutie' under the hack section and a few if - else checks to enable the new hacks
Tales of Symphonia's character lightning (material lightning?/ self-shadowing?) is now removed by default which helps speed, the game was one of the abnormally demanding GSdx games before, it went from 8 fps to 30 fps in the classroom on my PC.
http://i45.tinypic.com/2vx375t.jpg [previous revisions]
http://i45.tinypic.com/28up54l.jpg [r5214+]
Sorry for the vertical lines, it's a known issue I used upscaling because the game is really blurry at native res, it is possible it shares Issue 837 (r1357) with Tales of the Abyss, I believe ToS runs at 640x448 without interlacing while ToA runs at 512x448 without interlacing.
> What the hell? From these comments what I'm hearing is that these hacks
> are removing fully intended and functional effects like depth of field.
Well, shit. You're absolutely right. I don't remember seeing that effect on hardware, but it certainly is there (just checked):
Doesn't look nearly as jarring on a TV due to all the blurring caused by composite cables (most popular?) and other things. I guess that was the intention, but it still doesn't excuse the fact that the effect is rather cheap and ugly. Then again, it *is* correctly emulated, so I'm going to change my review about the hack:
Final Fantasy X (0xA39517AB EU) - worse (removes correct effects present on hardware) - tested little
i say: There are a lot of effects like blur and depth of field that were used on PS2 games to make the games look nicer, BUT here we are emulating PS2 on a COMPUTER, and we can upscale the resolution so there is no need of such crappy effects (in most cases they cause ghosting and make the image look like crap).
As i only play PS2 Games on PCSX2 for the upscaled resolution (and bugtesting different things) i wholeheartedly approve of this revision.
If it doesn't look better in PCSX2 i play the game on real PS2, simple.
This is just my opinion, and is not intended to start some crappy flame war. If you don't agree with my opinion then so be it.
This is a good discussion guys, please keep the reports coming.
As sudonim said, we should aim to "bypass" GSdx bugs, and not to just "make the image sharper" by removing layers of effects, so it's important that you report the changes you notice with the games. As time goes by, we will decide which changes to keep, and which to revert.
One option that came up is to add an "aggressive/upscale hacks" to GSdx dialog, which might also remove intended effects, but which deteriorate upscaling. This might take time as it requires delicate coding, but it's possible.
So please, keep reporting the changes you notice, and we'll try our best to make PCSX2 better overall.
i believe in you and you have my full support. :)
keep up the good work !
P.S: Just tested Soul Calibur 3 NTSC a bit - better (the dark overlay in stages is now gone).
Remember that we already remove the one pixel offset/interlace blur when possible.
Look for // try to avoid fullscreen blur, could be nice on tv but on a monitor it's like double vision, hurts my eyes (persona 4, guitar hero)
I think that we should revert the blur removal in FFX and FFX2 though.
They're effects that work correctly so they should be included.
People that really want them disabled can set skidraw to 1.
I dunno there is alot of changes here to take into account and test, some changes might be for the better (like haunting ground) but again not sure what effects were removed to make it look like that so I still think maybe just make a new option in the hacks section to enable these like
"Enabled New CRC hacks (untested)"
(Game that worked fine before, I think changes can be reverted on these.)
An extra option would require a lot of manual work.
Also, some of the games you listed show issues only later in gameplay (Sakura Wars for example).
So far I think we want to revert FFX, FFX2 and VP2.
Devil May Cry (0x79B8A95F - NTSC/U) - worse (black box on screen) - tested little
P.S. Why is Devil May Cry affected by this bug since it is not in the list of the modified game hacks?
markwe.. because that CRC appears on our list as DMC3...
New PAL crcs to be added:
Bully (CANIS CANEM EDIT) SLES-53531 crc:0xC78A495D
JamesBondEverythingOrNothing SLES-52005 CRC:0x5FFFDE40
LegoBatman SLES-55135 crc:0xE01F57ED
RogueGalaxy SCES-54552 CRC:0xCBB4B383
UrbanReign SCES-53688 crc:0xAE4BEBD3
And what games are Gits and Siren? If they are Ghost in the Shell and Forbidden Siren, I can provide the Pal crcs too.
The next reports I should post them here or in the new r5221?
PS: Thanks for adding the other PAL crcs.
For now, keep posting CRCs to this page. Thanks.
Ghost in the Shell and Forbidden Siren, yea.
A couple more PAL Crcs:
FinalFightStreetwise SLES-53853 CRC:0x73C560BA
TombRaiderLegend SLES-53908 CRC:0x05177ECE
More to come.
CRCS to be added:
Gits SLES-53020 CRC: 0xBF6F101F
Siren (Spanish) SCES-52330 CRC : 0xB083CCC2
Onimusha3 SLES-80038 CRC: 0x812C5A96 and disc 2 SLES-82039 CRC: 0x812C5A96
tourist trophy SCES-53372 CRC :0xCA9AA903
TombRaiderUnderworld SLES-55442 CRC : 0x8E214549
TombRaiderAnniversary SLES-54674 CRC : 0xA629A376
Games tested:
AlpineRacer3 SCES-50887 - 0x7367D841 PAL- better (solve problems with bad shadows) - tested medium
SoulCalibur3 SCES-53312 - 0xBC5480A3 PAL - better (dark screen fixed) - tested medium
JamesBondEverythingOrNothing SLES-52005 CRC:0x5FFFDE40 - Better (Solve the problem when you enter the menus, but still have the same graphics problems in hardware in fmv than in previous versions of gsdx) - tested medium
My crcs match for the us versions of Rouge Galaxy, Final Fantasy X-2, Grandia 3, Star Ocean 3 Till the End of Time.
@gladiator, you have a PM at the forum.
Games tested:
Tales of symphonia SLPS_254.00 - 0x830B6FB1 NTSC - better (big speed up in town and event, but it removes the shade effect) - tested medium(30 minutes)
Adding these codes make game speed up in battle. but it removes shade effect, too.
if(g_aggressive && fi.TME)
if(fi.FBP==0x0 && fi.FPSM==PSM_PSMCT32 && fi.TBP0 == 0x2bc0 && fi.FBMSK==0x0 && fi.TPSM==PSM_PSMCT32 && fi.TZTST==2)
skip = 1;
Just wanted to point out a few things that are redundant/unnecessary:
This part of an if statement:
else if(fi.TME && (fi.FBP >=0x0) && fi.FPSM == PSM_PSMCT32 && (fi.TBP0 ==0x0160 ||fi.TBP0==0x01e0 || fi.TBP0<=0x0800) && fi.TPSM == PSM_PSMT8)
fi.FBP is unsigned, therefore the comparison: (fi.FBP >=0x0) is not needed.
This is also the case in this if-statement as well:
if(fi.TME && (fi.FBP >= 0) && fi.FPSM == PSM_PSMCT32 && (fi.TBP0 == 0x2bc0 || fi.TBP0 <= 0x0200) && (fi.FBMSK==0xFF000000 || fi.FBMSK==0x00FFFFFF))
fi.FBP >= 0 is not needed.
also in this if-statement
if(!fi.TME && fi.FBP == 0 && fi.TBP0>=0 && (fi.TPSM >= 0 ) && (fi.FBMSK ==0x0001 ||fi.FBMSK == 0x00FFFFFF))
fi.TBP and fi.TPSM are unsigned, so this part:
fi.TBP0>=0 && (fi.TPSM >= 0 )
is not needed.

Revision 5215

GSdx: Dynamic CRC hack: now supports CRC
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.
I've been using pcsx2 for 2 years now but i've never heard about this Dynamic CRC hack. Could you please shed some light on how exactly it differs from the regular CRC hacks.
See r4914
Ah, thanks very much. Vaguely remember this now just didn't read it at the time. Thanks avi et al. Keep up the good work :)

Revision 5216

GSdx: Dyna crc hack: adds version info (for r5125).

Revision 5217

GSdx: CRC hacks: duplicates/stuff:
- Console message for duplicate CRCs on our list.
- Removed trivial duplicates.
- Added some CRCs from comments on r5214
- Soul Calibur 2 now has the same crc hack as Soul Calibur 3.
We still need to address the following 7 duplicates (most were already there
before r5214):
{0x7D4EA48F, HauntingGround, EU, 0},
{0x7D4EA48F, Genji, NoRegion, 0},
{0x7ACF7E03, ICO, NoRegion, 0},
{0x7ACF7E03, SpyroNewBeginning, NoRegion, 0},
{0x6BA2F6B9, ResidentEvil4, NoRegion, 0},
{0x6BA2F6B9, ResidentEvil4, EU, 0},
{0xD6385328, GodOfWar, US, 0},
{0xD6385328, GodOfWar, NoRegion, 0},
{0x1A85E924, GodOfWar, NoRegion, 0},
{0x1A85E924, DevilMayCry3, CH, 0},
{0x2F123FD8, GodOfWar2, RU, 0},
{0x2F123FD8, GodOfWar2, US, 0},
{0x23A97857, StarOcean3, US, 0},
{0x23A97857, StarOcean3, JPUNDUB, 0}
very good with all crc's
question thou,why svn revision id doesn't update ?it says r5199 for this build (from bulld bot)
Because PCSX2 itself was not modified and its version is the same. But the GSdx version IS updated because GSdx was changed.
i understand now,thank you.
Good work ! Although I would like to see finalyy working Terminator 3 Redemption and Van Helsing which stopped working properly very long time ago and also crc's for X-Men Legends which is hanging up still and Marvel Nemesis Rise of Imperfects which is also unplayable after pressing start button. Those are the titles I'm posing here for a long time but nobody tries to fix them :( So maybe now when someone took work on crc's something might move on with those.

Revision 5218

GSdx: Dynamic CRC hack: moved DYNA_DLL_PATH to GSdx/config.h.

Revision 5219

zzogl: GLSL is working again for AMD gpu. Nvidia test is welcome
* properly release shader in release mode
* set stream format every time an array buffer is bound
I tested zzogl-pg-cg (0.3) the other day, that one worked fine.
zzogl-pg (0.4) crashed whenever I run Persona 4 with the following assertion...
/home/hirato/sources/pcsx2-svn/src/pcsx2-build/plugins/zzogl-pg/opengl/ZZoglFlush.cpp:2027: void SetTexVariablesInt(int, int, const tex0Info&, bool, FRAGMENTSHADER*, int): Assertion `fblockstride >= 1.0f' failed.
Also, it rendered the "Playstation 2" logo incorrectly during the full boot.
right gregory..i will testing with nvidia, and after post new.. thnax for updates!
@billy65bob, thank for the report.
@willianholtz1, the best will be to test god of war1. I only test this one on AMD.

Revision 5220

Path3 Masking: Fix for Need For Speed Underground - This got broken when the new
GIF Unit went in, probably affects many games which use streams of NOP commands
before issuing the mask. Game still requires EE Timing Fix however.
VIF Stall Delay hack: Modified slightly for Onimusha Blade Warriors. This
expects the end of the packet to all be in the VIF1 FIFO (which doesn't exist)
and the VIF to have finished, so the Stall is technically ignored now, doesn't
hurt SOCOM 2.
This should also solve Issue 1089 , can anybody confirm? I dont have the 2nd one..
also if somebody could try Issue 1096 (Terminator 3), it would be cool :)
Terminator 3? You mean Terminator 3 - The Redemption? Is the one that gives a lot of issues... I can test both Terminator 3 games if you need them.
if you can try them. Not holding my breath but you never know ;p
NFSU2 (NTSC) is quite broken...
Hardware mode has some flickering issues in menus,
with the car head-lights, for example.
Software gets some semi-transparent green boxes over the menu options atop the screen.
Both renderers have some visual issue in-game,
causing everything to be kinda red-ish.
Hardware mode runs at single digit FPS for me (2500K @ 4.5Ghz),
and Software showed about 30fps when starting in-game.
And the funny thing:
I swear this game ran a bit better in the past (with SW only, though).
put the EE timing fix on, most path3 masking games dont work properly without it
Terminator 3 Redemption is still broken, for what rez comments about NFSU2 the issue seems similar, tested with and without EE timing, it seems a little worse with EE on (more broken).
Curious.. im going to have to see if one of the testers has T3 then, something wierd going on there!
Thanks for checking it :)
Outrun 2006 is still broken if that helps you (path3 game too).
Unfortunately this revision doesn't fix issue 1094 (Tomb Raider Angel of Darkness) that was broken by that damn gif change as well:-(
@ ref
The EE Timing hack is actually just making NFSU2 worse, too...
Bum! alright, ill take a look if i can get a dump or find it cheap
does the ee timing fix still make the bios(settings) appear without the text :D

Revision 5221

GSdx: CRC hacks: "Aggressive" mode (and related stuff).
- 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)
Also, the new "Aggressive" mode is disabled by default.
Please fix the menus in a devil may cry SLES 50358

Revision 5222

Path3 Masking: Games should no longer need the EE Timing fix. General fixes for
Need for Speed Underground 2 and other games affected by the change. Hopefully
Outrun and Terminator 3 will be ok now too, no promises (as i don't have the
I tested a couple of my dumps that often have P3 masking issues and they all work fine except for Star Wars Episode 3.
I think that game regressed some time ago though.
Ill loom at that one tomorrow, cheers :)
I can test Terminator 3 for ya but as i launched it on revision 5219 it still needs a lot of work. GFX is not appropriate, fps is around 20max and it still hangs up the whole pc. But i will try with this rev and see what happens.
Terminator 3 is now perfect. Outrun 2006 it seems that is still in the same state than before, but I will test it a little more.
Glad terminator is better! I only have a dump of Outrun and im having some issues getting it to work, so i couldnt test it :(
I just tried my outrun dump (got it to work) and the game looks perfect! Make sure you do NOT have the EE timing fix on.
Yes, I remember that I provided you the dump, and the graphics worked better them, tested in this version with gsdx5214 the game got graphics issues as I told you, for example there are flashings and some glitches in textures like the water as you can see here:
PS In the latest revisions the improvement in Outrun 2006 is that progressive scan can be selected.
i dont suppose software mode on gsdx makes a difference?
In software is the same or a little worse. Do you want another dump of the game?
To give you a tip for example in the car select the car is not visible (I don't remember if it was ever visible, probably not).
if you could please :)
ooh looks like i got it to mess up :)
New dump, made in r5222 and selected progressive scan, hope that it helps you.
Holy...this actually fixes Front Mission 5 in HW mode.
That game usually has a floating shadow textures (?) in HW mode.
That's probably just one of the new CRC hackfixes for GSdx.
Thanks for the new dump but I already fixed outrun :) will be in my next commit with some other stuff
Terminator 3 is not perfect i still can't see the screen with V-sync selection (50Hz or 60Hz) which was visible in very old revisions.
When i tried to switch from native into 4x native Terminator 3 hanged up my pc. Also fps was only around 40 when in very old revs was around almost constant 60. So in gfx bugs we have progress but in speed and compatibility we have regression with this and not only this game :/
amipc: Is that the american version? i have a similar issue with it, not sure whats goign on there, Onimusha Blade Warriors does a similar thing, i can only suspect an issue with gsdx causing it.
Yes I have american version with PAL/NTSC switch which is invisible right now :(
Well its fixed in r5228 :)
Wow refraction ure awesome you say its fixed after the revision with description of this fix appeared ! Look that i was posting before such rev appeared !

Revision 5223

zzogl glsl:
* clean macro selection and redundant code
* Request GLSL Core profile instead of the compatibility profile
Van Helsing started to work. Now we can see options screen and normally enter the game so that's nice comeback to life of this title.

Revision 5224

-Path3 Masking Changes, Gif Unit now rolls the DMA back (Path3 only) if it is
using the Masking and finishes mid DMA packet.
-Vif modified to be simpler in the transfer loop and fixes issues where Flushes
are called at the end of a DMA packet.
Game fixes from changes:
Outrun 2006 - Water textures and general flickering fixed, also SW mode not
required for half screen issue. Caused by GIF Path 3 stopping in the wrong
Star Wars Episode 3: Revenge of the Sith - DMA timeouts caused by Flush at end
of packet.
Had to break savestates (version change!), sorry :(
Sega Tennis and Outrun are lots better, the other usual Path 3 games are still fine :)
Excellent :) If you could do some general testing to make sure i haven't fubar'd anything up, the pass stuff wasn't totally easy :P
Looking good so far.

Revision 5225

GIF: Ape Escape 2 fix, who thought it was a good idea to transfer data direct
through the damn FIFO >.< Silly developers, i hate you! ;p
(love you really)

Revision 5226

GIF: Slight modification to earlier's work, curPath might not have been set
right if no APATH at start.
This is still prone to problems, but it will only happen with path3 masking games if it does and it is also unlikely (several paths rarely queue)
could you check tomb raider game:legend & underworld..
i think the same garbage graphic for those game..
both game are SLES..(I forgot the number)
only work with software mode in gsdx
sorry for my english..
Legend is fine but needs software mode
it might work in hardware with a skipdraw but i didnt test that, but software mode looked fine.
Awesome work.
Outrun 2006 works perfect in r5224 & in this one. Only 2 things:
- The first water needs alpha hack to looks similar to software mode.
- The car selection only shows in software mode (I'll try to check if there is a way to see it on hardware).
yeh i cant help that :P sorry! that's the GS devs department and i dont have a clue with GSDX, its a big non-understandable mess.
The texture cache (also does the lookup in GS memory) sometimes fetches the wrong texture or no texture at all. There's a couple of hacks in place to work with something but it doesn't always work right.
That and spotty GS memory invalidation breaks games.

Revision 5227

zzogl: revert a change of the zzogl-dev branch. Avoid to compute an empty frame
in Persona 4 & tale of abyss (if someone can check the latter)
Tested Tales of Abyss. Before that I was not able to run the game, and now I works! Intro runs in ~56 FPS, but in normal game I see black screen + a pop up of save game (so, not all black) and in menu screen some objects are missing. But, Nice work!
Did the missing object appears on zzogl 3.0?
no problem with zzogl 3.0
Hopefully I fix correctly dump in latest svn. Could you grab it, then build a debug version.
A dump is created in your /tmp when you hit ctrl+F9. Can you provide one from zzogl 4 (glsl), and one from zzogl 3 (cg).
The best is to provide the easiest wrong scene as possible. A 2D menu for example. I need the same scene for both plugin to ease as much as possible the comparison.
Ok I screw up my first patch... You need r5236 for the dump.
CG - http://dl.dropbox.com/u/19823921/snap001.gs
GLSL - http://dl.dropbox.com/u/19823921/snap002.gs
Good I have them. Can you check somethings. Launch ToA in GLSL debug and check the log file ~/.config/pcsx2/logs/GSzzogl_GL.log (or whatever directory your installed).
I got several error in the replay, so I want to be sure that my replay (code) is good first.
There's nothing in this file, but the following line repeated a bunch of times:
Type:Performance Severity:Med Message:Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
can you test again latest trunk r5252.
Tested in r5253: no screen appeared, not even black, in the GS window. Nothing on zzogl-glsl log file either.
Output: http://pastie.org/4007671
Tested in r5253: no screen appeared, not even black, in the GS window. Nothing on zzogl-glsl log file either.
Output: http://pastie.org/4007671
I fixed another big issue, it must be much better now.

Revision 5228

GIF: Fix for Terminator 3 & Growlanser 2&3 collection invisible screens.
*Noted small speed boosts on some games (Outrun up from 48fps to 52fps, MGS3
potentially gaining 1fps, Sega Tennis possibly 0.5fps), could be a freak
occurrance tho :P
everythings broken!!!
jks :P, everything seems a touch faster....
as i say, it could be psychological, but i made a savestate in an area where nothings moving (MGS3 was the point where you get control) then made note of the top FPS, bottom FPS and anything it hovered around, it did seem a little higher. Not totally sure why, possibly because the GS is getting the information sooner so it's not trying to cram so much in during a small space..
less time waiting for GIF, more cpu to the GS :D
"TT Superbikes - Real Road Racing Championship" (PAL) no longer needs EE timing hack to get rid of some garbage textures in latest svn (testing with r5229). I tested it around r5214 and it did need it then, so something in last revisions fixed it :)
Also, FYI, this game needs skipDraw=1 to remove "wall of fog" in the distance. This game now seems to be close to perfect :)
We may need to go through all the auto gamefix enabled games and see if they still need the timing hack.
Ok so the first screen with PAL/NTSC selection in Terminator 3 is fixed but the game is still broken. I got savestate from chapter 2.1 the one you purse TX in a pickup truck. After jumping the train there the game hangs up the whole pc and you have to use hard reset. It was appearing from the very beginning though I thought some fix will deal with it but none did so only garbage textures are fixed in this title cuz the performance dropped down instead of increase.
"After jumping the train there the game hangs up
the whole pc and you have to use hard reset"
thats not something pcsx2 can cause.....
I guess by Sega Tennis we mean sega superstar tennis here? The game does seem to run bit better now but what's going on with the glowing garbage characters? I guess thats a separate bug from path 3 masking?
Glowing garbage? How does it look in software mode?
If you mean the arm sps, that's a vu or fpu issue, more likely the former :p
"thats not something pcsx2 can cause" really? so what causes it? cuz it's not broken copy of the game cuz on console it runs fine ! Simply it crashes emulator in such way it hangs up the computer. Besides X-Men Legens also crash emulator in one and exact the same moment of the game at the very beginning. So it is a fault of emulator that it cannot handle those games properly.
"Simply it crashes emulator in such way it hangs up the computer."
No; It doesn't.
Your computer is setup in such a way that the game hangs up and crashes.
You mean i have a rig with defects? Don't be funny ! I just have rig on AMD Phenom II 955BE maybe that's the problem it's on AMD platform !
Besides did you play so long [email protected] that you came to chapter 2.1 and jumped over that train? Because it is the only moment this game crashes and hangs up the computer. If you didn't then don't blame my rig and config !!!
amipc, unless the issue you're having directly relates to this revision (as in, it wasn't happening before r5228, but is happening now), please take this discussion to the forum.
This page is only for comments directly related to r5228. It's not a support forum. Thank you.

Revision 5229

microVU: fixed a regression from r4940 that refraction caught when reviewing
changes for a bug report. Might fix line of sight in MGS2 (the reported bug)?
Might have something to do with the ace combat (forget which) collision
detection? Might fix nothing but I'm pretty sure this is correct now.
ace combat zero and 5 still have the collision bug, I dont think ac4 ever suffered from it

Revision 5230

wiki: opengl todo list. Clean GSdx part. Puts some idea for zzogl.
It is a wiki not a new svn build. I just update some docs!

Revision 5231

Fix wiki format syntax...

Revision 5232

gsdx-ogl: only enable AMD hack when linking ps2 related shader. Otherwise
SV_Target1 in convert is wrongly remapped
zzogl: check harder that the previous primitive exist.

Revision 5233

zzogl: rework dump test, to avoid bad mix between u32/u8
glsl4: Replace some define with function (ogl4 support function pointer).
Explain how depth is computed in vertex shader

Revision 5234

* new language ms_MY
* update sv_SE, tr_TR, es_SE,zh_CN
If I forget someone ping me ;)
I updated ko_KR files.
Can you add fi_FI?

Revision 5235

i18n: revert es_ES of previous commit (files were empty)

Revision 5236

zzogl: fix compilation failure because of a wrongly refreshed patch

Revision 5237

zzogl glsl: optimize state change. With luck it would be less slower. At least
GL trace is much smaller (Gow menu go down from 4600 to 3000!)

Revision 5238

1.0 branch: Biggest commit ever.
OMFG! I think you should roll back and do this commit in stages!
3 commits then? You got a point :p
Dear sir/madame I read this shall be the biggest commit ever, or so I was lead to believe.
please do use a sarcasm sign the next time
OT: YAY 1.0
OOOOOOOOOOOOOOOOOOOO yeaaaaaaaaaaaaaaaaaaaaaaaa!!!

Revision 5239

Found one more progressive scan flag and fixed a typo in the GSdx hacks.

Revision 5240

Merge of recent changes from trunk, GIF/VIF changes, MicroVU fixes, Locales and
GSDX Typo. All other GS plugin changes omitted for the moment until people are
happy with them to be sync'd

Revision 5241

copyright: remove the special copyright note. Only impact trivial code (enum and
register definition)

Revision 5242

1.0 branch: Merged in miscellaneous changes from trunk. Lots of changes in GSdx
need Linux side verification before they can get in!

Revision 5243

GSdx: Correct a small resource issue for merging.

Revision 5244

GSdx: CRC hacks: Few CRCs from comments at r5214
Nice... Let me suggest one more... My friend has just stumbled upon some Russian version of "Devil May Cry 3 (NTSC)"... Here's the line:
{0x4AD36D59, DevilMayCry3, RU, 0},
- Tomb Raider Underworld: Better. Tested medium
- Final Fight Streetwise: Not fixed, only first level is fixed, (menu is still wrong) please check these screenshots:
Gsdx level 2 of the game
Gsdx Cutie Level 2 of the game, almost identical to software and menu is not damaged.
Options in cutie: skip bad process, skip draw = 1, skip layers = 2
Hope this helps.
Set skipdrawhack to 3 in Final Fight Streetwise and those stripes will be gone. EE cycle on 2 VU cycle on 1 and will run fine.
to mr.gladiator?is that Tomb raider:underworld game you've played with the word "better" is with gsdx software or hardware mode?
I think my game Still have a garbage grapic in hardware mode..SLES pal..
sory for my bad english..still learn about it.
Tomb Raider Underworld SLES-55442 (CRC : 0x8E214549), of course I tested in hardware mode, the game already worked in software mode in the previous svns.
About Final Fight Streetwise, using skipdraw = 3 creates a lot more garbage, check the screenshot:
It's not a garbage it should look like this.
Galaxy Rogue EU: Some shielded enemies are now invisible! Charge attack animation (the blue flames during charge) is not shown. It seems that the CRC hack for galaxy rogue EU worsen the emulation.

Revision 5245

Path3: Stopped Path3 looping when MskPath3 is enabled, reduces the amount the
recompiler has to exit, yeilding a small speed boost (but it is really small!)
it needs more desu
Hmm.. this revision breaks SSX3 (gets stuck before the first loading screen). It works on r5239, broken here and also broken on r5245, r5246, r5247, r5248 and r5260.
This revision breaks some other games such as AllStarProWrestling3. Maybe it should be included as an optional hack.

Revision 5246

Path 3 games speed up. Stopping VIF looping when waiting for Path 3 to finish
(can sometimes loop over 1000 times)
Examples of speed ups:
Outrun 2006
before 43.4 - 45.7
after 44.7 - 47.33
Grand Theft Auto: San Andreas
before 63 - 66.9
after 66 - 69.5
Need for Speed Most Wanted
before 33.0 - 33.3
after 33.22 - 33.57
Burnout 2
before 46.5 - 48.3
after 53.2 - 55.5

Revision 5247

Path3 Masking Fix: GGIF MFIFO didn't set the GIF state, also added the path 3
stalling stuff to there too.
turning an idle loop into an idle stall?
if it loops, it carries on looping, if it stalls, it stops :p
this commit broke my pizza oven ;D

Revision 5248

VU Interpreter: Implement branch in branch delay slot handling, fixing hot
wheels when using VU Interpreter. Might be buggy, but better than without it ;p
it amuses me that cotton never done this in the first place
oh, i wonder if this broke MGS too :D
hah i hope not :P I only have hot wheels to test off for this too atm. I presume the concept is right... lol

Revision 5249

1.0 branch: Merge of GSdx changes.
Hum, I think we are in dangling state on linux :p (because cmake contains some global variables.)
Could you merge too:
The following stuff:all cmake related stuff. The debian-unstable-upstream directory.
zzogl change need to be merged too. GLSL is not enabled by default but it would allow us to ship pcsx2 on Debian/ubuntu when I fix the last GLSL bug.
FYI, I still need to upload some translation too.
Keep a good work...
@gregory, PCSX2 will be shipping zzogl CG or GLSL?
Final Fight Streetwise hangs up emulator when u play a little :/ also bugs in GFX (black textures or transparent textures).
PCSX2 will be shipping zzogl cg (0.3.0) and zzogl cg (0.4.0).
GLSL is a bit green to be part of the official release, unfortunately it failed to draws some textures.
Oh, what is the reason for "-DGLSL_API=true"? I always thought it was required to build GLSL, but now I figure out that without this flag pcsx2 is built with both CG and GLSL, while with it pcsx2 is built only with GLSL.
For clarity , zz 0.3 cg can only be built with cg(build when glsl is false)
zz o.4 "supports" both api, the api can be selected by the switch.
You can find which api is used by looking the linked library.

Revision 5250

1.0 branch: Merge back cmake changes, the debian unstable directory changes and
the whole of zzogl-pg.
Hope this covers the Linux side.
Translations are still untouched and the latest GIF and VU interpreter changes are also not in yet.
OK thanks. I will need to test it.
Sort of Off Topic, but I notice that zeropspu is inside this branch, but it is not built by default in linux. Wasn't it superseded by spu2x ?
It is because Win users still uses zerospu2 for speed reasons (but with a worst accuracy). I choose a different tradeoff on linux because zerospu2 crash badly on linux, we don't have time to maintain/support it. By the way I'm not sure it is faster on linux, we are often GS limited.

Revision 5251

1.0 branch: Merged the latest GIF / VU Interpreter changes as well.

Revision 5252

* Fix context code for the common shader and set the indices for the uniform...
(will fix most of GLSL-related black screen issue)
* some memory improvements were not merged from zzogl-dev branch
Excellent! I would like to test it, but how can I compile with GLSL?
Add this cmake option -DGLSL_API=TRUE
I add an option to build.sh too. So you can also directly use "./build.sh --glsl"

Revision 5253

* update es_ES/ko_KR
* fuzz id_ID/pcsx2_Iconized.po which is wrongly translated
Any chances getting dropship(ntsc) to get emulated better? (works fully (VU 0/1 at interpreter) @ 15-20 fps). Shadowman(ntsc)- (environment textures everything else seems beeing proper emulated) and primal(pal) in soft ware fully playable @ 25-30 fps).

Revision 5254

1.0.0 branch:
* merge r5253 and 5252
* refresh mo files based on the branch code

Revision 5255

GSdx: CRC hacks: Remove duplicates (none left for now).
The following dup CRCs of were removed (leaving one):
0x7D4EA48F - Haunting Ground EU (now only Genji).
0x1A85E924 - DMC3 CH (now only GOW1)
0x7ACF7E03 - Spyro New beginning (now only ICO)
The following CRCs were removed without any negative effect:
0x2F123FD8 - GOW2 RU (same as US).
0x23A97857 - Star Ocean 3 JPUNDUB (same as US).
I see CRC for the Russian verdion of DMC3 has been included also... Thanks...

Revision 5256

zzogl glsl: used the fog parameter correctly...
@gregory, I put some note in build.sh. Not sure whether you was notify or the note was identified (maybe I should have posted the comment in here..w/e)
2 line-by-line comments
line 18:
18: args="[email protected]"
$args is not being used. Maybe remove?
line 47:
47: echo "Valid options are:"
missing --glsl as valid option.
Thanks, I fix them with another issue. By the way, does ToA run ok now?
no more black screen, I can see characters. Slow in the intro (after the intro's fmv) and 25fps in battle, but nothing missing.

Revision 5257

1.0 branch: Added missing merge information and latest updates from trunk.

Revision 5258

Not sure if it was just me who had this issue but Lilypad didn't have the
Directx SDK lib/include paths in the VC Directories, causing it not to build.
Now it has :P
I have the DirectX SDK on the global include, so it wasn't a problem that way.
global settings are missing ??
Normally it'd be an issue, especially if it's a new VS2010 installation and not an upgrade from VS2008, where a user can export VC++ Directories settings from VS2008 so that it behaves similarly in VS2010 as a global include for any solution, not per project as VS2010 does.
On a new VS2010 installation without any prior VS2008 installed, IIRC it can be remedied by opening any solution, switch from Solution Explorer to Property Manager view, expand a project, expand any of its build config, right-click Microsoft.Cpp.Win32.user, click Properties, edit its VC++ Directories settings just like in VS2008, click OK, then save it (right click it again and choose Save).
What that does is basically editing the Microsoft.Cpp.Win32.user.props file in C:\Users\<username>\AppData\Local\Microsoft\MSBuild\v4.0 directory, so if you're familiar with the .props XML structure then you can just edit that directly.
Similar steps can be done for 64-bit build config, but the one to edit via the Property Manager view will be Microsoft.Cpp.x64.user.
CMIIW, though...it's been awhile since I installed VS2010. =b
Well the reason i did this is because PCSX2 has always been a "download and build" style project, but because the DX SDK is so pants, half the time it doesnt set itself up right.
Although you can do the Microsoft.Cpp.Win32.user.props stuff, that is entirely local, so it doesnt really help other people who come across the same issue, some not quite so smart as yourself :P
brilliant refraction, you also resolved the UI issue where it didn't always update when changing from a button to a rumble device.
well... you made it happen less atleast xD

Revision 5259

SPU-2X Project too for VS2010

Revision 5260

Gif Unit: Bugfix for Path3 Masking. Fast and the Furious did some channel
swapping which freaks it out. Now remembers if it was called by Path 3 for the
DMA rewinding to work correctly.

Revision 5261

Merge fix from r5260 in to 1.0.0 branch

Revision 5262

1.0.0 branch: one file was not merged properly
This is slightly off topic but can someone explain to me how you fixed the EE address because I can't find any useful references on Google.
If not explain then at least point me to a good reference.
I'm still learning C/C++ and it doesn't help when most of the links provided by a search engine don't provide useful information.
On another note great work on the emulator, I still follow the SVN changes on a regular basis, been rather busy on programming HackerEX which is why I haven't tried experimenting on the games I have ( around 100 ) to provide you guys with whatever information you need.
Just realised I wasn't using my main account to post, for those of you who remember the name gb2985 - that's me. Trivial information really but just in case you're curious.
Might be better to ask the guys that do hack the EE stuff.
I don't actually know which ones they're, so many developers and I mainly look at the changes themselves when I do visit which is why I chose to just use this type of revision until I see an EE change (also why I chose to say someone).
Ask rama, refraction or pseudonym ;)
Thanks, I'll go have a look for one of their commits now.

Revision 5263

debian: don't ship null plugins
build.sh: fix shell bug & update the help
What plugin will be used if not null for usb, dev9, etc. ?
Don't worry I only drop the sound/pad/GS null plugins. So the default configuration on Ubuntu package is good. Too much users ask help because of a black screen with GSnull.
And how you manage to tell pcsx2 to use another plugin as default (ex: between GSdx and ZZogl) in ubuntu package?
Unfortunately I can't do that, so I drop the null plugins. It will be either zzogl or GSdx but that will be better than a black screen. For the tarball release I will keep all the plugins so users can still download the extra plugins for debug. But that right it would be better to choose default plugins.
PS thank for the ToA test. You can remove the video.

Revision 5264

zzogl: gl resources must be deleted before the destruction of the GL context

Revision 5265

Path3 Regression Fix: Turns out part of the optimization in r5245 didn't work so
well with SSX3, plus it didn't create much benefit.
That was quick! :)
No messin me ;p

Revision 5266

Merge regression fix to 1.0 branch
fatal error C1083: Cannot open include file: 'Cg/cg.h': No such file or directory
Ref, you need to commit the modification of metadata(property) in "." (trunk root dir). Every time you do a merge, svn add some history of the merge in the property "svn:mergeinfo"
# On the 1.0.0 branch, we can see that the latest rev merged is 5256
#svn propget svn:mergeinfo .
# And svn don't know that you merge 5255 and 5260
#svn mergeinfo --show-revs eligible ../../svn_pcsx2
@jfre did you install properly nvidia cg toolkit?
Whoops. I did an upgrade of a gfx card 2 days ago over to a radeon card and removed all nvidia related stuff when I did. I reinstalled the cg software and that fixed it. My apologies. I'll remove the negative.
Now I'm not sure if this is due to my upgrade in gfx card or not, but I've noticed a 13 fps drop in .hack GU part 3 (US) in the dungeon sections. Ran around 45-60 fps before and now runs around 32-60. Odd. Was using 5261 previously.
After having asked in a much earlier revision I was told to try asking rama, refraction or pseudonym, so here I am.
This is slightly off topic but can someone explain to me how you fixed the EE address because I can't find any useful references on Google.
If not explain then at least point me to a good reference.
I'm still learning C/C++ and it doesn't help when most of the links provided by a search engine don't provide useful information.
On another note great work on the emulator, I still follow the SVN changes on a regular basis, been rather busy on programming HackerEX which is why I haven't tried experimenting on the games I have ( around 100 ) to provide you guys with whatever information you need.

Revision 5267

* new language fi_FI
* update cs_CZ
hey, I just notice database editor has some strings not available to translate. Can this be fixed to 1.0.0 ?
Unfortunately not for 1.0.0. Besides the database is only accessible from a debug build, so normal users can't acces it.
If it just show up in debug, then it is not an issue. Thanks.
I don't know exactly at which version the problem appeared, but under Debian I have now the following problem:
undefined symbol: _XGetRequest
in several plugins.
Any idea?
Where do the message appears exactly? How do you compile PCSX2? Probably not related but you need an opengl3 capable GPU/drivers. Debian sid or testing?
I compile in a i386 chroot with cmake, and I am under debian testing.
I updated the i386 libraries on my amd64 installation using the multiarch capabilities, and it works a bit better: I don't have this error anymore.
However, I have a new problem:
/root/pcsx2-read-only/common/src/Utilities/Linux/LnxHostSys.cpp(64) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x00000000
with all video drivers, which prevents pcsx2 from working...
Also, when I click the configure button for onepad, pcsx2 dies, so it is impossible to configure...
What is pour gpu? can you test a debug build.
OK, I will do a debug build. I have an nvidia Gefore GT330M.
I made a debug build, but no more information is given. How to get more info?
There are log file in bin/logs otherwise info are printed on.the terminal. However don't run pcsx2 with root neither use a root account to build it.

Revision 5268

gsdx: remove sdl and ogl from the win32 dialogs
For general information, SDL and OGL don't work properly on win32. SDL will be dropped in the near future (useless anyway).
err... i so hoped to use openGL renderer in windows :/
since zzOGL is... well, if say it soft, it just bad.
For the moment, opengl is not even finish on linux. Besides it miss the window specific bits that why it was disabled for the moment. It is still planned to add ogl on windows in the future.
uhh, i though it disabled forever and someone will say me to use D3D
then i have no oppose to this change and support it to made it neutral :D
"It is still planned to add ogl on windows in the future."
YESSS! I can't wait.
You CPU is probably a P4, I'm surprised that it could handle the emulator.
Anyway, I'm sorry for you but you can still used older version of PCSX2 (or at least older GSdx plugin).

Revision 5269

zzogl replayer:
* I miss some ending bit.
* Use a full int for GSvsync
* fix a small memory link
Note: candidate for 1.0.0

Revision 5270

Changed the defaults for GSdx to native resolution (for emulation accuracy's
sake) and made the recommended speedhacks enabled by default in PCSX2.
Also set the auto deinterlace mode in GSdx when the .ini isn't present (instead
of "none").
Note that there is at least one game (katamari damacy) that breaks with the mvu flag hack.
Indeed. The intc spin and wait loop detection should be the only ones enabled by default
Maybe we can set that flag off via games db for this game?
mVF flag hack is off for all Katamari games on r5272 onwards (when Automatic gamefixes is on).

Revision 5271

NSIS Un/Installer: updates (for both full/web installers):
- Removed vcredist 2008-sp1 and 2010, added vcredist 2010 sp1.
- GSdx DLLs rename (+"32"), added avx.
- Version to 1.0.0.
- Uninstaller: bios removal now has own checkbox (can now remove everything and
keep bios).
- Uninstaller: registry is cleaned first (better for next install in case
uninstall fails for some reason).
- Test upgrade from 0.98, 0.97.
- Got few crashes and/or errors if files/folders were in use while uninstalling.
Look into that.
- First install on a clean system: test that first-time-wizard appears (i didn't
get the ftw, I possibly had stuff from previous incomplete uninstall).
- Add an option to run pcsx2 when the installer completes?
- readme/faq have "0.9.8" in filename, but the installer refers to <version>,
check if/when it's used.
- Cheats folder created at program files. consider at mydocs?
- Cheats folder contains what appears to be a valid pnach file for personas 4
(inf health etc). do we want that packaged?
- Do we want to mirror vcredist 2010sp1 on pcsx2.code.google/files? (older
redists are mirrored).
- Change the installer logo to the one used everywhere else?
- See if we can use the best gsdx version selected initially (my system supports
sse4, but it selects the sse2 dll by default at ftw).
- Default KB config for lilypad? all other plugins can work without configuring
manually, but without a controller configured, it's very meh. See what we can do
about it.

Revision 5272

Games DB: add support for controlling mvuFlagSpeedHack. Disabling this hack for
all Katamari games (otherwise enabled by default now) since it has a weird speed
bug with it enabled.

Revision 5273

GS/GIF: only raise interrupts on IMR writes on falling edges, i.e. if the
interrupt was previously masked. Also remove a block about queued signals from
IMR writes which makes no sense to me given that the CSR write to clear the
previous SIGNAL should be setting CSR.SIGNAL already, which will trigger the
interrupt by the standard mechanism. tl;dr: fixes realta nua and probably other

Revision 5274

Game database: 2 games have the ee timing hack enabled now, one game disabled.
Which 2?
Perhaps you can add this aslo:
Serial = SLES-53826
Name = Tom Clancy's Splinter Cell - Double Agent
Region = PAL-Unk
eeClampMode = 3
No apparent side-effects.
Isn't safe to have "eeClampMode = 2" as default
for "Automatic Gamefixes"?
... and by the way:
you still have that "Davil May Cry" spelling error.
Here is another one:
Serial = SCUS-97405
Name = ATV Off-Road Fury 3
Region = NTSC-U
Compat = 4
vuClampMode = 1
This game requires this mode due to the "spikey textures" seen on the rider. Thanks.
Could you add some option in GameIndex?
(Guity Gear XX Reload and Shin Megami Tensei - Nocturne)
I attach a patch file below link.
Uh, sorry.
Canceling my request about "SLES-53826".
What I ment was that the "EE Cyclerate" should be 3.
Neither "eeRoundMode = 3" or "eeClampMode = 3" works.
What am I doing wrong?

Revision 5275

GSdx: Removed Rogue Galaxy from the GSdx crc hacks. Fixes issue 1290 .
Thank you

Revision 5276

GSdx: CRC hacks: ICO: moved the cutie extra hack from r5214 to "Aggressive

Revision 5277

Revert original fix for Realta Nua as Pseudonym found the proper fix. This
should get rid of the regression on Agressive Inline and one of the Matt Hoffman
games having textureless graphics.

Revision 5278

* add a script to run cg compiler on glsl file:
+ handy to check the syntax
+ output the asm of the shader
- unfortunately don't support latest glsl construct but better than nothing
* really delete resources before context destruction
* wanted to play with opengl3 timer for profiling but not conclusive, just
keeping code around for future use
Gregory what happened with the openGL 3? Lately I am seeing improvements only worsening.
you mean gsdx or zzogl ?
both! should better gsdx! whats happening with linux version?
What regression do you have?
My FPS decreased in the game ICO, is no longer playable! Marvel vs. Capcom 2 the same thing!
maybe a regression on pcsx2 core side! I didn't touch zzogl cg (0.3 or 0.4 but without glsl), maybe you can try it.

Revision 5279

GSDX: Probably fix D3D10 and maybe D3D9 (might be working anyway but I think I
have it addressing texel centres now) palette lookups. I noticed that this was
broken in D3D10 while fixing the Realta Nua issue in r5273.
Explanation, because this gives me a headache and this might save someone else
one (or I might be wrong and they might see why): in D3D10, 0.0 points to the
centre of the leftmost texel and 1.0 points one texel to the right of the
rightmost texel, so to map a UNORM uniformly across a texel we need to multiply
the input by (w-1)/w. In D3D9 0.0 points to the left edge of the leftmost texel
and 1.0 to the right edge of the rightmost texel so after the multiplication we
add 1/2w.
Actual texture sampling is probably not right for at least one of D3D9 and
D3D10, but this headache is killing me.
Forgot to mention in the commit message: this is barely tested, I have no idea what other than the mentioned game it fixes (or breaks). It should affect any game which uses paletted textures, so that's a lot of games.
Also whoever thought the UNORM bullshit was a good idea should be shot, make 0xff be 255./256, not 1.0
And I'm wrong, I really hate coordinate systems. Or these docs are wrong? The texture coordinate systems for D3D9 and D3D10 are meant to be the same? Well they certainly aren't on my system!
I think it's right, D3D10+ is centered in texel while D3D9 is on the corner. But ain't there some "corrections" scattered around for that?
No, it's drawing coordinates which change between D3D9 and D3D10. What I was experiencing must've been a floating point error which for some reason only occurs in D3D10 on my GPU/driver, which is odd because it should be under 16 significant bits.
Dx9: 0 == pixel center => first pixel range from [-0.5, 0.5[ (open on the right)
Dx10+, ogl: 0 == left edge of the pixel => first pixel range from [0, 1[ (open on the right)
In GSRendererDX.cpp: there is a variable m_pixelcenter but seem to only change the vertex offset.
There is a "HalfTexel" variable in the shader because the filtering mode of the ps2 are differents.
point sampling = integer part of (tex.xy * SIZE )
bilinear sampling = integer part of (tex.xy * SIZE - 0.5) (for the first texel)
Logically I would say that the clut don't support filtering. That mean the main texture returns an exact integer of the clut index (normalized in our case). Gsdx set the palette to point sampler filtering. So it take the nearest texel. In your case we are already on the texel, so the 255/256 mustn't change anythings. Except if the value returns by the main texture is incorrect
By the way, can I have a .gs of the wrong frame. I would need to test on opengl (well if it works enough for that).
Point sampling in D3D (either 9 or 10) isn't the "nearest" texel, it's documented as floor(U * Width).
To explain the situation again, first these values are from a UNORM texture, which means that the original index 'x' in the actual texture data is mapped to the 0-1.0 range by x/255.0. 'Width' in the case of this palette texture is 256, so an uncorrected lookup in terms of x is floor((x/255.0) * 256.0), which we can consider as floor(x + x/255.0) to see that barring calculation errors, this will be x for the range 0-254 inclusive and 256 for 255 (but because of clamping that will work anyway). However on my GPU (Radeon HD 4770) with my driver (Catalyst 11.8, yes I know it's ancient but when you find a version of Catalyst which works without significant problems you STICK WITH IT) values starting from around 250 (I don't know exactly and I'm not writing a test program) got rounded up, indicating effective precision of only 14-15 significant bits rather than the 23 I'd expect.
Haha, texel alignment is a bitch in D3D9.. I had lots of fun with that in Dolphin :p
Not particularly sure if that's related at all, but you might wanna take a look at the explanation at https://code.google.com/p/dolphin-emu/source/browse/Source/Plugins/Plugin_VideoDX9/Src/D3DUtil.cpp#342 . That code is used in Dolphin to copy textures by drawing a textured fullscreen quad onto the destination texture.
Anyway, either good job of fixing this or good luck properly fixing it :D
Hm... if you want to be on the safe side, it should be enough to add this line at the bottom of your vertex shader:
"o.pos = o.pos + float4(inv_vp.x, inv_vp.y, 0.f, 0.f);"
where inv_vp is a constant/uniform that stores the inverse viewport dimensions, i.e.
inv_vp.x = -1.f / (float)ViewPortWidth();
inv_vp.y = +1.f / (float)ViewPortHeight();
The changes of this revision aren't necessary in this case.
The advantage of this method is that it works universally (fwiw, if you don't have something like this in your current rendering code, you really should give this a thought... but then again I reckon reading some dev post about gs pixel alignment some months ago) while modifying texture sampling coordinates only works for orthonormal projection and/or fixed texture sizes.
Oh yeah, btw: D3D10 and OGL don't need any of this stupid stuff (unless GS happens to work like D3D9, in this case D3D9 obviously doesn't need any haxx but D3D10 and OGL do).
... I guess that's enough spamming for now :p
Thanks for the advice but I don't think I need it. I plan to review
pixel and texel alignment in general (again, I reviewed them before),
just not today. I am aware of the issues in D3D9 and D3D10 (the GS is
D3D9 style, centres at integers for drawing and offset by 0.5,0.5 for
texture sampling).
...and this revision isn't about texture sampling, it's about palette sampling. It had nothing to do with D3D9 vs D3D10 and everything to do with a bug on my system causing a small calculation error, but playing safe (as in the next revision) doesn't hurt. Well it does reduce performance slightly, but one multiply-add per pixel isn't even worth counting.

Revision 5280

GSDX: Fixed my inability to remember or look up (I swear that page was hiding)
coordinate systems in r5279 and assumed that it was a rounding error instead.
The symptom was that palette indices above around 250 were being rounded up to
the next palette entry causing visible glitches (only in D3D10 for some reason).
Changed the code to keep the fractional part after multiplication by 256 around
0.5 and the steps around 1.0. Should be very safe against small errors.
And again this might be a driver bug, it's likely a driver bug in fact. So if nothing changed for you that might be why. Though not everything uses full 256 entry palettes so maybe you're just not testing a game where it would be visible.
=== OFF TOPIC ===
thanks for your great work ..
i was wondering if can manage to implement a fix for some suikoden games
where in some FMV video get corrupted unless you switch to software mode .
@ahmad, the forum is much more appropriate for such reports/requests. This page is strictly about issues relating to this revision. Thanks.

Revision 5281

GSDX: put all paletted texture samples through the same transformation from the
UNORM 0-1 256 step mapping to a 0.5/256-255.5/256 mapping after seeing potential
bugs with FMT_4HL and changed FMT_4HH because it seemed to be completely wrong.
Nothing but 8 bit textures tested because I can't find a single game which uses
4 bit textures.
r-type final uses 4-bit textures
It does? I'll look into that then.
It does. For, among other things I don't recall, LOD textures in the museum.
All the blue garbage textures here are 4-bit.
I've since fixed that issue.

Revision 5282

1.0.0: sync with branch.
Didn't take r5273 and 5277

Revision 5283

GSDX: Prodded some offensive code, this isn't meant to affect emulation of any
games and it probably won't.

Revision 5284

GSDX: Added some exceptions on shader compilation failure (with handlers in
entry points because people seem to like the plugin struggling on even when
nothing works any more) because I am not keen crashing Windows via my graphics

Revision 5285

GSDX: Forgot a file.

Revision 5286

GSDX: Err, and another file, I should be asleep.

Revision 5287

GSDX: made the paletted texture handling in the cache a bit more sensible to my
eyes and implemented interpolation of palette entries for pixels in paletted
textures when using the 8 bit textures option. Regressions in some games I
think, such as Virtual On (which is very broken anyway), need to investigate
what made them work (to some degree) before. Seems to change some performance
characteristics favourably to my surprise, but I might just be bad at
remembering framerates.
Omg there too many regressions in that project :/ Be more careful please !
Jak and Daxter 1 works fine here.
Don't worry, this revision isn't going into the release :P
Breaking things is part of development.
Well im going to positive it ;p Although there are regressions, i know from experience what its like. you change something big and loads of stuff breaks, then you spend a few revisions fixing up the breakages :P
All this is leading towards positive and well needed improvements to GSDX.
what refraction said :).
Did you change the texture format (not the palette) for the 4bits idx? For the moment the code still fetch a 8bits index. Or did I miss somethings.
I'm a bit afraid of the speed impact to do the alpha (PS_AEM) before the interpolation. In bilinear mode, you increase quite a lots the conditional branch number.
4 bit indexed formats retrieve an 8 bit index only using 0-15 as I understand the code, which is why they don't need special handling.
I'm not too concerned about the performance of the shader, I doubt this is the bottleneck for anyone with a decent GPU. Doing full format conversion before interpolation is a matter of correct emulation.
Hum ok. I think bits are shifted to 0x0-0xF range inside ExpandBlock4H* function to only get the useful bit when the texture is uploaded. I guess I would need to upload glsl too.
Alpha extensions is not correct for 24-16 bits colors (without clut).
alpha extension after interpolation on RGBA24,RGBA16
alpha extension before interpolation of clut 16 bits.
Clearly RGBA24 and RGBA16 must be added too.
this revision broke text rendering in CodeBreaker 9.2. Not sure if that counts though, since CB was bootleg made with a shady development kit

Revision 5288

GSDX: Added a compatibility check to the framebuffer handling for the texture
cache and made it preferred and added a writeback as a fallback. Compat should
be back to normal?
It may be my idea, but Jak II seems to be far worse now.
Midnight Club 3 also seems to have some new vertical artifacts when on the road. Those were not present before.
That sounds likely. I did break stuff. I haven't yet determined why.
Rogue Galaxy also exhibits said artifacts.
Okami lags like hell when opening the menu, i mean SERIOUSLY borked.
Crash - Wrath of cortex seems slower.
Okami NTSC is fine in everywhere, but Jak3 the clouds in start menu are wierd.
Oh indeed. I guess something i did caused Okami to lag when opening the menu. And as for Jak, i noticed the weird clouds in Jak 2 as well.
They also occur in the first Jak installment, but they seem to fix themselves on you toggle to software rendering and back.
Before submitting any regressions PLEASE double and triple test everything. A comment for a broken game here could waste serious coding hours for the team members trying to find something that was never broken.
VP2 have some strange artefact during cut-scene starting with this commit.
re. VP2 I got the message the FIRST time you posted it, you did not need to make six comments on three different revisions.
I believe I've found all the real bugs in my changes now and what's left is effects which weren't working at all before and are now partially working. This may make your playing experience worse but frankly I don't care, I am trying to advance the emulation of the GS and an effect partially working is better than not working at all. The reverse thinking is what has held gsdx back for years.
I'm sorry for the multiple post. Didn't want to make you angry.
I totally agree the way you are thinking for the emulation of the GS.
And just to make things clear, I was just reporting thing I saw with the recent commit. I'm not whining to get it fixed or do i care if it is... Im just reporting ...

Revision 5289

zzogl glsl4:
* properly delete program and vertex array. Avoid a crash on plugin reload
* reset shader state. Avoid to reuse invalid data on plugin reload
* 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
what downloader not shearch installer r5289
@jorgec...: er.. what?
not download link r5289 or 5290
I sometimes hate orphis buildbot;P making people giving negatives for silly things like that just becouse being demanding n...;]
Anyway Gregory you made a small typo which breaks buildbot again giving error at ZZogl build;3
In /trunk/plugins/zzogl-pg/opengl/ZZGl.h
change glDeleteFramebuffers(1, &buf);
to glDeleteFramebuffersEXT(1, &buf);
have a positive for working soo hard to make typos;3
@jorgec..: I don't have a clue what're talking about. A bot or troll, probably. Giving positive, to go back to original score.
ok what time pcsx2 0.9.9 r5289 installer or zip windows
please for download
my pc is:
core 2 duo E7200
4Gb Ram DDR3 Dual Channel
is much more than the console then going slow
hey gregory, could you update your ppa for natty? the lastest version it has is r4970 and tryed compiling r5288 but bluid.sh gave me errors about missing dependencies that i already have, the cmake method did the same and using codeblocks i had to patch parts of the code to make it compile,exept for gsdx which gave me lots of errors about shared_ptr missing and if shared_ptr.h was added shared_ptr_base.h threw error about missing contructors, so i'm missing what i wanted to try the most XD
some deps were missing from the official repo and had to compile them on my own so a static build would be less of a hassle than adding them.
Also tried with the oneiric and precise repos but had deps error U_U
ps: why isn't there a linux build from the build bot?
I can't compile either, although only with the following error.
pcsx2/plugins/GSdx/GSRendererOGL.cpp:346:21: error: ‘class GSTextureCache::Source’ has no member named ‘m_fmt’
I can comment that out easily enough (probably the wrong solution) but I haven't done any tests.
Thanks for you feedbacks
@billy65bob, actually previous sudonim change a bit the renderer and I need to update it.
Natty is broken. You better upgrade to Precise (the best) or Oneiric. Otherwise you can try to upgrade cmake (from precise) or test micove ppa.
Multiple version of distribution and libraries are not friendly with a linux build bot. I have some script to build pcsx2 from a cowbuilder (not used for a long time) so it would be possible to build a bot with them.
it's really a mess to upgrade ubuntu....(that's why i have mint lmde in my netbook) every time i upgrade it brakes something, and i dont like unity and its unusefullness, and much worst when i already got natty to be stable and work as i want it. Think like it as a server, you don't upgrade without testing throuhgly first to avoid inconvenients, and i cant spend 2 weeks to get everything to work like it's now as of now, i'll give precise a try but it'll have to wait to mid year recess.... :0(
it's really annoying to have to upgrade when you have a 4 hdds mdadmin soft raid and like a thousand things you had download/tweak/compile by hand in order to make it work right, if i upgrade theres a lot of chances of it screwing up the custom pakages and stuff forcing me to reinstall everything again U_U
ok. In this case upgrade cmake. The natty version is broken. If you want a package, check micove ppa. Maybe it still have a Natty version.
@gregory checked nicove and just precise ones.
cmake (2.8.8) was one of the things i had to compile to even try to compile pcsx2 but it still says i'm missing stuff i already have, like wxwidgets, libm (isn't this from math.h? how comes?....) and libgtk.
don't worry ill do this by mid year, half a month wont kill me :P

Revision 5290

zzogl: use the EXT version of fbo (fix the build on windows)
* add some parenthesis to shup up very verbose gcc warning
* adapt ogl to latest sudonim change

Revision 5291

GSDX: fixed an oversight in my shader change gregory caught which removed alpha
expansion for the direct sampling case, should probably fix the remaining bugs.
Also set the texture sampler to point sampling when the shader will be
performing its own bilinear filtering (effect on games unknown but should be an
This revision corrupts textout in Splinter Cell 4.
The problem is still present in r5302.
Serial = SLES-53826
Name = Tom Clancy's Splinter Cell - Double Agent
Region = PAL-Unk
... and in r5304.
... and Splinter Cell 3.
Well if that bug is real and exists in the current version I'm interested, but I have no way to test or debug it currently.

Revision 5292

GSDX: (New bug?) If "8 bit textures" is disabled format conversion has already
happened and we need PS_FMT=0 in the shader for indexed textures.
GSDX: (Old bug) When looking up a texture in the cache, the check didn't take
into account CLUT formats, nor did it skip this check when "8 bit textures" is
Since 5288, VP2 have some strange artefact during cut-scene.
Wagnard: Stop spamming every single commit, you mentioned it on 5288, that's good enough.

Revision 5293

GSDX: Clear Target::m_valid after a full Read() for performance (and accuracy?)
Probably doesn't match the original intent but it matches the current usage.
Rogue Galaxy still exhibits artifacts

Revision 5294

GSdx: Add GUI for disabling all CRC hacks (for testing purposes only, disabled
by default). The new checkbox is at the "HW Hacks" section, and is only relevant
when the global "Enable HW Hacks" box is checked.
Ermm.. to make it clear, it's unchecked by default.
Thanks alot for this:3, much better than editing ini each time trying to check a game.
Good work but shouldn't the Config button only be active if "Enable HW Hacks" is checked like is done with Shade Boost Settings?
Wonder if disabling the texture cache (for testing purposes) would be a handy one to have in there. Such a pain recompiling to do that!
@grove, it was considered and eventually decided to keep that button always enabled. We might rethink this though.
@ref, possible, but. how about adding a gsdx.ini option: dev_gui, which will control the visibility of both "disable crc hacks" and "disable texture cache"? I honestly think these options shouldn't be exposed to the casual user by default..
Not sure, it could be useful in bug hunting. Could put a massive warning on it to not touch unless we say to
A Hack to disable all hacks . Interesting :)
One hack to rule them all!
maybe with the dev_gui option also add an setting to set the path for the dynacrc location since that is also a pain to always have to fix the path then recompile ...
how about a developer conosole instead of cluttering the GUI?
hmm that might be better. a developer gui which can be manually turned on in the ini file would be awsome.
How about a quake3-like console + an overlay with stats/info, etc. ?
I guess the reason against fun stuff like overlay info or console - dx9, dx10 and not leaving it aside also ogl would need to have it done differently, it's easier to just keep things around gui.
it'd be interesting and helpful to have a robust console and the ability to input various cvars in order to manipulate the output of the emulation process.
ofc on the fly

Revision 5295

portaudio (SPU2-X): Last merge from portaudio svn I forgot to include this
change (or tell rama to include it), which breaks debug builds of SPU2-X.
Also, "omfg a commit by gigaherz!"
thanks :)
ratchet: obviously not, it's a small portaudio update, and the bug exists in all modules.
Whenever "omfg gigaherz" is up for it,
he could look into issue 1212, please.
And how would gigaherz fix an issue in gsdx when he never touched gsdx's code?
what good are you then? :P

Revision 5296

1.0.0 branch:
Preparing some docs for 1.0.

Revision 5297

1.0.0 branch:
Preparing some docs for 1.0, part 2.

Revision 5298

1.0.0 branch:
Preparing some docs for 1.0, part 3.
cool..then make a PCSX2 release ..and make a PRO edition and sold it for a few dimes
The FAQ states that pcsx2 doesn't support more then 2 cores, which is not true since the implementation of MTVU. Maybe this should be edited to tell to activate MTVU
PCSX2 readme lacks info about all the hotkeys... F1–F12, Tab, PgUp (or is it PgDown) and maybe some more I don't know about...
A hotkey/key info would be a nice thing yes, for pcsx2 and/or gsdx/other plugins.
Yep. I suggest using this as an easy reference:
Ah, thanks for the link.
In the meantime i'll do:
echo "F1 - Save state
F2 - Change State slot (With SHIFT - backwards)
F3 - Load State (With SHIFT - from backup)
F4 - Frame Limiter Type (Normal / Off / Value)
F5 - Toggle De-Interlacing Modes
F6 - Adjust Aspect
F7 - Pixel Noise
F8 - Screenshot
F9 - Hardware/Software Toggle
F10 - ??
F11 - ??
F12 - Video Capture
TAB - Turbo On / Off (With SHIFT - slowmo)
Page Up (or down?) - FXAA"
Though it might be flooded with pcsx2 console-output :)
How about including a weblink to "Cheat Engine" in the cheat folder of PCSX2 1.0.0?
Just a thought.

Revision 5299

GSDX: CT32 -> T8H, need to use a 32 bit D3D format for the texture so that they
have compatible D3D types for the copy (don't have to if using StretchRect but
might as well).

Revision 5300

GSDX: partially revert texture cache changes for now. Compat probably back to
normal, some glitchy textures are probably differently glitchy, the other
changes might improve some games, performance probably much the same as ever.
For your information, VP2 is back to normal with this now.

Revision 5301

GSDX: Missed this in d3d9 code while fiddling with the shader. Can't be
bothered to do the maths to determine whether doing this twice would have a
visible effect.

Revision 5302

GSDX: Ignore this commit, just deleting lines of code.
Liar. You also edited one. :)

Revision 5303

GSDX: use a GPU side palette for high byte indexed format copies from
framebuffers again (including all the buggy cases because of the revert). I
think this is how it used to be but I've lost track a little.

Revision 5304

GSDX: Add a comment explaining something which doesn't matter.
Commenting a uncommented thing always matters!

Revision 5305

* update it_IT and pt_BR
* remove bad character in id_ID

Revision 5306

Null Plugins: Now report an SVN revision as well as a version.
Actually linux also have the svnrev.h file (automatically generated)
I was just code stealing :P You're free to make sure they work on Linux too :)
Error in CDVDnull breaks compilation.
CDVD.cpp:34:6: error: #elif with no expression
CDVD.cpp: In function ‘char* PS2EgetLibName()’:
CDVD.cpp:37:1: warning: no return statement in function returning non-void [-Wreturn-type]
CDVD.cpp: At global scope:
CDVD.cpp:23:13: warning: ‘libraryName’ defined but not used [-Wunused-variable]

Revision 5307

zzogl: autocompletion typo. Interlace texture was attached to the wrong shader

Revision 5308

zzogl glsl: remove a bad optimization that lost track of some textures. Fix
potential black-screen

Revision 5309

GSDX: Do not interpret TEXA while filling the gsdx internal temporary CLUT
buffer used in texture creation and updating (I didn't realise this was
happening and it's incompatible with my approach). Probably generally fixes
stuff in combination with the other changes in palette handling, at the very
least I know it fixes lines in sprites in Ar Tonelico 2 (currently needs the
"sprite hack"), a bug which I spent a long time trying to fix after it was
pointed out to me before.
I think GetTextureMinMax depends on the clut having been already read into the linear palette buffer.
I was thinking of GetAlphaMinMax, not sure if used in hw rendering anywhere.
Hmm, yes it is. Could just change that to decide by CPSM like it currently does with PSM, specifically checking the palette for alpha values doesn't seem terribly worthwhile.
wow,gabest back?
Keep a good work.
I think tekken 4(pal europe) have a gsdx bug,i just can see only the hair of character.
And dmc 3 special edition,just see the body and face,there is no leg of the character.
Just chilling and waiting for the next gen hardware. Larrabee/Knights Corner/Xeon Phi, or Haswell. Nothing interesting until mid 2013.
Doesn't fix what I thought it fixed. Might fix other things in combination with r5311.
@sulistiyanihimawan You have set clamping to none, nothing to do with GSdx.
gabest, i thought you were excited about the avx instructions in the new ivy bridge? what happened with that?
Do you have a texture cache on SW mode? And how it is working exactly?
By the way, what is exactly the purpose of the HW cache? On the past I believed it was due to bandwidth limitation but the HOST-LOCAL_GS bus is 1.2GB/s on the ps2 so PCIv2 (6 GB/s) seems to be enough. Except it you want to avoid the PCI latency. Or maybe the LOCAL_GS-LOCAL_GS transfer need some additional transfer between CPU-GPU. Another possibility is the cost to unswizzle texture every times.
I'm curious because of future APU architecture which don't rely on the slow PCI interface but directly uses the DRAM and so avoid slow transfer.
Just traced a new bug in breath of fire dragon quarter back to this rev. That plainTEXA changes the palette, which I use to do the pre-shader alpha test, and with these default 0x00/0x80 values it fails, and the output is blocked by setting the d3d write mask. Mostly affecting the overlayed user interface in the game.
We always need a texture cache. One reason is the swizzled memory, you can overcome that with lookup tables and integer texture coords. But there are cases when the source and target is the same, then you need a snapshot of that location before drawing, to avoid reading and writing at the same place.

Revision 5310

88GSDX: Removed the "sprite hack" as it should be obsolete, fixed the vertex
shader selector key function (the pixel shader was broken in the same way but
with the "sprite hack" removed it doesn't matter now).

Revision 5311

GSDX: Skip checking each palette entry's expanded alpha when deciding whether a
texture is fully opaque. Textures are probably almost never determined to be
opaque by this and doing it is problematic. (Skipping the check might even be a
performance gain for hardware, you never know.)
Also remove some (probably mangled) chinese comments from the cutie merge.
...well crap, the lines are back, guess that's not fixed and this was the only reason it looked fixed.
You are forgetting sw rendering, knowing the limits of alpha is kinda important there. IsOpaque can disable some JIT code. TryAlphaTest can fail quicker.
I'm not forgetting sw rendering, I just seriously think that this will never or almost never matter compared to the simpler test.
Just how often would a game be using an alpha test with an indexed texture while either every palette entry is rejected or every entry is rejected? Or using alpha blending with an indexed texture and a palette with no transparent entries.
You think? Err, how about doing benchmarks. Every optimization you find there were based on .gs dumps, to make them run faster, even if only a few games or game engines get a boost from it. If you check it with vtunes, you won't even find GetAlphaMinMax listed because it does not generate enough samples to show up on the radar.
Oh, games are dumb. Doing fullscreen drawings which never write a single pixel. That's where the key speedups are in sw renderering, to skip the stupid invisible parts.
Fine, fine, I guess I could just toss a m_clut.Read32 in there, it'll be practically free if the parameters match the last call.
Here is one example, right in the first I tested, Shadow of the colossus.
m_vt.m_alpha.min = 0x00
m_vt.m_alpha.max = 0x44
AREF = 0x7f
ZMSK = 0
Knowing that all alpha will not be GREATER than 0x7f I can pre-fail the test and mask zbuffer writes.
The IsOpaque thing is also often useful, leaving alpha blending ON is no big deal for game developers, one state for every texture, but sw alphablending requires a read-merge-write pxiel processing, much more costy than simply writing.
Point taken, developers are lazy. r5313 should be more better.
...more better? Ugh, I do know English, I was just typing something else then changed it.
On another note I'm not very inclined to trust any example from shadow of the colossus because that game isn't rendering correctly in software or hardware currently :P
Where in sw mode?
Everywhere, the HDR or whatever lighting engine doesn't match the real console.

Revision 5312

GSDX: Put the sprite hack back in because apparently it wasn't fixed.

Revision 5313

GSDX: Put palette checking for alpha min/max calculation back in because of
gabest's concerns about the software renderer's performance. Added a one line
fix instead (m_clut.Read32(TEX0, TEXA))

Revision 5314

Fix SPU2-X linking issues (I sincerely hope).

Revision 5315

GSdx: Fully disable CRC based hacks when the option is set (by setting the CRC
to 0). Some GSRendererHW::OI_* functions were still active before.
It's good, but this way, when CRC hacks are disabled via this option, those OI_ functions will affect the BIOS, which is identified by 0x0 CRC IIRC.
Might be better to assign a pseudo arbitrary CRC (e.g. 0x31451593) to an imaginary game, add an empty CRC hack function for it, and use this value when CRC hacks are disabled, which will avoid the BIOS issue. If we ever get a duplicate with this value and a real game, a message gets printed at the console for CRC dups, and then we'll change it to another arbitrary value (highly unlikely we'll ever get to that stage though).
0xffffffff might be better tbh, a lot less likely :p
Unless someone has the clever idea to use -1 for smth :p
Option b is to have a global crcsdisabled book flag
Just gave it 0xfffffffe and called it a day :p

Revision 5316

SPU2-X: Quick fix for an issue with dsound configuration dialog where if the
default device is selected, nothing is initially selected in the combo box and
on writing the configuration uninitialised memory is used for the GUID.

Revision 5317

SPU2-X: Tweak the quick fix in the previous rev a little: also select the
default device if a GUID is specified but not present in the enumeration.

Revision 5318

GSdx: Better CRC disable value, using -2.

Revision 5319

linux compilation fix (introduce in r5306)
cool thanks ;p didn't realise linux didn't like elif :P
I'm not sure elif without condition is valid on windows. Here, first 'if' is true so the compiler probably doesn't bother. I prefer this kind of fix rather than template madness ;)

Revision 5320

GSdx: Disable CRC hacks - cleanups:
- 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.

Revision 5321

GSdx: Disable CRC hacks: Yet cleaner, better and more generic. Thx to sudonim.
thanks mr.avihal.
Gsdx now can play tomb raider underwold but only 9-11 fps in HW Mode.
The SW just fine,33 fps in my 3.0Ghz Amd x2 OC'ed computer.
Sorry,my bad english.
why you want emulate tomb raider underworld? have pc version with better graphics and perfect compatibility... i think emulator is for emulate games than don´t have pc version... don´t have any sense emulate this game...
Some games differ from format to format.
Also the manoeuvring is often not as good on PC.
If you're going to ask that you might as well ask why he wants to play TRU at all, it's a terrible game. But we don't ask that around here, we just try to emulate everything as well as possible. (Nothing's going to be done about the games which are extremely slow with the hardware renderer right now though, we know approximately what needs to be done and it is a big job.)
Also, all off topic. This rev is about a developer option.
i dont like pc version.
I just love ps2 version,all the game you know.
I have ps2 console at home,but i'm boring.:D
i love pcsx2 coz the save state..wow.. :D
sudonim..you're the man.
I always support you,guys.
@thiago: There's nothing wrong with preferring a console version of something. I prefer the ps2 version of GTA SA for example. If it wasn't for save states I'd never have made it past the plane missions.
I must say i also prefer console games too over PC,by plenty reasons..
So Thank you!

Revision 5322

gsdx ogl: nvidia compiler is not happy with implicit cast...

Revision 5323

linux launcher:
* 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

Revision 5324

1.0.0 branch:
Merged the SPU2X fixes.

Revision 5325

GIF/1.0.0: Fix some condition bitching from my sloppy coding in r5277 and
integrated the change in to the 1.0.0 branch as it will stop the emulator
complaining about double interrupts.
Can't believe I didn't spot this when I looked over your diff. Glad you caught it yourself.
Yeh it was a bit dippy really >.< at least it's solved :)

Revision 5326

Path3 Masking: Optimization got missed during r5277 revert. Outrun, GTA:SA,
Burnout 2 and others all speed boosted again ;p

Revision 5327

1.0.0: sync linux change from trunk + po translation

Revision 5328

GameDB: Status updates, games that require new gamefixes or don't anymore, etc
GSdx Hackfixes: Lego Batman changed to aggressive list, doesn't really fix
ingame and breaks the title screens.
I wish i could see what was changed (too big I guess). Can you add skipdraws to the db for some games? I've been making comments lately in my issue reports about that.
No, we can't and we wouldn't want to either.
Skipdraw is purely a GSdx thing that depends on the current state of it's code.

Revision 5329

GSDX: Fix splinter cell double agent (and others) regression. Texture cache
hits no longer depend on TEXA ever, GPU load however is increased. The last
regression I think?
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.
If ultimately it results in something good, then that is all that matters. The journey is sometimes more rewarding than reaching the destination.
Does that fix Tekken Tag Tournament speed in every arena like also does it fix hanging up the emu in X-Men Legends and Terminator 3 Redemption (the level when we chase TX with pickup truck) ? If not there will be plenty of code to fix :/
This is for code review and testing results, not arguments about which OS is better. Deleted all the nonsense.
I'm not very sure about this. BUT,it seems give me 10% speed up in FF12 during the CG play. and also a speed up in game.
Well, I test it again. And maybe I made a mistake, or can someone test it and see what happen?
Still, I would appreciate if logz isn't explicitly disabled if the z-buffer is advertised as being 32bit.
I fired up a known "good" version and it seems like the 8-bit texture thing's a wine bug, so I'll go yell at them for that in a moment.
Sorry for inadvertently causing a flame war, just wanted to bring up a few pet peeves I believed were genuine pcsx2 issues; wasn't my intention to bring out the trolls.
Anyways, I'll fire up Windows a bit later and check things out, I'll bother you guys again if I find anything of note.
Sudonim. Are you still working on the code you reverted in r5300?
The reason I'm asking this is that, commit(r5300) fixed the VP2 problem(in r5288) I had mentioned but what I just found out is that your previous enhancement(r5288) had almost fix the red screen issue in the first level of VP2.
When using this revision (R5329) VP2 is back to where it has always be.
The red screen (forest scenes) were not fixed, the effect just looked different and got less in the way.
That's why I said *almost*. They are less obstructive.
It might of helped the red forest but it broke a ton of other graphics, so it's much better the way it is now.
I was also thinking maybe the Haunting Ground Crc hack from cutie should be moved to the aggressive section and restore the previous crc hack for normal.
Maybe it can help you on the 8bits textures. GSdx stores 8bits on the alpha channel (and read back the alpha channel on shaders too). Opengl don't support this texture format, it can only store the 8bits in the red channel. Don't have time yet to test the behavior on my ogl backend, my shader is still reading the alpha channel...
On the Z buffer. I have several depth issues (depth is not cleared properly for example). Anyway I add an option to support logz in the ini file maybe you can try it (not sure it help).

Revision 5330

GSdx: Removed the CRC hack for Drakengard 2 as per issue 1303 .
Thanks for reporting.
(Also replaced broken Chinese characters in comments.)
While I'm glad you like it, if we can keep the comments related to the revision. Thanks
And here I thought there was a problem :p
why is there -1
reason is nothing to write
the angry post is deleted ^^
Nice speedup in Marvel Nemesis Rise of the Imperfects but still i cannot enter the game in story mode cuz it hangs up the whole emulator :/ but improvement is seen in loading of the game so that's good.
@magmaroc this commit simply deletes outdated hackfix for Drakengard 2, it doesn't affect anything else.
rama, gabest or whoever is in charge of GSDX at the moment, could you implement a key for the PS1 side that enables/disables frame limiting, I find it really annoying having to sit through video clips that I can't skip - I would switch to another plug-in but this is the only one with up-scaling support and I find pixelated objects more annoying.
Probably best to go with F4 to avoid confusion when using it in both PCSX2 and a PS1 emu. Aside from that great work, for lack of a better word cudose.

Revision 5331

A couple installer fixes.

Revision 5332

Merge installer fixes.

Revision 5333

1.0 branch: Merge fix from r5301.

Revision 5334

1.0 branch: Merged r5328 and r5330 (game database and Cutie CRC fixes).

Revision 5335

trunk/branch: i18n: update zh_TW and de_DE
If you up for it: "http://forums.pcsx2.net/attachment.php?aid=38741".

Revision 5336

GSdx: 2 more crcs for GoW and GoW2.
For the special game-specific CRC hacks GSdx uses
I posted this in an earlier revision however there was no response so I figure noone is checking that revision now so I'm just copy & pasting.
/* Start */
rama, gabest or whoever is in charge of GSDX at the moment, could you implement a key for the PS1 side that enables/disables frame limiting, I find it really annoying having to sit through video clips that I can't skip - I would switch to another plug-in but this is the only one with up-scaling support and I find pixelated objects more annoying.
Probably best to go with F4 to avoid confusion when using it in both PCSX2 and a PS1 emu. Aside from that great work, for lack of a better word cudose.
/* Finish */
Also side note, getting better speeds out of Wiplash, there is a kinda amusing graphical bug that has appeared though (I'm using a the r5331 bot build on Win7 x64). I'll get a screenshot in a minute to show you what I mean.
Here we go:
Tried disabling speed hacks, no change, everything else is default. Here's a screen shot of my settings:
Alright in that case I'll download the source and try implementing it myself, could you point out where I should start looking. From what I've seen when playing it does seem to disable frame rate when the screen goes blank or a similar event happens and then turns back on when objects and the like are loaded.
Never mind, I think I found where to start, gonna try some code out and see what happens.
Think I'm missing an SDK and I got work soon so I'll have to try tomorrow on my day off.
The SDK I need is packaged with the non-free Visual Studios and I don't have the money for those at the moment. The code I wanted to try was this:
LRESULT GPURenderer::OnMessage(UINT message, WPARAM wParam, LPARAM lParam)
if(message == WM_KEYUP)
case VK_F4:
m_fps = s_gs->SetFrameLimit( !s_gs->m_framelimit );
return 0;
m_filter = (m_filter + 1) % 3;
return 0;
case VK_END:
m_dither = m_dither ? 0 : 1;
return 0;
case VK_NEXT:
m_aspectratio = (m_aspectratio + 1) % 3;
return 0;
case VK_PRIOR:
m_fxaa = !m_fxaa;
return 0;
return CallWindowProc(m_wndproc, m_hWnd, message, wParam, lParam);
I just added in the VK_F4 code, anyone able to try it out? Or has this already been tried?
After having downloaded the trial version I spotted my mistake, trying out something different now.
Sorry for the noob question but...
What is those "crc"?
Did "crc" fix gfx bugs on games?
If so, is this a "automatic" game fix or a manual fix?
crc is the checksum of a game, this is used to identify the game and apply patches that "fix" stuff, however as PCSX2 evolves these patches can sometimes become useless or even a problem in itself. The main reason that they can be disabled is no doubt so that the devs can check whether code they are using fixes an emulation bug which in turn would render the patch unneeded.
Now for why I came here, after much searching through some rather obscure code I finally found the file that controls framerate, the thing is it is not clear what the max frames variable is and I can't try to add a framelimit changing key for psx without knowing this ( unless I try changing them 1 at a time ) does anyone know which it is in the GSPerfMon class?
Thanks @gb2985
You're welome :)
Since noone has replied to my question I would assume they either don't know or there isn't one, either way I am gonna have to try each one myself. This being the case I'll have to do it later on today because I have a volunteer job to go to soon.

Revision 5337

1.0.0 & trunk:i18n update sv_SE

Revision 5338

1.0.0: debian: update the branch name to 1.0.0

Revision 5339

1.0.0 & trunk: add new language th_TH

Revision 5340

1.0 branch: Updated readme and faq by gigaherz. Thanks dude :p
Something I wanna ask, while I've been going through GSdx code I noticed a lot of variables being incremented or decremented on the right hand side (i++) but I'm sure I read somewhere that it is faster to use the left hand side (++i), I figure it is probably like that all over PCSX2 ( haven't gone through that code ), Is there a reason for this or was this done out of habit and the left hand thing just forgotten about?
@gb: It's true that ++i is faster than i++, since i++ needs to do a copy. But compilers do optimizations. So in the end, if the compiler sees an i++ that's not being asigned to anything, it will make it a ++i. So it won't matter if you use i++ or ++i, since in the end both will be ++i.
Fair dos

Revision 5341

GSDx: ATI strikes again. Workaround for ATI sampler bug, the same bug I found
in palette sampling earlier.
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.
*Very* slightly affects speed. Won't be able to measure it outside of GS dumps that run at 1000FPS :p
I wasn't noticing this bug existence earlier, but that's a huge improvement for every ATI/AMD owner^_^, thanks for the fix.
"Huge improvement" is a bit of an overstatement. This only strikes on 1/128 samples on point sampled textures, because from further testing it appears that an ATI card, as I suspected, adds 1/128 of a texel to texture sampling coordinates (or maybe rounds up to the nearest 1/64 texel before further processing), which 1/128 times on point sampled textures will cause it to read the wrong texel. You'll furthermore only normally notice this if using the pixel shader implementation of bilinear filtering that gsdx has for paletted textures. Otherwise it'll normally merely appear as very minor aliasing.
Linear sampling might be similarly incorrect, but the impact there will be even smaller.
How about checking for vendor on the beginning? Then use that to set ATI_SUCKS 1/0
Well at least for me, purely "result based", couse of my middle range gpu with AMD logo on it, which requires using 8 bit textures for like 99% of my games - it is, even if I noticed those glitches before I probably thought it's just imperfect emulation, so + for fixing.;)
Wonder through, if there are any other of such "small stuff" which can be broken for ATI/AMD gpu's. ;c
Checking for vendor is an option, I'd really like to get the driver version too though and I can't see how with D3D10/11/DXGI, although it's clear in D3D9.
Regarding other things maybe affected, DATE uses a point sampler too but it shouldn't be affected because if it's coded correctly it will sample texel centres only; palettes use point samplers but I took care of that a while ago. I'm not aware of other ATI bugs which affect us, but they may exist. So might nvidia bugs, and intel... well we know they exist.
I'm honestly learning towards checking for the bug itself automatically rather than querying the vendor and driver version...
Does the bug applies on what driver version? I'm using 12.6 right now.
Nice. :)
I do not see any slowdowns with 8-bit Texture with DBZ BT 3.
Runs Fullspeed (83 Fps) with 3x Native.
I don't think Nvidia needs this hack. So could it be restricted to Nvidia
If (Detects_ATI) {
//Apply Fix;
Street Fighter EX3 has physics problem with Pcsx2 1.0.
What fighter female is that their costumes are flying.bug or not ?
i test the revision in nvidia , no change for me
it's bug or not ??
@Recoder: That's what I was thinking. Just set a bool when getting the device if it's a DAAMIT one, then with that, define ATI_SUCKS for the shader.

Revision 5342

GSDx: Just slapping some consts on methods I needed to use with const references
in testing.

Revision 5343

GSDX: Removed the collapsing of ge/g and le/l alpha tests in the shader code and
the supporting code in the C++. This was presumably intended to reduce the
number of shaders needed but a) this was never actually implemented, b) a single
developer will generally not mix the functionally equivalent (with a different
AREF) greater/less than with greater/less than or equal to in GS techniques, c)
it really wouldn't make much of a difference to performance anyway and d) it
would make an experimental change I'm working with more complicated and slower.
No change in functionality expected.
Well, if you think about it, now there is an extra step in the dependency chain of instructions executed for every pixel on the gpu (that -/+ 0.5). All your shaders are probably 1 clock slower, which can burn millions of ticks per frame. Doing it on the cpu for every drawing call virtually costs nothing, 100-1000 times, and can be executed parallel with other independent instructions. It was big deal when ps 1.x/2.0 was used and gpus were running shaders anything longer than a few lines ass slow.
If you're going to be concerned about the 0.5 you should probably be more concerned about the trunc.
Also the 0.5 is probably optimised away since the expression already involves adding a value from a constant buffer.
...in any case I'll worry about speed if it's actually measured to be slower. Half of the 0.5s are just because I'm not confident in the result falling just the right side of 0 when dealing with multiples of 1/255.
Oh wait, this was all integers. What I said about the trunc still holds, if you want this function to be fast it shouldn't be doing extra work to avoid working with the raw floats.
There is no theoretical way to optimize this away, clip uses the end-result, it is a RAW dependency.
Rounding is an interesting question, I think borderline problems could surface with or without it, since most calculations are only correct if I use fixed point numbers with 4-bit precision in the sw renderer, but shaders use floats for everything.
Sure there is. The constant buffer is, as the name suggests,
constant. All the driver has to do is add 0.5 or subtract 0.5 before
the first run as AREF is only used in one place in any given shader.
Then tell it to do. It won't.
I'm going through old changes that I don't agree with, is there anything affected by this later on?
As far as I know it's fine but I do think the palette work I did this for was extremely misguided and an item on my todo list is to review all that and revert much of it.
This revision caused problems with "Drakan - The Ancients' Gates" on HW-mode (native and custom).
The inventory menu, and menus like the one at the blacksmith are flickering and distorted.
The problem remains in "pcsx2-v1.2.1-329-g8a43789".
The problem seems to have been fixed.
Maybe it was a problem with the GeForce driver.

Revision 5344

GSDX: Quick ugly fix (major work on this function might be done soon) for a bug
with colclamp I noticed. Unknown impact, might make some effects work.
what should i be looking for?
Well, the feature's mainly used in shadow rendering as far as I know.
:p so i should start with Xenosaga 2/3 xD
Nothing I have is fixed. Sorry :p
It's very likely that no actual games are fixed. The code was wrong nonetheless.

Revision 5345

GSDX: don't unnecessarily create and use a render target for the DATE setup
stage, D3D10+ supports not having a render target set. (D3D9 doesn't, so that's
what would this affect?
Speed, memory usage. In a completely unnoticeable way.

Revision 5346

GSDX: New interpretation of destination alpha testing to improve effect
rendering as an optional hack. Known to make shadows in the persona games (and
thus probably shin megami tensei) better, not sure what else it accomplishes
without destroying other effects.
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.
...I always feel bad about writing more about the code than actual lines of code, but when someone looks at the code in a couple of years and says "what's this crap?" they might be able to find out.
Fixes Xenosaga 2/3 shadows
unsure about 1 just yet... that'll require another new game
eh, spoke to soon, it just behaves the same as the offset hack :|
btw sudonim, GSDX has gotten a tad unstable lately.
i can reproduce GS Plugin has failed to open" pretty reliably just by starting xenosaga, loading a game, closing the emulation window and trying to configure GSDX
Looks like Closing the emulation window is not the same as clicking pause and having the window close?
should i log a bug?
Uh, yeah, that's a bug and I can reproduce it. Don't know what's going on but I doubt it was recently introduced.
By the way, you don't need to close the GS window to configure the GS plugin, that would be why we haven't noticed it.
Okay, pretty obvious. The destroyed window's handle is being passed. Not sure why we're destroying it at all, hiding is normally fine.
Hilarious :D
One of the reasons we may destroy the GSdx window is to force a re-init when the plugin configuration has changed. Though we can just do that when an actual GS plugin configuration happened.
...I was an idiot for trying to be civil. Deletion time.
This fixes shadow in SMT: Nocturne. Though it didn't work at first. I had to disable all CRCs, otherwise it has no effect.
Is this normal?

Revision 5347

GUI: Closing the GS window didn't update the structure telling plugins about the
window. Decided that just hiding the window has less race potential.
As for that other thing i mentioned, closing the window was preventing a crash that i experience when i open and close the gsdx settings a few times.
changing of any settings is not required, all im doing is opening then closing the gsdx config. Though i just realised i might do this 8-12 times if i hit OK, but if i hit cancel instead it might be 4-6 times before the emulator generates an exception.
...well I just opened gsdx's configuration while the emulator was running about 40 times and nothing unexpected happened.
ok, i goofed up. I forgot i still had the SMAA Injector's DXGI.DLL in the pcsx2 folder. After renaming that i've opened it like 20 times so far without a hang. Also works WITH the smaa injector as long as fraps is not running, must be one of the overlay bugs mentioned on the site
I guess i should just file a feature request for SMAA in GSDX itself

Revision 5348

1.0.0: Merge r5347, remove zerogs and zerospu from installer.

Revision 5349

1.0 branch: Fixed typo in the readme.

Revision 5350

Re-added prafull to the beta testers list, he got lost somehow.

Revision 5351

Tag the 1.0.0 release

Revision 5352

Rename the 1.0.0 branch to 1.0 in case of further patches

Revision 5353

Bit of cleanup in our /pcsx2/docs folder

Revision 5354

Reorganize the tags folder, get the ancient files out of the way.

Revision 5355

Cleanup part 2: Renamed the readme and faq where they're referred and upped the
trunk version to 1.1.0
delete cmakekist:

Revision 5356

Update installer version string.
Damn so many New Revisions great Work, i wish the jpcsp would be that great as you Guyz, i think they REALLY need Help...
I think PSP Emulation Development is very Hard...
what do you Guyz think is it really that big Difference between PS2 and PSP Emulator Development?
Yes. Completely different worlds. PSP is emulated at a higher level, by simulating the results of syscalls and firmware modules (as far as I know), while the PS2 is emulated at low level, by implementing the hardware itself. Each method has different advantages and disadvantages, and although it may be possible to emulate the whole ps2 in high level, the early attempts failed so it became a mostly low-level emulator.
On the other side I don't think anyone has had any need to document the hardware internals of the PSP, since the standard firmware already provides all the necessary modules for homebrew (unlike the ps2 bios).

Revision 5357

GSDX: Simplified and improved (for my purposes) the D3D11 checks a little.
Necessary for something I'm working on, hopefully doesn't break GSDX for anyone
(this code took a lot of revisions initially as I recall).

Revision 5358

GSDX: Adapter selection in the configuration dialog. Effective on D3D10/11 and
probably on D3D9. D3D9 will not enumerate adapters with no connected outputs
and I haven't actually tried connecting my integrated GPU to a display, but
D3D11 doesn't care.
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.
...I missed some stuff, typical.
GSDevice11.obj: error LNK2001: unresolved external symbol _CreateDXGIFactory18
this what??
See my comment. Fixed in the next revision.
- - sorry
Damn network latency

Revision 5359

GSDX: missed the property files, VS is awkward about saving them.

Revision 5360

GSDX: And combo boxes are apparently weird about vertical size.

Revision 5361

Cleanup part 3: Update the cmake files in /trunk and /1.0 and upload the readme
and faq pdf to /trunk
Thanks for the cmake update.

Revision 5362

GSDX: reduce precision requirement for DATE, partially fixes Intel GPUs. (Not
sure exactly what's going on here, I think that 0x80 as a 8 bit unorm isn't
exactly the same as 128.f/255 but I don't know whether it's required to be... we
can just play safe on this anyway).

Revision 5363

GSDX: Temporary fix for another unorm precision issue.
Please read some games 30 FPS and 60 FPS not reach, what happens to the new version or svn?
ah! I forgot for a medium capacity laptop as a i5 2.30GHz, 4GB RAM and Intel graphics .... could give solution to that? .... thanks
saberkura: This is not a support forum. If you want help go to http://forums.pcsx2.net
If you just want to know how the new svn versions work, go to the download section on http://pcsx2.net and try it yourself.

Revision 5364

* properry separate both GLSL implementation
* glsl4: Use a define for logz instead of extra math computation. Much more
easier to understand

Revision 5365

gsdx ogl:
* 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

Revision 5366

i18n: use standard pcsx2_Iconize instead of an additional key lookup. In others
word, english string is now included directly in the po/pot
Translators note: I save previous translation but a careful review is mandatory
Swedish transltion updated: http://forums.pcsx2.net/attachment.php?aid=39536
I guess that when all translation have been updated you intend to merge Main and Iconized, is this so?
Thanks for directly including. it's more easy to edit. and I update ko_KR po file.(correct 1 fuzzy)
thanks ;) I'll review the translation when I have the time.
I'll review and update my translation as soon as I can. Should I be updating the guide too Gregory or will you release another guide for v1.0?
I only manage gui translation. Guide is done by Bositman :-)
Oops that's right, my bad. ^^
@pgert, I don't have any plan to merge Main and Iconized. Main is already big enough and I don't see any advantages to merge them.
Updated polish one as well:
I wonder why current svn version is 1.1.0, through it'll be 1.0.1 now.^^
Updated the Turkish one. :)

Revision 5367

* 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
The "before" situation happens as well in archlinux. 32bit libraries in 64bit systems are installed in /usr/lib32, but cmake verifies /usr/lib/LIBNAME which is a 64bit library.
Is there any chance you could fix this situation too?
It expect directory under /usr/lib
Can you try to set this variable:
Looks like it works. Recognized /usr/lib32 and built pcsx2. But just to mention that some warning messages showed up: http://pastebin.com/LmDZ22Dq
1 line-by-line comment
line 68:
68: ./pcsx2
How about './pcsx2 [email protected]', to allow users to pass arguments to PCSX2 from command line?
cool. The warnings are "normal", don't have any impact. I just don't know how to shup up them.
Good idea.
With "-Wno-dev", according to my log. I didn't try it, though.
Which warning? I deals with cmake warning.

Revision 5368

VIF: Some optimizations for the VIF Rec, some small clean-up/optimizations for
VIF itself.
what should i be lookin for, boss?!
umm, speedups i guess.. lol. It's probably negotiable but hey, every little helps, right?
I think negotiable meant negligible :P (Am i correcting the native english speaker? wtf -_- )
BTW, you can find some solid bug reports in the forum, the first 5 or so are all valid and tracked to a specific rev. Have fun :D
don't worry, hes British, they have free reign at bastardizing the language :D
negotiable was the word i wanted. I noticed small speedups, others didn't, you can negotiate if it does or not :P
but yes negligible would work too.
blimey little britard :p
1 line-by-line comment
line 42:
42: if(vifX.irq && !CHECK_VIF1STALLHACK)
I don't have a clue how the VIF works but I think the "!CHECK_VIF1STALLHACK" in that if changes the behaviour of the code, since it will make it break too early? In the old code it never returned before setting the irq.
Forgot to say, I think moving that check to a separate if after setting the irq to true would restore the behaviour, if the change wasn't intended.
That was intended and should have similar effect to the original code.
the reason the check is before the set is because it shouldnt break until the current vif code (which this is on) is complete, so putting it after setting it would break out before the vifcode has even run, thus breaking it.
Moreover, if we are at the end of a vif data chain, you don't need to check to break out as it's going to do it anyways, so it doesn't need checking at that point, so it would be a pointless compare just slowing the loop down :)
Eh I meant after setting the irq, not at the end ;P it's just a matter of breaking before or after the irq has been activated ;P
if you checked it after the irq has been set, it will break then, you don't want it to break then as the vif cmd has to run first :P
introduces Issue 1325
This revision breaks the game FUTURAMA (see Issue 1343 )

Revision 5369

Fixed Issue 1311 : UI percentage values sometimes save incorrectly to ini file.
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.

Revision 5370

New: Allow changing the language at any time.
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.
If "Change Launguage" is always in english, then so should also the wizard be on restart, but only if it has been summon through "Change Language".
Didn't test that, but this only re-invokes the wizard, which allows changing the language on its first page.
The title of the popup and the text on the OK-button arn't in english.
It looks kinda bad.
I was happy to see this option, but actually by trying it today I must say it's a complete failure. It does only activate the wizard and guess what "clearing all settings" DOES EXACTLY SAME:]... The existing option also just invoke wizard, it doesn't actually clear anything, the wizard does it. Saying soo I guess this option is a duplicate of previously existing one. ~_~;

Revision 5371

Fixed: Change-Language menu item was a checkbox (plain menu item is enough

Revision 5372

Fixed a bug pseudonym spotted. stalls should be handled properly once again on
games that have IRQ's on VIF Mark commands.

Revision 5373

Game fixes: Extended the OPH hack a bit to set APATH to each path in turn in
addition. Should make the hack fix some Eurocom games (Sphinx and the Cursed
Mummy, some Buffy thing, others?)
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
Oh, meant to mention that refraction debugged this in the commit message, oops :P

Revision 5374

Added the new OPH hack to Sphinx the Cursed Mummy and Buffy the Vampire Slayer.
Both should run fine now, only tested Sphinx though.
was this applied to both the pal and ntsc versions?
the fixed work on both versions of chaos bleeds
Yeah, both versions. A bug like this is usually coming up in all regions of a game.

Revision 5375

gsdx ogl: incorporate DX sudonim's changes on ogl

Revision 5376

gsdx: remove completely the SDL backend. Let's hope I didn't break too much VS
cmake: take the opportunity to drop the support of 3rdparty compilation.
Distributions have got a more recent version of zlib/soundtouch anyway.
Forget to say default GAMEINDEX_DIR is now /usr/share/games/pcsx2 instead of /var/games/pcsx2. The file is not really writeable, so it must be in /usr/share
5378 won't build, so i suspect this
can you provide me the log? I doesn't have windows so I can't check
its ok, Sudonim just fixed it with 5379 :)

Revision 5377

3rdparty: remove SDL code source (and reduced 3rdparty size by 40%)

Revision 5378

* 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
* Allow to use command line pcsx2 option with the linux launcher script. Thanks
Rafael for the idea.

Revision 5379

Removed the SDL project from the visual studio solutions.
Shadowman2 (ntsc) gives ingame a black screen after Menu and loading(sound keeps going on). 5372-5379. 5371 ingame full (with known problems - environment textures.) pal does not start at all, not even menus. keep it up guys <3
Ps. I really appreciate what you guys are doing. Every time i see a new menu/addition i feel like it's christmas day. Nintendo sixtifooooour :P

Revision 5380

More vif work to fix Shadowman 2 and improve the function of some parts. Gave
vifstalled a more specific job and reasons for the stall. Also did some work
with the irq offset, seperating it from the stalls.
Savestate bump needed.
And somebody was telling me not be one game specific and now i see fixing only one game? What bs is that?
Its for us the users to not be requesting game specific stuff. For the developers of pcsx2 they can be as game specific as they want to be. Their the ones who are taking the time to code all of this for our benefit afterall.
So end of the day, if you want your game working better dante2, then your more than welcome to go code in the changes yourself.
Actually i broke Shadowman 2 due to incorrect emulation, i was merely correcting it and improving the system, this was not a single game fix.
if you're fixing emulation then it's definitely good regardless of whether it is game specific or not cause the eventual result will general purpose code that emulates correctly with enhancements.
BTW where can I find source code for Peop's plugins so I can try porting over the PS1 frame handler into something GSDX can use ( or at least try adding compatibility for ).
gsdx already supports PSX graphics
I wonder if it will be possible to launch psx games on pcsx2. I know this might be stupid cuz there is another emu but cmon ps2 launches psx games as well so when emulating console why not emulate its all abilities?
I know GSDX supports PS1 graphics what I meant by frame handler is the toggle of the fps limiter during runtime which GSDX currently does not support on PS1, I noticed during usage that Peop's plugins work together to control the fps themselves with the gpu plugin controlling the fps limiter, what I wanted to do was incorporate support for that since I like how high the internal resolution can go and the simplicity of the settings.
Hey, if you need peops sources, you can prolly still find them on pete's website.
some games.. ex: guitar hero 3
gsdx plugin..
please don't clog the comments with entirely unrelated bugs
thx for url
Problem changing UI language when restart
If select Turkish > Apply >Next > Prompt in Thai
If select Thai >Apply> Next > prompt in Turkish
If select English(US) >Apply>Next> prompt in English
And what does that have to do with this revision at all icu?
@willianholtz1, check next revision. I think I fix it.
PS: better ask a linux dev on the linux issue ;)

Revision 5381

GSdx ogl: Fix a nasty crash because of the multithread hack.
canditate for 1.0 branch
great! fixed! thanx @gregory
Excellent - Appears to fix recent crashes in Katamari games
+1 for including in 1.0 branch

Revision 5382

Make PCSX2 compile with Visual Studio 2012 (1/3): Workaround compiler
differences that result in compile-time errors.
NOTE: The 'glew' project does NOT build yet, but it will have to be decided how
to approach the problem (String literal too long in glew.rc)

Revision 5383

Make PCSX2 compile with Visual Studio 2012 (2/3): Copy project files and
solution from their vs2010 originals. Not updated yet!

Revision 5384

Make PCSX2 compile with Visual Studio 2012 (3/3): Upgrade the project files and
fix a few project names. Update the .sln to point to the right project files.
NOTE: Other than glew, I noticed the Zero* and ZZogl* projects don't build in vs2012, but I had those unloaded because I didn't really care about them.
Thanks for the bunch of commits here :p

Revision 5385

ZeroGS/vs2012: "count" is a function in the vs2012's std:: namespace, so it
conflicts to use count as a variable when "using namespace std;" is in place.
Renamed the two instances of that issue to "counter".
It still doesn't build, but I'm not sure how to solve the SAFESEH issue right now.
does zeroGS serve any value anyway? it's not active. aka DEAD. cut it off the main line. tho you might still wanna keep the code in the rep for some guys that wanna fling it for some some specials. i know there are some hidden. ;)

Revision 5386

Turn off SAFESEH for ZeroGS and ZZogl.

Revision 5387

Remove glew from the 3rdparty libs. It's not currently used by any project.
... which calls for an update of "CompilationGuideForWindows" & "CompilationGuideForLinux"?
To avoid any misunderstanding. Linux does use glew for opengl plugins.
Extra clarification: It uses glew, but NOT the one that was in the repository. It uses the distribution-provided package instead.
In linux, the glew version for these plugins must be 1.7.0, or could be latest (1.8.0) ?
I don't really know but, is there a reason the basic API would have changed from 1.7 to 1.8? Seems like it shouldn't be the case.
Better be the latest because they fix some bugs. Otherwise you can use any version (>=1.6.0) as Giga said.
Ok, then I'll use the latest version for pcsx2-svn. Thanks gigahertz and gregory.

Revision 5388

Missed one reference in he vs2008 sln

Revision 5389

[vs2012] ZeroGS/ZZogl: Also disable SAFESEH for the other targets, not just

Revision 5390

Added loading of external shaders, coded by KrossX (thanks again :p ).
Right now it looks for a file called "shader.fx" in PCSX2's main directory.
If it finds one, the PageUp key activates the external shader (instead of the
built-in FXAA).
We have a forum thread for some nice shaders to try out here:
Code r5390?
where's the GUI dialog for that kinda stuff. you know you should do one. ;)
you want it?
you do it.
Sorry for the old patch, I never updated it for the r5284 changes. >_<
Comparison screens would be nice :)
Any comparison screens would be appreciated :)
KrossX3: No worries, it's in now :)
Good function, but I'm using PageUp key for gamepad input. It is getting difficult to map the 24 buttons to the keyboard without hitting some keyboard shortcut. At this rate, using a real gamepad will soon become part of the system requirement.
Personally, I'd not touch the emulator without a game pad.
The keyboard is really just a short term workaround for me.
I think you could remap they keys somehow but it's not my field.
i think i saw the fps drops about 12fps after turning on shader?
I used x3 scaling which already maxes my GPU. Adding any work then sharply drops fps.

Revision 5391

New optional gamefix detects when a full motion video runs and temporarily
switches GSdx to software rendering mode.
This is a workaround for the many FMV issues that occur in hardware rendering
and that will take a while longer to get a proper fix.
It doesn't have any checks for the current video mode, so don't put GSdx in
software mode and expect this to adapt, okay? :p
Note: It's possible to get crashes from switching renderers so please report
those if you get them.
Thanks!, I've been waiting for something like this, no longer need to run in native / software mode for videos to work properly, works great in rule of roses , ffx-2 , dirge of Cerberus
Great it works for others, too :p
Yea, I tested Rule of Rose and FFX-2 and decided this would be nice as an option :p
Great work, this is very convenient. Is it possible to make it switch aspect ratio too, or at least map F6 key to controller like Tab (turbo)? With widescreen hacks it's a pain to switch back and forth
I don't get what the problem is, imnotaweeaboo.
The aspect ratio is controlled by PCSX2 and should stay the same on renderer switches.
Tested it in Warriors Orochi 2 and it works smoothly, no crashes so far. No more flickering textures in videos.
Great idea!
In Shadow Hearts (NTSC-U) [SLUS-20347] seems to work perfectly.
No change for Baldurs Gate - Dark Alliance (PAL). Even with this gamefix on the game still freezes during the first FMV. Though that was happening before and after this revision with both hardware and software modes so this was of no surprise. Look forward to playing this in pcsx2 one day.
Dark Alliance just doesnt work with videos at all, you have to use the skipmpeg hack to get past it. This does cause corruption on the screen in the menus but allows you to get in to (the very broken) ingame.
Hi, does this help the Dynasty Warriors 5 Pal intro movie? That in the past flickered and stopped responding at some point of the movie had to skip movie with start button.

Revision 5392

Vif Unpacks: Fixed Issue 1325 with Non-SSE4 processors.
Put in some handling for MPG Overflows (VIF command, not videos :P)
Fixed another SSE Unpack bug i came across - Effected THPS Project 8
I just noticed i put Temp Directory instead of Temp Register. There's a force of habit for you lol. Stupid IT job >.<
well its nothing needing an immediate re-commit atleast.
I approve of everything refraction does (Abbas from #pcsx2)
mVUmergeRegs() isn't actually used by the VU, also the case i added only actually happens with the VIF recompiler behaviour, so any changes i've made there wouldn't affect the mVU even if it did use that function. It actually has its own functions for doing this and doesnt use this as far as i can see.
as for not signing correctly, the only real change i did for the non-sse4 version was change the xMOV32 to xMOV64, so the original one wouldnt have sign extended properly either, so im not going to bugger about with it unless it really causes a problem, ive literally just made it copy 2 lots of the vectors instead of 1 in to the temp reg.
If this does cause further problems of course ill look in to it, but as it is, it should work fine.
and since the emulator actually works :>
ah yes i see the error with the extending now.
as for the src == dest thing, it needs to be masked in this case, else data gets left in from the shifting around on non-sse4 processors and then it writes crap to the VU's causing corruption on the .Hack games, It's been changed around so it doesnt clear out the work reg for repeat itterations so the tempreg becomes the source and the destination (this is only for setting the masks) and then the mask information becomes rubbish when adding it to the unpacked data, so we have to check the source/dest and mask out the mask stuff we don't want.
The sec==dest thing is for the mask writing not this :)
Thinking about it, I could probably just set IP a seperate function soley for that mask function and take it out of there. Will do so later :)
Changes of this revision break Odin Sphere.
Comment by rozanski.michal.mr, Sep 8 (5 days ago)
Changes of this revision break Odin Sphere.
Can anybody confirm this in this revision?
also if it is the case, is it okay with supervu?
This is how it looks in r5391:
This revision:
awesome! lol, okay will check it.

Revision 5393

Found and hopefully fixed a really long standing DMAC bug.
This gets videos working in Katamari Damaci, Baldurs Gate, Tales of Destiny 2,
Suikoden Tactics and others.
May fix other games as well, these are just the popular ones :p
So, about why this might be right... in order to modify any bits of CHCR except for STR you have to stop the DMA... but because this change works, stopping the DMA probably does actually mean specifically setting the STR bit low before a subsequent write to other bits, regardless of whether the DMAC is disabled. Disabling the DMAC just guarantees that writing 0 to STR will be effective probably and doesn't actually affect the writable status of the bits directly.
This is obviously something we should write a test (to run on real hardware) for, we'll do that later.
If Baldur's Gate, then Bard's Tale too?..
I have to try that...
Time to test Tales of Destiny Director's Cut! =D
It should work :)
It doesn't. ='(
Aww. Well, anything I threw at it that needed the skipmpeg gamefix works now.
would you hate me if i said the katamari videos were broken long before i rewrote this bit of the dmac? :P
it is interesting how that fixes it tho, should make hunting down the real problem easier
Yea, I've been working on this for ages now. I know it's always been this way :p
great fixes the ace combat movies (tested ac4)
Great job!
Midnight Club 3 is working now (tested Remix version)
Red Dead Revolver should work now too.
Yaaay!.. Bard's Tale intro doesn't hang the emulation anymore!!!
Now it's time to figure out the weird texture bug there (both HW and SW modes)
This revision is marvelous, started testing all my hanging games, so far these games have been fixed:
1. Twinkle Star Sprites La Petite Princesse
2. Guilty Gear XX Accent Core Plus
3. Flipnic - Ultimate Pinball
Also tried Neo Contra and Quake 3 Revolution but didn't do the trick.
Good job, as always :) .
Also fixed:
4. Rozen Maiden Gebetgarden
5. Rozen Maiden Duellwalzer
Baldurs Gate getting some revision love? yay. I'll go test.
Confirmed as fixed for the FMVs. Game didn't even freeze at the main menu and I made it to the heavily broken in-game. Nice :). Great work.
Fixes for blizzard engine games are great! Thank you ramapcsx2.
Do you think you can work on the in-game problems with blizzard engine games? gigaherz has previously said that he thought it was a problem with the core PCSX2 and not a video plugin bug.
We're all aware of the Snowblind Engine games (not Blizzards ;) ) being broken.
I'm working on it sporadically where working means trying stuff until its magically fixed :p
you think this might fix the infrequent Xenosaga video errors that would occur at times?
No idea, it depends on what the problem is/was :p
This has fixed cut scenes in Ace Combat 5. Yay!
Well done :)
Can we get the new latest revision on the download section so i can help by testing Suikoden Tactics and Dynasty Warriors 5 both PAL that had problems in the past on movies.
Finally some progress of Ace Combat games as well!
ummmm ladies sorry to revive such an old post but i don't know where else to share my good news... The bards tale opening has been fixed by the wonderful OGL addition in Rev5682 all i did was switch to OGL (Hardware) even and opening works fine and so does the game for me!! on both Hard Ware and Software with OGL using nvidia GT460SOC

Revision 5394

Optimistically removed all the SkipMPEGHack gamefixes from the database.
I think this calls for an official Hotfix sense we can play FMVs now.

Revision 5395

onepad: reduce a bit (75 pixels) the heigh of the dialog for NNNNx768 displays

Revision 5396

Bleh: some really unproductive hacking on DOA2 implementing the noted "better"
way to patch the previously patched function and a poorly understood hack to get
past the black screen (but the US game just breaks later if you do this). All
of this is commented out, it's just for the benefit of my future self when he
comes back to trying to fix this game.
Current status: the pad rpc hangs in the second iteration of the main game loop
for an unknown reason.
I saw this title get ingame today so kudos :p
Well by "in game" you mean the title screen, one menu then everything broke. If you actually want to see it in game, get the Japanese version :P
Baldurs Gate Dark Alliance now also goes in-game, but the emulator seems to crash in the intro sequence every time at almost the same moment (when protagonist walks in the town and narrator say: "...the town seems deserted")...
It would be very nice if someone could figure out the cause of the weird texture and half screen missing bugs in Baldur's Gate and Bard's Tale common game engine...
I'm a bit confused, is this progress on just DOA2 or DOA2 Hardcore also?
It's not progress at all, but I was looking at the boot issues with DOA2HC (US) and discovered that they can also occur in DOA2 (JP) depending on timing. I don't understand this issue yet and am probably not going to work more on it in the near future, rpc debugging would probably help.

Revision 5397

SPU2-X: Fix a minor logging bug.

Revision 5398

SPU2-X: Don't force align transfer addresses, fixes The Bouncer. I honestly
don't know on what basis they were force aligned in the first place. The
Bouncer very strangely has correctly aligned sample data in IOP memory which it
uploads using an unaligned DMA with SPU2 set to an unaligned address, resulting
in the data being correctly aligned in the end. Weird. It also writes the
address twice in the order high word, low, low, high, the first pair being
aligned and the second pair not. Really weird.
Looks as if devs actually got two bugs in the code which even themselves out with no side effects on the real console... :)
great, no more piano sounds, shame it's such a short game :).

Revision 5399

SPU2-X: TDA is a fake internal register (which should probably be nuked), so
reading from the FIFO (or whatever 1AC is) certainly shouldn't use it. Also
fixed up related code a little. We don't know of any games which actually use
this though. Actually I don't know if we know that reading this register does
anything, this could all be the product of an overactive imagination.

Revision 5400

SPU2-X: Add the alignment check to console logging.

Revision 5401

SPU2-X: cleaned up the re-enabled debugging messages from r5400.

Revision 5402

SPU2-X: Use zero coefficients when the sample data references a higher entry in
the coefficients table than we know about and print a warning to the console if
logging is enabled. Fixes audio glitches in "Crash" series games. Also fixed
the voice stop log, it was printing when voices looped.
Good job, finally got somewhere with the Crash games :)
Great work. I actually ran into that bug a while ago and thought nothing of it. Nice to see it's finally fixed
Crash as in Crash Bandicoot?
Does it mean that the only remaining broken game in SPU2X is LeMans 24 Hours (which for some bizzare reason works better with ZeroSPU)?
I read a report on the forum about broken sound in "Parapara Paradise" (which seems to be practically impossible to obtain for testing by any means) and I think rama knows a couple of other games with sound bugs.
Yep. Fixed all sound-related problems in Crash Tag Team Racing (including that annoying static noise) for example.
God of War textures bugs in Dx11 our Dx9 and crash in Gran Turismo 3.
Visit our forums if you want to report unrelated issues.

Revision 5403

[VS2012] For some reason when I made the conversion I totally forgot to copy
these, and I didn't notice that until yesterday.
If anyone wonders, those files give the virtual "folder" structure within a visual studio project. Without them, you get all the files in one place, at the root of the project.

Revision 5404

VIF: EXPERIMENTAL, NOT SANITY CHECKED: Delayed VU execution until the next
flush, mpg, microprogram call or (as a fallback) end of dma packet to deal with
cases like MSCAL, UNPACK, MSCAL (expects the first program to receive the unpack
Fixes Snowblind's games (BG Dark Alliance etc.), Mortal Kombat Shaolin Monks.
May break things, needs extensive testing.
Finally got behind that :D
To people testing this:
Unfortunately Snowblind engine games can't be enjoyed yet due to GSdx bugs in software and hardware ><
I just realised that I wrote a fairly non-obvious workaround which further extends (this time justifiably at least) the horrible vif state object without any comments. My first draft had comments but I got something wrong and just broke every 3d game completely so I got frustrated and reverted that and rewrote it. I'm too tired to be doing anything so I'll do something stupid and ask here what I should explain in comments (particularly you, ref, since you work on this code).
crashing in gsdx?
Nice. Even more revision love for Baldurs Gate. Thank you. Every step taken to fix those games makes them more playable.
Just did a quick play test of Dark Alliance 1 and damn what a difference. Sure only half the screen is displayed as per always, but you can now see all the 3d models in-game properly now.
Did try baldur's gate dark alliance 2. The game don't freeze anymore. Still there is nothing in zerogs and half-screen in gsdx hardware mode. The only workaround is gsdx software. It worked but poor fps and pcsx 2 crash because it is out of memory. But the screen is fully shown in software mode. :) One more step to be fully playable.
Cannot like this enough. Thank you sudonim! Finally some progress in these kinds of games. Any chance you could do a Blog post about this? The blog has kind of been left in the rain for quite a while and this is a big fix that I'd love to read about!
I don't really do blog posts. I'll maybe do one when I finish something really big and important. Maybe. Explaining the really big things is almost as much work as coding them. More if it involves diagrams.
This case is just "game does something bad (which the developers probably never even stopped and thought about because it worked) we can support with a little extra code".
In CON:RTA there are still some problems but it has been improved a lot. The half black screen (can be fixed with software but I just thought I should say it) but it also has a problem with video memory. It runs out of video memory if you move around and that'll disable texturing and cause the ground to flicker.
Joshikousei Game's-High!! completely broken when load savestate in this revision. I was able load savestate in previous v5393 and game is fully playable.
Tested it a little bit... Cool...
@tony... Did you notice savestate version bump?.. It's expected that old savestates are incompatible anymore...
the version bump wasn't mentioned in the log comment so i wouldnt be surprised if it escaped a fewpeople.
tonyluey: Savestates will regularly break with revisions, it's quite likely this will bugger games up which are in 3d at the point you make the state.
Well states should still work within this revision :P
As far as save state compatibility goes, I changed the size of a structure so if I hadn't bumped the version you'd just get corrupted data. Actually it might've been okay for backward compat I guess, I could change it to only be a minor version bump.
No wait, that's no good, the state doesn't contain the size of the structure as saved. No backward compat for you.
Haven't tried it yet but it's nice to hear that some preliminary work has been done to solve the issue to a certain extent.
This isn't really preliminary work, as far as pcsx2 itself is concerned the game's fixed, GSDX issues are separate.
Btw, you can probably patch your pcsx2.exe with the large adress aware bit and get less out of memory errors from GSdx software.
Do note though that PCSX2 isn't prepared for this and something might fail.
Really?.. I thought it runs out of some "internal" "virtual" memory addresses, not the actual RAM... I' ll try it right away...
WOW, cool... "Large-Address-Aware" flag does the trick... Now the game does not crash in Software mode, just becomes very slow when allocated memory reaches 2,5GB (32bit can't allocate that much and crash)...
However, HW mode uses only ~500-600MB and would be playable if someone get rid of the "half screen" bug...
the excessive virtual size is because gsdx is allocating equivalent virtual memory for the video data.
i saw a microsoft article detailing how not to do that at one point, but it would just cause pcsx2 to crash when hitting the limits of available video memory i would guess.
"This isn't really preliminary work, as far as pcsx2 itself is concerned the game's fixed, GSDX issues are separate.", thx but I called it preliminary because it is experimental and not classified as stable and as far as I know experimental means that there is still more work to be done, for example the "excessive virtual size" would eventually need to be sorted out.
I'm no expert on graphics handling but maybe the raw textures themselves could be stored in temporary directory until they are needed, whilst the info about them would be kept in a simple array.
Experimental means that this change is fairly drastic and I'm not sure it won't break things (seems good so far though). The GSDX issues have _nothing_ to do with this.
Oops, sorry didn't notice this weren't part of GSDX, well anyway most of what I said still holds, "more work" can just mean testing and depending on results bug fixing, depends on situation really but yeah I'll shut-up about that now, it's a fairly pointless topic and is off track from the original post, I only used it because I like using fancy / big words :D
Great work!
I need to test this with shadowman 2 actually, the delay in the vu processing may have a similar effect to the code comment i made which is now in the vifqueue function :)
Just curious. What do you thing "if (!idx) startcycles = VU0.cycle;" would do?
Breaks Warship Gunner 2 graphics/textures =(

Revision 5405

onepad: reduce dialogs of another 25 pixels for small screen.
Why not set it %. Everytime changing the size isn't good.
Well it is too difficult to get the size of the screen. The size is only the minimum size. The window can be extended for people with normal screen (ie not crappy laptop screen)

Revision 5406

SuperVU: fixed null pointer dereference in constructing an exception object.
SoulReaver2 works until 3467 well. 3468-5406 makes startmenu flickering and ingame the Environment/objects flicker. Ntsc version only tested.
ops, 5367 well. 5368-5406... :P
Off topic in this revision and not surprising, that commit and friends are on my list to review.
This comment actually has to do with GSdx + wine (again), and is completely unrelated to this revision.
I've been investigating a bit, and I think I may have gotten to the crux of the depth-buffer issues with wine with the d3d9 backend.
First, these lines in GSDevice9, which are used to testing whether or not certain texture formats are supported
Wine, returns success with D3DFMT_D32, which is mapped to a GL_DEPTH_COMPONENT32 (unsigned int) texture.
As I've established with previous posts, in Windows 7 I have access to "logz", which would imply it fails creating surfaces with the D3DFMT_D32 and D3DFMT_D32F_LOCKABLE formats and falls back to the D24 + stencil format.
I do not think the wine devs are doing anything wrong here...
Meanwhile in GSDevice11.cpp, you will find that the depthstencil buffer is created using the format, DXGI_FORMAT_D32_FLOAT_S8X24_UINT, which is 32bit floating point with a stencil buffer.
Since D3DFMT_D32 is an unsigned int format, I've hacked wine's d3d9 DLL to return unknown format for it so that it would fallback to D32F_LOCKABLE.
Unfortunately, due to not so recent regressions (in wine mind you), have made it impossible to see how this affects Persona 4.
I was able to get ingame with Nocturne, though. There is still some Z-fighting in the distance, but it's much, much better than either D32 or D24S8, irrespective of the state of logz.
Now some queries, sorry if they seem a bit confrontational
1. with the D24S8 format in Windows 7 and the D32 format in Wine, rendering with the d3d9 backend produces identical depth fighting - albeit without the option of logz to make it more manageable. Is the d3d9 renderer set up to make proper use of a 32bit unsigned int depth buffer if available?
2. The d3d11 backend uses a floating point format. The d3d9 supports a floating point format (D32F_LOCKABLE) as well, but prefers the unsigned integer variant (D32) over it. Wouldn't it make more sense to have it the other way around?
That really is off topic, but...
logz: The configuration dialog doesn't know much about the capabilities of your GPU and thus does not disable the logz control. The only way to know if D3D9 is using a 24-bit format (unless I have a printf I forgot about and can't find) is to toggle logz in a scene where it would have an effect (e.g. just about any scene in persona 3 or 4).
1: Yes. No special code is required for this in fact.
2: No. We would in fact prefer fixed point but that isn't available for some reason in D3D11. C'est la vie.
The check to disable the logz control in the panel was removed some time ago.
This toggle has an effect in Windows 7 but none in wine (as I've mentioned before).
I've had to turned it on by force via hex editing the shaders bundled in the plugin.
I'm rather surprised to learn the DGXI_* formats don't have a 32bit fixed point equivalent, though
Anyhoo, I'll keep digging and see if I can find anything else, thanks for that!

Revision 5407

i18n: update 2 strings not aligned on current gui
Close issue 1323 and issue 1322

Revision 5408

GSdx, linux: remove some letf-overs

Revision 5409

* merge commit 5381 (that fixed some GSdx ogl crash)
* update debian package with the good branch name

Revision 5410

i18n: long awaited update
* New nb_NO (only main, iconized was bad)
* update tr_TR/it_IT/ko_KR/pl_PL/pt_BR/sv_SE
* refresh pot/po

Revision 5411

i18n: Apply pg patch to better detect the system language

Revision 5412

gsdx: update the copyrigh address thank to sed

Revision 5413

Modified my changes from r5392, one small fix and some code movement, thanks to
DarkShoelaces for pointing it out.
Also cleaned up the DMA change made in r5393 and added a small comment of
explination to why it is now right :P
That's a great cleanup job! Is this functionally the same in terms of the r5393 changes?
Yes, just removed the old useless code and explained a but why the change fixed it :p
Probably not, hopefully it fixes some recent issues.
Breaks sega superstar tennis :/

Revision 5414

GUI: All GS window settings should now apply immediately regardless of the state
of the window. (Window size and resizing border were not applying correctly.)
Out of topic, but related:
Modification of "Enable Cheats" won't apply while a game is running.
The user have to pause the game, modify "Enable Cheats", and resume the game.
I guess the same is true for "Automatic Gamefixes".
If these fatures can't be supported while a game is running, why not have the menuoptions grayed out while a game is runnng?
You're right, that is off topic.
Click on the task bar and back on the PCSX2 window.
This is a common issue (I have it myself).
When i press F4 or F6 in game i got nasty bug with GS window.
^ this is actually is fullscreen. For example:
window mode. At first I thought it was because of GSdx, but later it revealed that it's a issue from this revision (it doesn't appear on r5413 or earlier).
drdevl88: Fixed in r5423.

Revision 5415

SPU2-X: Trigger interrupts only if TSA is incremented to IRQA on the basis that
we know that the final TSA value after the transfer is checked. Also fix
inconsistency in TSA after transfer in one case. Fixes Chaos Legion bgm.
Testing together with the 4T fix. So far so no regressions :)
r5415: This revision caused audio-distortion in "Project Zero 3".
4x: Hour III: The subduing song - Intro (awakening in the manor of sleep).
Full\Fast Boot makes no difference.
Cheats (WideScreen-hacks) on\off makes no difference.
DX9\DX10 makes no difference.
SSE2\SSE4 makes no difference.
"EE Cyclerate" affects grade of distortion; the higher EE value, the more distortion.
"Wait for Vsync on refresh"\"Dynamically toggle Vsync depending on frame rate" affects distortion; if enabled, there is more distortion.
"Progressive Scan" makes no difference.
r5414: No problem.
Problem remains in r5492.
... and the problem is there both in HW & SW mode.
Well shit.
Your pain is my pain - lol.
More info:
The distortion is also in "Project Zero 2" (Chapter 1).
And it remains in r5530.
Update: Problem remains in r5731.
Problem remains in "pcsx2-v1.2.1-529-ge019979",
but enabling "Disable Effects Processing" takes care of distortion :).

Revision 5416

SPU2-X: Removed the temporary "TDA" variable from the core structure. Breaks
state compatibility.

Revision 5417

SPU2-X: Fix old crash on state load if logging is enabled. (It's appalling that
this is in the state though.)

Revision 5418

SPU2-X: Delay starting voices for 4 SPU2 cycles after key on. No idea if this
is right, but there must be a reason some register writes aren't effective for a
few cycles after key on, and this seems likely. Fixes DQ5 adventure log music
and Le Mans 24 Hours everything.
And breaking savestate compat again, not that anyone cares since I did the same earlier today.
Great stuff here. This was a random guess but so far it seems to be correct.
Or at the very least works well with our IOP time slices. Real testing needs to happen later.

Revision 5419

Make IOP module loads visible in dev builds as well, not just debug ones.

Revision 5420

Fix from refraction for the recent VIF changes: Unbreaks Sega Superstar Tennis.
Thanks for doing that :)

Revision 5421

SPU2-X: Add extra exceptions to shortcutting silenced voice processing (which is
basically a speedhack and should probably have a GUI option). Unfortunately
this is a significant speed hit for all games, but I have no solution to this
for now. Fixes Gegege no Kitarou - Ibun Youkai Kitan and quite likely others.
It is a 3% fps hit in very fast scenes, think 950 to 920fps.
Not measurable in normal scenes.

Revision 5422

zzogl: some experiences to EGL (on linux). It can be enabled with -DEGL_API=TRUE
* EGL is the interface between the window and opengl. The purpose is to replace
GLX/WGL in a crossplatform way.
Unfortunately so far only opensource driver use it (need not yet released mesa
* clean most of the legacy GSopen1 window management. Only keep a basic window
for debug with replayer.

Revision 5423

GUI: Don't resize the window automatically while it's maximised or fullscreen.
(Annoying consequence: if you change the GS window size setting while it's
fullscreen or maximised, the setting will be overwritten by the resize event on
restoring to normal size. Seems to be far more hassle to work around than it's
god job,guys.

Revision 5424

1.0.1: Merged some revs, marked a load for not merging (clear bug fixes only)
and experimentally started up a news file to make releases easier.

Revision 5425

SPU2-X: Another change to the shortcut processing of voices, check the actual
loop flags in memory rather than the ones in the voice structure because the
memory might've changed. Fixes Innocent Life - A Futuristic Harvest Moon.
Also, check both cores rather than the current core, that was a mistake.
Speed-- again.

Revision 5426

SPU2-X: Update effects engine indexers when the effects area is moved and kept
the same size. Not doing so caused SPU2 memory corruption in Sphinx and the
Cursed Mummy and maybe others.
Save state compatibility broken.
"Save state BACKWARD compatibility broken"?
Older save states do not work with this version anymore.

Revision 5427

SPU2-X: Add an assertion that I used (in a more stupid and long winded form) to
find the effects memory corruption bug.

Revision 5428

Games database update, fixing an error and adding the EE timing hack for Tony
Hawk's Underground 2.

Revision 5429

GamGames database: Removed Tony Hawks again. The problem was already fixed.
Yes, GamGames is a word now.
+1 for GamGames

Revision 5430

Add NFL '12 to the database and silence a SPU2 cache clear notice.

Revision 5431

User submitted updates for the game database. Thanks for compiling them, pgert.
Thanks for applying.

Revision 5432

linux: allow to use the shell interpreter to execute the launcher script =>
"bash launch_pcsx2_linux.sh"

Revision 5433

wiki: refresh linux compilation guide
* new cmake option
* add build.sh for basic compilation.
* clarify that PCSX2 can be installed on a 64 bits system that support multiarch
Good job keeping this up to date :)

Revision 5434

Added correct clamp modes for GT4 to the game database. Fixes various issues
with the GUI.
Also added a mark for Klonoa 2 problems with SPU2-X.
woow =). I remember that I wrote about this issue a week ago. Thanks for fixing it.

Revision 5435

Added a new variable for defining a 'release to public' build which replaces the
automatic system we had before. The automatic system doesn't work well with
planned updates.

Revision 5436

license: update the copyrigh address to please linux distribution
And that's exactly why having license headers on every single file is the wrong way to do it.
Right, we should redo this as soon as possible.
On linux this kind of commit is few seconds although it impacts lots of files. I use this kind of command to update license:
sed -i -e '[email protected] Temple Place, Suite 330, Boston, MA 02111-1307 @51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,@' *.*
It will do a seach and replace in all files.
By the way (don't know if it exists on window, never used neither) do you know Cocinelle? Might be useful one day.
Description-en: semantic patching tool for C
Cocinelle is a program matching and transformation tool for C.
The programmer describes the code to match and the transformation to
perform as a semantic patch, which looks like a standard patch, but can
transform multiple files at any number of code sites.
Removing the license headers is not a solution (unfortunately) because linux distributions require it. Besides it is easier to track license info when you move/copy/paste file.
Yes I know they require it, which is very annoying. The files should only have something like... // This file is Copyright ... and licensed under the ... // For the license terms read LICENSE.txt, or browse ...
And you wouldn't have to potentially change dozens of thousands of files in a large project, just because the FSF wasn't happy where they lived ;P

Revision 5437

* move all remaining glx into the dedicated GLwin object
* rework a bit WGL to separate opengl context and window creation (like linux
gsdx: Allow to control vsync. Not sure I used the good extension.
* check that EGL opengl context creation
* Shut up gcc warning when force inline might not work...
It's not compiling here, it gives me this error:
CMake Error at cmake/FindEGL.cmake:17
or something like that :P
Which cmake version do you have? What is the exact error message? And what option did you use? By default cmake doesn't include the EGL module.
Test latest version and hopefully it will be fixed.
Tested, now it's fixed but grey screen in zogl PG 4.0 :( (It doesn't work), but the zzogl PG 3.0 works fine >_<
Could you test latest trunk.

Revision 5438

zzogl: Check the size of both rectangle and 2D textures. Hopefully will fix
Sandybridge system. Tests are welcome.
cmake: be sure that EGL is supported

Revision 5439

cmake: policy existence must be checked on older Cmake version...

Revision 5440

zzogl: fixed crash at startup for Intel (and probably nvidia too). Opengl3 and 2
don't support the same set of attributes

Revision 5441

GSdx: only enable AMD hack for AMD GPU. Remove the older geometry shader hack
fixed since 6 monthes
ZZogl: support xdg for the replayer
AMD Radeon HD 6850, Driver: - Catalyst 12.10 (9-27-2012) - GL_NV_copy_image is supported ;)
Yes I know, that why I removed the unsupported text string ;) However I would like to replace it by the ogl 4.3 equivalent. Which might be supported one day by opensource drivers. Anyway I'm not sure the code work as expected by GSdx.
Testing for specific gpus is very bad and this bug occurs on intel gpus too, at least on windows.
Wait, I'm thinking of a different bug, aren't I? Still, testing for gpus is bad, testing for the bug is right.
Sorry for posting this here, but this bug is quite old - anyone can look at Issue 951 ?
Yes you're right, I can do somethings better.
GSdx ogl is not designed for intel window driver that limit (for no real reason) the support version of ogl3.1 on SB. I think they release on ogl4 driver for IB, probaby because they learnt that the opensource driver will reach OGL3.3 next year.

Revision 5442

gsdx ogl:
* retry compilation when driver failed to compile with a static 'index'
constraint. Replace previous AMD hack.
* clean context default attribute value
zzogl 4: clean context default attribute value too.
zzogl 3: backport texture size fix
The purpose is to avoid a bug in the driver not to make it faster ;) Unfortunately there is another bug in the driver which corrupt blending (it takes only 1 fragment color, instead of 2 to compute blending) but first I would like to be sure that it working properly for others drivers/GPUs.
hi gregory, not r5442 but as this was the last one in which someone touched gsdx i thought this would be the best place.
So...i just compiled r5445 in release with strip=true, i'm in ubuntu 12.04, pae activated with mate as desktop. Phenom II X6 1055T @3.5GHz with a HD 6950 with the HD 6970 bios using catalyst 12.10.
The problem only happens when you use gsdx in openGL (software/hardware) and sdl (soft/hard), not if you select null (soft) or null (null).
Trying to boot, either full or fast crashes with the cpu at 100% (1 thread) in the Opening plugins.....Opening GS part.
In the console output it crashes at:
X-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
do you want me to compile everything in debug or is that enough?
Set the debug_ogl_shader option in GSdx ini file.
=> inis/GSdx.ini
debug_ogl_shader = 1
Rebuild with strip=False, it doesn't make code slower but easier to debug.
Opening plugins...
Opening GS
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
/home/me/pcsx2build/pcsx2-read-only/common/src/Utilities/Linux/LnxHostSys.cpp(64) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x0000001c
Closing plugins...
Closing GS
<froze at this point>
no difference in debug.
also as a note: i had to enable console to stdout, or else it wouldn't show
anything else? :P
Normally a pop up must appears with a stacktrace. Did you try a debug build? It would help me if you can generate a backtrace from gcc but I'm afraid it would be hard. Maybe you can try the patch below. It will add some debug on the console.
Index: GSDeviceOGL.cpp
--- GSDeviceOGL.cpp (revision 5442)
+++ GSDeviceOGL.cpp (working copy)
@@ -222,12 +222,15 @@
{0, 4, GL_FLOAT, GL_FALSE, sizeof(GSVertexPT1), (const GLvoid*)offsetof(struct GSVertexPT1, p) },
{1, 2, GL_FLOAT, GL_FALSE, sizeof(GSVertexPT1), (const GLvoid*)offsetof(struct GSVertexPT1, t) },
+ fprintf(stderr, "Before Buffer \n");
m_vb_sr = new GSVertexBufferStateOGL(sizeof(GSVertexPT1), il_convert, countof(il_convert));
// ****************************************************************
// convert
// ****************************************************************
+ fprintf(stderr, "Before comp \n");
CompileShaderFromSource("convert.glsl", "vs_main", GL_VERTEX_SHADER, &m_convert.vs);
+ fprintf(stderr, "After comp \n");
CompileShaderFromSource("convert.glsl", "gs_main", GL_GEOMETRY_SHADER, &m_convert.gs);
for(uint i = 0; i < countof(m_convert.ps); i++)
CompileShaderFromSource("convert.glsl", format("ps_main%d", i), GL_FRAGMENT_SHADER, &m_convert.ps[i]);
@@ -1349,6 +1352,7 @@
header.copy(header_str, header.size(), 0);
header_str[header.size()] = '\0';
+ fprintf(stderr, "Before likely buggy implementation\n");
*program = glCreateShaderProgramv(type, 2, sources_array);
// Check the correctness of the driver
I tried the debug build last time but no message at all.
Anyway, just downloaded r5442, applied your patch and compiled with debug and strip=false, then ran it normally and with gdb (no difference though) and "got" a backtrace though it says it's corrupted and stuff :(
I've never used gdb with threaded stuff and openGL so I've no idea how to interpret this, the only thing I see is that the plugin's main thread is the one causing the segfault.
Tried both with 5 and 0 extra threads but same result, here are both.
Initializing plugins...
Init GS
Init PAD
Init SPU2
Init USB
Init FW
Init DEV9
Plugins initialized successfully.
[Nuevo Thread 0xb17ffb40 (LWP 8678)] <<<<< (New Thread....)
Opening plugins...
Opening GS
[Nuevo Thread 0xaa2f8b40 (LWP 8679)]
[Nuevo Thread 0xa8cfeb40 (LWP 8680)]
[Nuevo Thread 0xa84ddb40 (LWP 8681)]
[Nuevo Thread 0xa7cbcb40 (LWP 8682)]
[Nuevo Thread 0xa749bb40 (LWP 8683)]
[Nuevo Thread 0xa6c7ab40 (LWP 8684)]
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
Before Buffer
Before comp
Before likely buggy implementation
Program received signal SIGSEGV, Segmentation fault.
[Cambiando a Thread 0xaa2f8b40 (LWP 8679)] <<<<< (Switching to thread....)
0xa4b0dc12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
(gdb) bt
#0 0xa4b0dc12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
#1 0xa321bba0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
this is with 5 threads, the one with 0 is basically the same, just different virtual addressed :\
Plugins initialized successfully.
[Nuevo Thread 0xb17ffb40 (LWP 8816)]
Opening plugins...
Opening GS
[Nuevo Thread 0xaa2aeb40 (LWP 8817)]
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
Before Buffer
Before comp
Before likely buggy implementation
Program received signal SIGSEGV, Segmentation fault.
[Cambiando a Thread 0xaa2aeb40 (LWP 8817)]
0xa7392c12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
(gdb) bt
#0 0xa7392c12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
#1 0xa5a1bb00 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
hope this helps :(
Thanks very much for you data. GDB tells you it a crash in the GL implementation (aka AMD drivers).
Anyway, execution is fine until "Before likely buggy implementation". I already got some crashes with glCreateShaderProgramv on ZZogl but not on GSdx (was on hd5770...). To confirm it can you try to use this small patch (a basic run without gdb will be enough).
I expect to crash before printing "Crash point"
Index: GSDeviceOGL.cpp
--- GSDeviceOGL.cpp (revision 5442)
+++ GSDeviceOGL.cpp (working copy)
@@ -1349,7 +1349,9 @@
header.copy(header_str, header.size(), 0);
header_str[header.size()] = '\0';
+ fprintf(stderr, "Before likely buggy implementation\n");
*program = glCreateShaderProgramv(type, 2, sources_array);
+ fprintf(stderr, "Crash point\n");
// Check the correctness of the driver
GLint slot = glGetFragDataLocation(*program, "SV_Target1");
Could you test this patch on a clean svn. Hopefully it will fix your crash issue. It might crash later however, let's see.
Index: pcsx2.snapshot-5438/plugins/GSdx/GSDeviceOGL.cpp
--- pcsx2.snapshot-5438.orig/plugins/GSdx/GSDeviceOGL.cpp
+++ pcsx2.snapshot-5438/plugins/GSdx/GSDeviceOGL.cpp
@@ -1349,7 +1349,13 @@
header.copy(header_str, header.size(), 0);
header_str[header.size()] = '\0';
+#if 1
+ const GLchar* ShaderSource[1];
+ ShaderSource[0] = header.append(source).c_str();
+ *program = glCreateShaderProgramv(type, 1, &ShaderSource[0]);
*program = glCreateShaderProgramv(type, 2, sources_array);
// Check the correctness of the driver
GLint slot = glGetFragDataLocation(*program, "SV_Target1");
patched a clean r5442 with the first patch and it crashed after the "crash point" part :P
console output from the first patch
Opening plugins...
Opening GS
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
Before likely buggy implementation
Crash point
/home/dario/pcsx2build/pcsx2-read-only/common/src/Utilities/Linux/LnxHostSys.cpp(64) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x0000001c
Closing plugins...
Closing GS
tried the second patch in r5442, r5438 and the lastest but it threw an error everytime, no idea why :(
anyway....patched 5442 manually.I added a little fprintf just after the if 1 to know the patch worked :P
nothing, crashed at the same place.
Opening plugins...
Opening GS
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
Executing patched route
/home/me/pcsx2build/pcsx2-read-only/common/src/Utilities/Linux/LnxHostSys.cpp(64) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x0000001c
Closing plugins...
Closing GS
rev 5438 had a different function for *program so i didn't try it :(
also tried with the lastest rev (5452) and spamed the buggy area with "fprintf(stderr, "at line %i \n", __LINE__ );" in everyline. The last it printed before crashing was the one before "GLint slot = glGetFragDataLocation(*program, "SV_Target1");". Also added some usleep before that line just in case it was some kind of race condition but no, the seg fault occurs exactly at that line
Opening plugins...
Opening GS
[Nuevo Thread 0xaa24cb40 (LWP 13669)]
glX-Version 1.4 with Direct Rendering
Supported Opengl version: 3.3.11978 Core Profile/Debug Context on GPU: AMD Radeon HD 6900 Series . Vendor: ATI Technologies Inc.
GL_ARB_shading_language_420pack is not supported
Executing patched route
at line 1355
at line 1357
at line 1359
(int)program A9901458 / *program 2
sleep 10 sec at line 1369
sleep 5 sec at line 1371
continuing at line 1373
Program received signal SIGSEGV, Segmentation fault.
[Cambiando a Thread 0xaa24cb40 (LWP 13669)]
0xa7392c12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
(gdb) bt
#0 0xa7392c12 in ?? () from /usr/lib/i386-linux-gnu/dri/fglrx_dri.so
#1 0xa5b1bb00 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
let's keep trying :P
forgot to mention it but gsdx from r5325 worked fine. (although it crashed when entering the load screeen from FF-X soi had to use zzogl) I'll see if i can find myself some time to find in which rev it stoped working.
Can you comment this part ie put // in front. This part avoid a driver issue for HW renderer, SW is fine.
GLint slot = glGetFragDataLocation(*program, "SV_Target1");
if (slot == 0) { // <=> SV_Target1 used same slot as SV_Target0
GLint index = glGetFragDataIndex(*program, "SV_Target1");
if (index != 1) {
fprintf(stderr, "Driver bug: failed to set the index, program will be recompiled\n");
*program = glCreateShaderProgramv_AMD_BUG_WORKAROUND(type, 2, sources_array);
just tried it (with r5456) and IT WORKED FINE!!!! ^_^
and it didn't crash at the load menu!!!!
well the soft renderer works fine now, also tried the hardware one and although it didnt crash at first, it was glitched to hell and ended crashing when i tried to enter the menu. Can't wait to see it finished and working :P
well till the next bug :P
............ Hum.................. Great I need to fix the code that fix the drivers....
By the way, what is your driver version.
The latest crash and some glitches are AMD driver related. Nvidia seems to be fine. An opensource AMD driver would help me a lots. It only miss a couple of features so far.
I'm using catalyst 12.10 with my HD 6950, and yes, if you check phoronix you'll see that catalyst is known for its long standing annoying bugs.
Radeon works fine with my card but it's slow,so I have no other choice, plus I loss the openCL capability
Yeah I often read phoronix. I know very well the status of catalyst because I got an HD5770 ;) It seems they introduce new bug in recent version mine is only 12.6.

Revision 5443

VIF: Fixed a bug which caused PATH3 masking to fail if there was an IRQ on the
FlushA command while it needed to wait. Fixes Futurama Issue 1343
Also re-fixes Soul Reaver 2. Good job :)
Terima kasih

Revision 5444

Hide the "Disable GS output" option since it's currently broken.
All this commit does is hiding the option in the GUI.
this is unrelated but are commandline switches working now or is it still a work in progress heven,t been online lately and have been wonderin about this for a while now
the others developers make a good changes but you make minimun changes man...
This emulator is complicated, if you think you can do a better job then bloody do it, ungrateful fool!

Revision 5445

SPU2-X: 2 known games set an illegal reverb EEA that randomly causes crashes in
the plugin.
We need to figure out what real hardware does with it but for now let's disable
the effect engine in that case.
Affected games: Summer Beach Volleyball and 18 Wheeler.

Revision 5446

SPU2-X: Disabled the parked voice processing optimisation completely for now.
Fixes Silent Hill: Shattered Memories, maybe others. Reduces speed for all
games. However much you hate this change, I hate it more.
For all it's worth, I did a comparison of 2 PGO builds.
One with this change, one without.
The 2 perform nearly the same (1390 points with optimization, 1370 without).
This change is good though, as it more correctly resembles the real SPU2.
I'm pretty sure we fixed that one a while ago.

Revision 5447

Modified the way SPR accesses the VU memory as the old method doesn't seem to
work with the VU's since the MTVU change in r4865. Fixes Summoner 2 in Issue
1354 .
Probably is a better way of doing this, but this works ;p

Revision 5448

fix the masks in the previous commit, habits die hard :P
"0x11010000" - "0x10FFFFFF"?
....this looks wrong to me. a) addr & 0xfff0 means that you'll be accessing more than 16kb of VU1.Mem. b) addr & 0x3ff0 means you'll be accessing 16kb of VU0.Mem, which is only 4kb. You mean addr & 0x3ff0 for VU1, addr & 0xff0 for VU0.
Furthermore this special casing is only necessary for VU1.Mem, which has a handler rather than block mapping in vtlb now. Micro memory isn't necessary either I think, there's nothing I know of to indicate that it can be accessed (note that the condition containing this code starts at 0x11004000)
Probably not, expected you to negative it anyway, feel free to alter it if you like.
In hindsight it should have been 3ff0 and ff0 but I'm in bed now so if you could change it :p
Off topic:
i think splinter cell-chaos theory (pal,sles 530xx) have a problem with SPS just like mortal kombat shaolin monks..in the first level i guest,lighthouse..
Pcsx2 r5350.
pcsx2 r5444.
Win 7
2gb ram
amd x2 DC 3.0Ghz Oc
8600gt nvidia
my english bad,sorry..

Revision 5449

Corrected masks again, apparently my brain refused to function properly last
night. Thanks for pointing out my noobness Sudonim1
bah i left f's at the ends for VU1. Sod it, it gets masked out before then anyway.

Revision 5450

Like this?
I had to laugh,
can't explain why.
Yeh that's it :p

Revision 5451

Fixed Prince of Persia Sands of Time by increasing the VU kickstart cycles a
( Issue 1341 )
Awesome work rama. This fixes Prince of Persia : The Two thrones too. :)
Fancy this?
const int s = 1024*8; // Kick Start Cycles
// Silver Surfer needs 1024*6, Prince of Persia - Sands of Time & The Two Thrones needs 1024*8.
const int c = 1024*1; // Continue Cycles

Revision 5452

Add a dev notice for a tweak point with VU0 Macro/Micro updates.
This is rare and I'd like to know when games trigger this.

Revision 5453

Game Database: Removed the IPU busy patches from Neo Contra as they're not
helping anymore. Also added the OPH hack for Motorstorm Arctic Edge.
Maybe Neo Contra stil works soon? Or not?
No luck with it yet.

Revision 5454

A few more revs for the 1.0 branch.

Revision 5455

1.0: Merged new release flag system.

Revision 5456

Game Database: Added the OPH hack to Tomb Raider Angel of Darkness, making the
game playable.
It also needs to be started via full boot. Issue 1355 is about that.
Finished this game some time ago, didn't know there were any problems exept for this Font bug.
Maybe you could remove the remaining skip video patches for the some games (e.g. Midnight Club 2/3) which are not needed anymore (Fixed since r5393).

Revision 5457

Game Database: Removed Midnight Club 2/3 skip video hacks since they're reported
fixed (after r5393). A few other, rarer games still have video skip hacks
Actually there never was such a hack in place for DUB/DUB-Remix editions, despite experiencing the same issue :P
Good 2 more almost perfect Games.

Revision 5458

GSNull: Stop it calling itself "Firewire" in the config etc.
It's still called "Firewire" in the Config menu, and in the BIOS/Plugin selectordialog.
Or is that something else?
Make sure to rebuild the project, a simple build won't pick up the resource file change.
It works for me here.

Revision 5459

SPU2-X: Made the message "KeyOn after less than 4 T disregarded" less visible on
release builds. It tended to slow games down.

Revision 5460

SPU2-X: Actually ignore successive writes within 4 ticks to the same key-on bit,
don't just say we do. I think I just forgot this return in r5418. Fixes The
Legend of Spyro: The Eternal Night (probably the other two legend games too).
Good, this should be a safe change anyway.
The only other game that comes to mind that even triggers this is
Ephimeral Phantasia and that still works.
Tales of Legendia?
I remember that i played up to 70% of the game without problems?
ib HW mode,she has problem again?
Sorry to spam this as its not the place,but i must finish the above...
Tested tales of legendia,and it still works perfect.
Maybe someday silent hill,origin/shatered will be fixed in hw mode..
Its now playable but....
great work. This really messed with TLOS:TEN causing massive lag. Do you guys have any idea why software mode also removes all HUD elements as well when toggled? Cause it's pretty much the only way the true colors of the game come out. Otherwise, even the skybox is dark and gloom, completely lifeless..
Different developer, so no.

Revision 5461

GSNull: Change the register set definitions to structs instead of unions so it
ACTUALLY writes the data to the registers, rather than just writing to 2
predefined variables then being overwritten the next time a write is done to
something else :P
The original code was correct, please revert and think about it harder.
Really? cos i've been using it and if you write to a register, say TEX0, then write to something else, say TRXPOS, the original data has been wiped.
These are type definition for a register of a given width (the _u32, _u64 and _m128 members are for raw access) which can be one of a set of specific registers. e.g. further down in this file, a GSReg is a GSRegBGCOLOR or a GSRegBUSDIR or a GSRegCSR etc. It is entirely intended that all members access the same memory. These are not definitions for machine states.
Incidentally there is absolutely no need for gsnull to process unprivileged register writes, they have no effect if you don't emulate drawing (which is the point of gsnull).
And yes, I know that these types are not used properly in this plugin. Nobody noticed that a plugin designed to do nothing is coded sloppily, go figure.
I noticed as im dabbling with stuff and these changes ive made work, this code as it was didn't
Well yes, in particular the GSVars struct uses GIFReg incorrectly. But that's a problem with GSVars, not these macros and the types they define. The types they define are useful and are CLEARLY meant to be the unions they were before your change.
Alright ill look at changing them back to be unions. Seems to work this way though so im in no dire rush ;p

Revision 5462

That warning was annoying me :p
Bleh didn't notice :p

Revision 5463

cmake: always use /usr/lib/i386-linux-gnu when it exists

Revision 5464

gsdx ogl: don't check dual source support on SW mode to avoid a crash on SW
mode. (note HW is still crashing but better than nothing)

Revision 5465

Creating a branch to backup and track future progress on my attempt to make the
internal ISO reading code asynchronous.
Feel free to ignore the question but what does this do if I might ask?
It avoids slowdowns in the emulation core caused by reading the .iso files. This is not very noticeable in a modern HDD or SSD, but it becomes important if you are using an USB or network disk to store the files.

Revision 5466

async-iso: Current state of the code. It was done on vs2012 so only the vs2012
project file is updated with the file changes.

Revision 5467

async-iso: Fix non-debug builds.

Revision 5468

Fix blockdump reading, the disc type wasn't being properly detected.

Revision 5469

Fix blockdumps containing 2352byte sectors.
Great, this is good enough for in house testing now :)
Finally :)

Revision 5470

Attempt at making blockdump loading faster, may go either way.
Worked, shaved off valuable seconds :p

Revision 5471

async-iso: Uncomment and fix the blockdump creation code.
There are some things left to do before this branch can be merged back, the most important of them are:
1. Update the vs2010 and vs2008 projects with the file changes.
2. Create the FlatFileReaderLinux.cpp file with Linux-compatible async I/O.
I can do 1a (vs2010), but I don't have vs2008. And I don't know enough about Linux to do 2, so I will need help on that one.

Revision 5472

async-iso: Update the vs2010 project files.
(Update from r5471)
There are some things left to do before this branch can be merged back, the essentials being:
1. Update the vs2008 project file with the changes.
2. Create the FlatFileReaderLinux.cpp file with Linux-compatible async I/O.
I would appreciate if someone can help with those 2, since I don't have vs2008 nor experience in linux async I/O.
For linux, saturday I got some bookmarks. As far as I understand there are severals aio IP on linux.
1/ posix based on some internal threads (userspace). Scale poorly
2/ kernel api (kernel space). Faster but with limitation (not sure they hold because doc is very old)
If I understand correctly, 1 vs 2 mostly depends on the numbers of simultaneous IO. Let's go for case 2 besides IP seems to be easier to port from MS api.
I will need to find some free time slots to do it ;)
There's always the option to use a thread and use standard synchronous I/O within the thread.
I'll do the 2008 files, once done with work :p
Thanks to you both. ;P

Revision 5473

async-iso: Some cleanups.
Oh Hi Gigaherz nice to see some nice Work of you, but i got a Question about this Plugin, In Monster Rancher 4 will we now be able to import some Monsters with Disc/Iso swapping?
Thanks in Advance
This is not a plugin, it's just a change to the internal ISO code so that it doesn't stop the emulator while it reads from the HDD. It doesn't change anything on iso swapping at all.

Revision 5474

async-iso: linux. Create an empty FlatFileReader implementation. It will be
completed later based on https://code.google.com/p/kernel/wiki/AIOUserGuide

Revision 5475

async-iso: Fixed MSVC 2008 project file.

Revision 5476

async-iso: finish the linux port
Warning new dependency libaio. Cmake would need to be fixed later too.
Is this good enough for trunk?
Yes, with my latest cmake addition :)

Revision 5477

Vif: Modified VIF FIFO reverse while VIF is active hack. Now just makes sure
VIF is stopped before it swaps direction either way. Fixes Sled Storm.
This is down to the nature of how our emulation works. This is one of those games that watches either the memory address or the amount left to transfer. We clear (or set these to the end) way before it actually "finishes" as far as the system is concerned. So if it's checking either of these and carrying on when the condition is fulfilled, it will confuse our emulation.
Hey guys, can you make option to disable all game fixes and hacks? ;)
you can disable all game fixes already, just not hacks :P
Yeah, in GSDX here few options allow to disable CRC's, but i always use only Software rendering and think some hacks still here. Accurate emulation brings me a lot good feelings. ^_^
Uh the build bot thought this was a linux build for some reason so we don't have a windows build? :S
Buildbot was broken, Orphis is on it

Revision 5478

Just adding a log to devel builds. This is a curious case we want to be notified

Revision 5479

* add cmake plumbing for libaio
* add Native EOL style on cmake file

Revision 5480

SPR VU Access: Changed VU0 back to using physical memory map addresses, Doesn't
seem to work the other way. Fixes CSI 3 - Dimensions of Murder SPS
Looking at the code again I see exactly what's wrong, that it's not specific to VU0 and how to fix it.
return (tDMA_TAG*)VU0.Mem + (addr & 0xff0);
return (tDMA_TAG*)(VU0.Mem + (addr & 0xff0));
And make the same change for all four cases, everything will work.
I did think it was something like that, cheers :)

Revision 5481

SPR VU Access (Again): Managed to get VU0 working the way we wanted it, thank to
sudonim1 for pointing out where i was failing.
Also added a check for a possible scenario where SPR may try and read/write
crossing VU0 memory boundaries in to mirrored space, could cause issues in games
if it happens.
Good work :)
The comment section on google code isn't the best place for that especially giving a revision a negative for no purpose. Theforum is much better suited for issues playing games and if needed a bug report can be made.
please don't randomly negative commits because you have a problem, it doesnt "encourage" us to help. If you have a problem, go to the forums.
Are all these positives overcompensating the negative, or just fixed shit? XD
I think it's overcompensating :P
im just hot for ref ;D ;D

Revision 5482

VIF VU Execs: Fix for r5404 (the fabled Baldurs Gate fix). Need to check that
when VIF ends there is no queued VU Exec left else it gets abandoned. Fixes
freezing in Legends of Wrestling 2, possibly fixes the graphics on Warship
Gunner 2
So, are the snowblind games finally playable?
Still not. Split screen issue + slow downs still occur. GSDX problems for the most part.
The split screen issue is solved with software mode, graphics still flicker occasionally due to memory problems but it is playable.
Nope. Graphics in Warship Gunner 2 is still broken=( It's like they are missing in some parts of a ship
I mean textures missing
Okay i will have to see if i can get hold of the game from somewhere.. Unless you can make me a blockdump with instructions on what i need to do to get to it, then i can look in to fixing it.
Wow software mode does fix the split screen issue now. NICE. Not playable due to the slowness and flickering graphics but these games are inching closer and closer to playability :). +1 positive from me.
It runs full speed on my i7 920 @ 3.8Ghz and GTX 570 ;p you just need a damn good PC lol
Just tried r5483 on generalplots machine and airship gunner 2 is absolutely fine. Please make sure you are using the correct version, since the buildbot was missing exes you might have been using the old version still
Sorry. I don't know how to make this blockdump thing(( I used the latest version for every file there. I have NTSC-U version of the game
Tried running Dark alliance 2 on software mode, only got around 50 fps, and some messed up sound on a 3500k @ 4.5ghz :P Same for you refraction?

Revision 5483

Core: Changed when scratchpad DMA waits on the VU1 thread with MTVU active,
might fix/speed up something.
yeh we know about that. as long as you have a much older SVN revision of the 1.0.0 release it will have that file there already so it won't be a problem.
all afflicted builds are being replaced as we speak with complete packs.

Revision 5484

Merge async-iso branch into trunk.
There are such sites as http://pastebin.com/ that are designed to avoid this sort of pointless spamming.
If you switched from an older version of Visual Studio, you need to Clean before compiling, or hit Rebuild.
Yeah I'm using 2010 so I'm not sure what happened but rebuilding w32pthreades and wxBase28 fixed it
question: what was this branch's purpose?
See r5465
i see
thanks :)

Revision 5485

Merge (replace actually) trunk into async-iso, so I can begin working on an
experimental implementation of a read-ahead queue.

Revision 5486

async-iso: First iteration of the experimental read-ahead system.
In this iteration, a simple read-ahead scheme is used where the next expected
read begins as soon as the CDVD code calls FinishRead.
The expected improvement is close to 0 since a similar system is already in
place in the core.
The next iteration should have an internal buffer, and use completion callbacks
to initiate read-aheads as soon as the previous read is done, without waiting
for the emulator to fetch the results of the previous operation.
F*ck, I commited the wrong folder >_<
haha good job

Revision 5487

Revert previous mistake.

Revision 5488

async-iso (really now ;P): First iteration of the experimental read-ahead
In this iteration, a simple read-ahead scheme is used where the next expected
read begins as soon as the CDVD code calls FinishRead.
The expected improvement is close to 0 since a similar system is already in
place in the core.
The next iteration should have an internal buffer, and use completion callbacks
to initiate read-aheads as soon as the previous read is done, without waiting
for the emulator to fetch the results of the previous operation.

Revision 5489

async-iso: Fix detection of flat-file NRG images.

Revision 5490

Backport the NRG fix to trunk.

Revision 5491

Fix the fix, one line got lost during the backporting.

Revision 5492

Make a rare IPU chain mode transfer error log be DevCon only.
The only known game to run into it is fine anyway (Phase Paradox).
You can now close issue 982 :).
(ref was supposed to hide this error awhile back but must of forgotten about it)
It still is a problem but right now we can only assume that it's either corruption, a corner case on how the IPU operates or it actually happens on the real hardware and is ignored.
moisesfurbino: I sincerely doubt it. In fact, I'm willing to put money on the fact it wasn't this commit.
just try a few recentish ones that affect pcsx2 (not the async stuff) and you should find where it was fixed. This commit merely changed how a warning is displayed in a certain scenario, there was no emulation changes.

Revision 5493

[No log message]
Whoops, I wanted to cancel, not commit. I wasn't done >_<
Oh well doesn't matter.

Revision 5494

* new language: arabic
* update CS_CZ/es_ES/sv_SE/tr_TR/zh_CN
* refresh others translations

Revision 5495

cmake: Use non standard arch parameter on Fedora's wxconfig. Close issue 1368

Revision 5496

* add libaio new dependency
* update create_pcsx2_tarball_from_svn_repository script to support svn 1.7

Revision 5497

GSdx branch to support various openGL window API (wgl/glx/egl)
Do you intend to (if possible) remake GSdx into WinGS, a plugin that supports both DX and OGL?
GSdx will remain GSdx ;)
But yes, one goal is to be able to use OGL on MS too. It would be handy to debug OGL on linux.

Revision 5498

* split GSwnd into GSWndOGL and GSWndDX
* replace GSwnd static object by a dynamic pointer

Revision 5499

gsdx-ogl-wnd: update the MS build system. Not sure I got all verions.
Fun you're starting this :p
There's 2 files at least where MSVC2010 complains about a missing #include "StdAfx.h".
Do you have a Windows environment to test this?
Kinda. I got a VS2010 (free edition) on my girlfriends laptop.
I guess I will add this include on the new .h, I need to move a bad #ifdef _LINUX too by the way.
I have a smal Favor to Ask, is it Possible to implement a Savestate display in GsDx, like seen in ZeroGs?
Its like the Only thing i am missing, cause somehow all my Current Games Working Great!
Keep up the Good Work (^.^).
TMOD1: That would probably be in the actual emulator that happens as PCSX2 provides the window for GSDX to display in (ZeroGS has it's own, which Lilypad hacks in to for displaying the savestate), so it would actually be a core change for that.