PCSX2 Documentation/Google Code svn repository comments archive 1250 to 1499

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 1250

GSdx: dx9 hw mode got a vertex buffer too (as dx10), it was an old TODO...
DX10 mode yet again faster :p
well, dx10 mode should not have changed with this commit :P
Yeah, I'm beginning to question the accuracy of gsreplay :p
But I did check this with xenosaga1 and the very slow scene it has in the beginning (you fixed a bit of that once).
That one gets to 49fps now, and it was at 43 before (also a huge increase from the previous 35 ;) )
ah, that might be the fix for GSVector4i::ruinion, it did not return the correct result if one of the rects was empty, as UnionRect did with the old CRect class from mfc.
Ok, so this whole speedup thing is all just because of getting rid of the mfc..
Wow :p
nah, runion just did not calculate the union of a rect and an empty rect right as it did previously with mfc, ending up fetching more texture data, but now it's back to normal again.
Grandia 3 got a nice boost on the begining it lowered to like 20fps now it doesn't go below 50fps, but other part still get 30fps but still very nice, XenoSaga I got extra 10fps at the slow part in the begining of the game, before was 22fps now is 32fps, its fluid enough to see it without getting boring.
there one problem i noticed, in 1228 and 1250 the F keys doesn't seem to be working tryed to changed interlacing and it didn't work, 1194 still works.

Revision 1251

ZeroGS: Strictly in the interests of maintainability, I'm moving these functions
to a separate file.
Windows Build's compiler was broken... Gsnull broken too...
By the way.zeropad's Windows version's config diglog is broken.If you press any key.pcsx2 will crash.
Right, I suppose I chould change the Visual C++ project. And I'll take a look at GSnull.
As far as Windows Zeropad, it hasn't worked properly for me since 0.9.5. I've thought about fixing it, but the main problem is that I'm using Visual C++ Express when on the Windows side, which doesn't allow you to edit forms.
And I'd really need to redesign the form...

Revision 1252

Some quick fixes.
You noticed the missing semi-colon I see. I found it too earlier today but I've been to busy on IOP stuff and HDD spring cleaning.. >_<
Yeah, it broke GSNull on Windows, so thought I'd better take care of it...
I was trying to figure out which file and functions to de-optimise for gcc 4.4. Got a bit further if I do it to VU0 & VU1 related files, but no luck so far.
Then I switched to, err, "testing" Phantasy Star Universe with microVU. Plays pretty well.
I've been trying to fix some things up with zeropad on the Linux side, too. Irritating thing about that is people keep reporting the Windows issues, and that code is practically a separate plugin. I should probably either fix up the Window port, depreciate it, or just fork Zeropad...
Of course, fixing up the Windows ports is tough, since Visual C++ Express doesn't do forms...
To arcum42:You can use Resource Builder to edit forms:http://www.resource-builder.com/mt/mt/mv.pl?distr=19
(Finishes rescuing some thugs)
Resource Builder? Sounds useful. I'll take a look when I get a chance...

Revision 1253

* Finished up the bulk of register mapping logic.
* Cleaned up the Diagnostic system.
* Fixed some branch-handling cases in the IR / First-pass interpreter.

Revision 1254

- Implemented an idea by Jake to use a GPR as a reg-offset index to save a few
bytes from reg-moves (only did it for VI regs, didn't have enough free GPR's to
do it for VF regs)
- Fixed a minor problem with micro-program logs
OKAMI now has missing geometry like on ZeroRec

Revision 1255

R3000air: Couple minor cleanups and bugfixes.

Revision 1256

Zeropad: Yes it's a bunch *more* cleanup work on Zeropad.
And I know the Windows version is really flaky, and probably doesn't even register keys in the config screen. It was before this commit, and before the Playground team merged with the pcsx2 team, even.
If I get a chance, I'll see what I can do about it.
make: *** No rule to make target `Linux/joystick.cpp', needed by `libZeroPAD_a-joystick.o'. Stop.
Delete the zeropad folder and redownload it from svn. Old dep files from previous versions are causing automake to look for a file in the wrong place.
thx it helps. I wonder is there any other more correct way to checkout&compile pcsx2 then
svn up && svn up plugins/zzogl/ && sh build.sh clean && sh build.sh all
as svn up cause this mess..
to fix zeropad.
rm -r zeropad
svn up zeropad
A zeropad
A zeropad/Linux
A zeropad/Linux/zeropad.glade
A zeropad/Linux/linux.cpp
A zeropad/Linux/callbacks.c
A zeropad/Linux/interface.c
A zeropad/Linux/support.h
A zeropad/Linux/callbacks.h
A zeropad/Linux/gui.cpp
A zeropad/Linux/linux.h
A zeropad/Linux/interface.h
A zeropad/Linux/support.c
A zeropad/mkinstalldirs
A zeropad/joystick.cpp
A zeropad/analog.cpp
A zeropad/configure.ac
A zeropad/zeropad.cpp
A zeropad/joystick.h
A zeropad/depcomp
A zeropad/analog.h
A zeropad/build.sh
A zeropad/Makefile.am
A zeropad/Windows
A zeropad/Windows/ZeroPAD_2008.vcproj
A zeropad/Windows/ZeroPAD.def
A zeropad/Windows/ProjectRootDir.vsprops
A zeropad/Windows/ZeroPAD.rc
A zeropad/Windows/resource.h
A zeropad/Windows/win.cpp
A zeropad/zeropad.h
A zeropad/bitwise.h
Updated to revision 1276.
No, that's normally fine. The the clean isn't even usually neccessary. sh build.sh depclean might have resolved this, but I'm not sure.
I don't end up moving files often, though, so this rarely happens...

Revision 1257

Path3 Masking mystery solved, Simpsons ( Issue 24 ) GT4 ( Issue 211 ), tenchu and
many many other path3 masking games should be fixed. This will only work on
Also semi-removed my gifsplit thing to resolve the tekken 5 menus Issue 209
Note: GT4 is still missing its logo, this is down to a really bizzare timing
issue i cant pinpoint.
Removed redundant path3hack
Oh and soul calibur 3 still doesnt show anything, it is there however, if you're brave you can blindly get through the first screens
Awesome, Ref!
It fixed Suikoden5 and Persona4 path3 problems completely :D
Amazing, even an old issue is fixed
GT4 has logo bug, and Simpsons has lines bugs around some textures corners but anyway it's much much greater than before, thanks Ref
Damn had thought the GT4 start game crash had finally been fixed for a sec there, then read the description *sobs*. Yes I know its a gsdx issue :p.
easily solved with software mode :p
Tenchu is perfect! It was broken for years! Thanx ref :)
SW Episode 3 Path3 fixed game has little VU SPS bugs but textures are right
Puzzle Quest is fixed.
Hi Refraction. There is a good job, still missing logo, but i believe you gona fix it. Another question, when we see the replay in "DIVE REPLAY" and fail a license the screen is garbed, is PCSX2 problem or GSDX?
Thanks and keep the good work.
not sure, for example one of the loading screens on my GT4 is garbled, but its is remenants of a bug which appeared aaaaages ago (inside pcsx2 i think), however i dont know where or when, so locating it is going to be near on impossible.
Great job Ref!!!
This is Awesome!
Found out something changin from Rev 1225 to 1265.
If youre playing Shin Megami Tensai : Nocturne you MUST deaktivate "IOP x2 Cycle Rate" or the game will freeze up during stage Changes. Anyway, this is ok, "IOP x2 Cycle Rate" gives no speedup in Shin Megami Tensai Nocturne. - Just a hint for thoose r playing this game.
Keep up the good work!
Unfortunately, this revision completely stops Timesplitters 2 from running. Meaning, you start the iso, the window pops up, but it isn't even filled with black, it's completely transparent (if you get what I'm saying).
I'm gonna try testing a few more things later on, but Timesplitters 2 does work in build r1256 with my current settings (no speedhacks, native res, I even tried turning off all of the recompiler stuff).
It still doesn't work as of r1277. I might start up a bug report thingy when I've got a bit of time. Cool revision otherwise though.
This revision is causing huge slowdown in "Maximo". Now its unplayable.

Revision 1258

R3000air: Added fairly decent support and documentation for the 'mystery'
register located at 0xfffe0130 in IOP memory (it's the Bus Interface Unit (BIU)
/ Cache controller), with the help of Mizvekov. Starting work on IOPrec block
dumping & logging to assist in troubleshooting the recompiler.
I'm always in favor of decent documentation...

Revision 1259

Altered time between GIF resume checks, 2 cycles was a bit ambitious, 16 cycles
(8 qw's transferred) is much more realistic and doesnt slow games down as much.

Revision 1260

Fixed GIF MFIFO for Front Mission 4
playing front mission 5 now.with all speedhacks on the opening movie is flickering but when i press escape and continue, it became perfect(no flickering at all) but i guess it has no relation with this commit. just for info.
I just love front mission so much.

Revision 1261

Temp fix for Soul Calibur 3 so i can close Issue 233 .
Other small fixes
man plz naruto chronicals laoding problem and half render screen in digimon rumble arena 2 and jacky chan
keep asking and ill never touch it..
why man i am so devoted to the project i chack it every 3 hours to see the changes i am trying also to leearn coding to join you
Then you learn to fix it :p i have enough on my plate..
The more I see these gif/dma 'fixes', the more it appears like black magic. Is any of this proper emulation on the whole or just specific case workarounds?
the small fixes are proper fixes to the emulation, the temp fix for soul calibur is replacement of the old code for some cases, which technically is a hack.

Revision 1262

Guess im just a jackass, do do do, oh *ahem*... This fixes Jackass :P
You're on a roll today it seems. :p
just fixing up the bits i left behind
Ref, you're unstopable today :P

Revision 1263

Another µVU typo, fixes silent hill 2 but probably not nothing else.
Heh, and it ONLY fixed GOW 2 (probably 1 too) almost 100%! The games graphics are almost perfect now, but for some minor glitches (e.x. missing fires when in the loading game scene). Having enabled both flag hacks (so not sure which one is to blame) causes alot of infinite loops+slowdowns + missing menus, but still the graphics are perfect 98%.
wow sudonim u rocks u have one comment every lots of days but it make mothes of diffrance thanx man
What in Silent Hill 2 does this fix specifically out of curiosity? I`ve not played the game in pcsx2 in ages, but the game had very slight sps and small flickering textures in occassional parts of the game. Nothing ultra major, just litttle glitches here and there.
If those have been fixed, very nice work :).
wow this was strong GoW1&2 is fixed and the lights on Kratos's Swords not above them, they have right position now
But it breaks OKAMI geometry so now it's like on ZeroRecs
Oh sorry this was broken in r1254
Fixes GoW indeed but the speed impact is 50%, for me at least. I am on a [email protected], GeForce 9800GTX, 4GB of DDR3.

Revision 1264

Added VIF wait to MFIFO, fixes Crash of the Titans graphics
I was so glad to your previous commits so i dont even starting issue knowing this bug. Thanks ref you're wondered once again
I'm getting Unknown VifCmd:21 and crash with dividing by zero in the first cutscene.
wow dude you rocks
I don't know which revision made this, but the menus of Test Drive: Eve of destruction
has the menus with lots of garbage. The last time that I tried was with r1250 and the menus were fine.
Then submit an issue and upload a blockdump somewhere :P (not here! we dont have a lot of room)
well.. I've already made Issue 33 for the same game (but another problem)
and has a blockdump there(4shared). But if want I make another Issue to
report this new problem.

Revision 1265

- Properly fixed problems from r1254, a lot of games should be fixed.
- Added some debug code that runs sVU and mVU, and compares their results. If
they differ, then the game is halted, and debug info is given. (this can be
enabled in iVU1micro.cpp with the DEBUG_COMPARE2 macro)... the code is a bit
messy, but it gets the job done for now.

Revision 1266

GSdx: bit more work on the vertex buffer, and broken ffxii fmv fixed again.
I don't no why, but latest gsdx revisions are a bit slower for me (Xenosaga I, FFXII) in both DX10 and DX9.
rev 1076 is still faster for this games...
It's hard to test ffxii for speed, it uses less than 99% cpu in gsdx.
And I think I lost my xeno1 disk again... when I need hdd space that's one of the first thing to delete lol.
hi gabesst , there is still the problem with the ffx-2 fmv as explained in the r1236
It seems to correct partially the fmv from FFXII but still some problems.

Revision 1267

* Improved several branching and exception handling logics, relating to block
splitting and optimizations of blocks/loops.
* Fixed several bugs in the register mapping / allocation system.
* Redid the strict register mapping mode's api (again ... >_<)
* Improved the interpreter's handling of AddressError and Overflow exceptions.

Revision 1268

mVU: Fix for a bug that would cause stall cycles to be counted 2 times.

Revision 1269

Bugfix for Issue 241 . Also increased the EErec's stack memory from 64k to 128k,
since there's no reason to be frugal there anymore.
Yup it's fixed, thanks

Revision 1270

- Fixed a big bug with the help of sudonim and rama which greatly increases
mVU's compatibility!
Thought i would let you know with microVU enabled Ratchet and Clank 2 & 3 refuse to work, both start but when the ships flying to the planet you get a constant 'Exiting from possible infinite loop' error and after you've landed the screen goes black sounds plays for about 5 seconds then the game just freezes and you have to press escape to exit.
sorry for second post but i just noticed that the ship suffers from slight sps hope this helps you in some way
thanks for reporting, i'll keep those games in mind.
there is a small possibility they're fixed in my latest update though (i haven't tested the games so i'm not sure...)
Persona 3 & 4 games are now perfect.
Great you found the issue (and that it was a small thing :p ).
Great!.. This (or the next, maybe) release fixed missing geometry in Okami...
Strange thing with clamping modes... I have almost no geometry in Okami with Full Clamping Mode, just some random sprites... None and Normal Modes are fine...
Crash Mind Over Mutant looks exactly as with zerorec... I mean without any textures, but it's GSDX problem, I think...

Revision 1271

- Increased mVU run cycles (Fixes Kloana 2's Inf Loop messages)
- Fixed some potential problems with the log code that would cause some games to
- Minor Changes...

Revision 1272

GSdx: Even more alpha test voodoo magic, it must be nailed now!
And there is even an explanation.
The tfx functions calculate At * Af >> 7, which means modulating by 0x80 should
return At as the result.
With the evil floating point pixel shader however 0x80 translates to 128/255
(0.502), not exactly 0.5, modulation as At' * Af' * 2 (' means 0 - 1.0 range) is
not the same as with integers.
At' = Af' = 0.502
At' * Af' * 2 = 0.504
If the alpha test happens to be "not equal to 0x80", then abs(0.504 - 128/255) <
0.5/255 will just miss.
Solution is to re-scale those values to the integer range, do the calculations,
and then back to float again, but in the end it just simplifies down to At' *
Af' * 255/128, doh...
At * Af >> 7 => ((At' * 255) * (Af' * 255) / 128) / 255 => At' * Af' * 255/128
At' = Af' = 0.502
0.502 * 0.502 * 255/128 = 0.502 (w00t!)
I think now it would be safe to remove those FIXMEs and change 0.4/0.6 to 0.5, probably...
voodoo magic is always good :D
Voodoo magic ftw!
Nice to see this thing fixed finally... I don't know if it really fixes anything significant, but anyway...
Isn't the problem with Squall's hair in FFX related to alpha blending or alpha testing too?..
Ah, no... Squall's hair and other glitches in FFX is a bug in VU1 recompiler (both zero's and cottonvibes')... VU1 interpreter is fine (but slow)...
squall? like from FF VII ..... in FF X ??? dude that IS some voodoo magic
I feel like the shaman of monkey island is right next to me and is holding a rubber chicken!!????!
thanks gabest for the explanation
Oups, sorry... :D I mean Tidus, ofcourse... :) The bug is there anyway...
Yeah, I'd like to play FFX as Squall, really... :D Cutting everyone around with a big sword...
The FFX issue is a VU problem (i think) if you look at tidus's hair as you go around the campfile, he has a triangle seemingly cut out of his hair, but if you look closely, it's there, just flipped vertically. so there is a calculation problem somewhere, most likely making it a negative value when it should be positive, not totally sure. One day ill trace back to when the bug appeared (i know it was between 0.8.2 and 0.9.0 but not sure when) so ill have a look through sourceforge
campfile? i meant campfire. Damn you google for not implementing an edit button
I feel your pain on that one. I've wished for an edit button any number of times.
And, given a choice, I'd prefer to play FFX as Guybrush Threepwood. :)
Tidus is cooler than Guybrush... Tidus can hold his breath under water indefinetly long while Guybrush - only for 10 minutes... ;)
This build crashes metal gear solid 3 @ the intro (where snake starts falling from the sky). The last gsdx build I tried, 1228, doesnt have this problem. Also Odin Sphere is quite slower than in 1228, 10-15fps at the intro (gsdx usage is 99% in both builds, but still at 1228 I get 35fps while with this 22fps).
I'll check them... but it's almost certain that not this revision caused these problems, it'd have saved me a lot of testing if you have already found and told me the exact revision number :P They are all downloadable.
Ok gabest, i'll compile the inbetween builds later today and tell you what caused it.
Strangely when I compiled this build it defaulted to 1300x1300 d3d internal res, which I didnt change (even though I never used these values before). This causes the crash with all latest builds for some reason. Changing these values to something normal like 1024x1024 remedies the prob.
I thought you already knew, but here are the updates:
Thanks for the link. Regarding MGS3, further investigation shows that it crashes at this point with any resolution above 1024x1024 (!). I Tried all my builds as back as build 896, and they all crash the emu. My gpu is a very powerfull dx10 one, so I doubt this is to blame.
Regarding Odin Sphere, here is a gs dump http://www.megaupload.com/?d=61B6HN8Z , it was severely slowed down at build 1250 (around 10fps slowdown),where until 1239 it was faster - but still quite slow for a 2d game (my guess is it wont be too hard to optimise it, and remedy the 99% cpu usage).

Revision 1273

microVU is now selectable as a GUI option from the CPU dialog box.
microVU speedhacks are also available in the speedhacks dialog.
All the GUI stuff took me a few hours, so hopefully I didn't bug anything.
Note to users:
Please remember that microVU is a W.I.P. and will have bugs; but it also fixes
some games Super VU has problems with. So have fun testing.
Also I recommend to set VU clamping to 'none' for now, if running microVU...
And of-course the GUI changes were only for the windows port, linux changes need to be implemented xD.
WOW!!! WOW!!! WOW!!! Finally!!! Now we don't have to compile several different executables to test microVU with it's speedhacks...
Thank you very very very much, cottonvibes!!!
at this stage, microvu ( for sure is fun to test ) is any better than standard vu unit?
if yes in which area?
After a brief test with my not-so-numerous games I can say that two VU recompilers are very similar at this very moment...
Even that bug in VU1 recompiler which causes alpha blending glitches in Final Fantasy X is exactly the same as in superVU... :-)
THAT IS THE DAY!!!! Thanks Cotton! (Wish I could give you 100 positive scores :D)
Katmari Damacy - sps fixed on mVU
GoW1, 2 - lights are in right position
Soul Calibur 3 - hair bug fixed
GT4 - letters are fine even if clamp mode set to "none"
GREAT DAY!!!! 'nuff said XD
alright let the testing (and comparing) begin!!!!
quick question: are the speedhacks compatible or should we generally refrain from using hacks which target the VU ? (when in µVU mode)
kabooz: old speedhacks are compatible with mVU, as well as saved states.
but if you have problems, of-course disable all speedhacks and try again ;p
ToA appears to be working almost perfectly in microVU. Looking good now.
All right, I'll reboot and implement.
I was trying to finagle the Windows Zeropad code into working so I'd get left alone when I update the Linux code.
Finding that the code to pull what key was pressed in the configuration dialog is *commented out* isn't a good start. :(
Alright, played around in ToA a little more with microVU / no speedhacks. SPS = gone; still some disappearing geometry (i.e. when a character approaches a town on the world map), and some missing sprite effects (snow).
Missing geometry in ToA seems to be triggered when enabling microVU1. Hope that helps.
to andrea.b... And to all interested...
Okami is better with MicroVU (but slower)... SuperVU often has some missing poligons at far distance... MicroVU is fine with it...
ftp://pcsx2:[email protected]/okami_mvu.jpg
cottonvibes, can you take a look at that old bug in VU1rec that makes FFX alpha blending fail?..
eliotfur: what makes you say its an alpha blending issue? just cos gabest has done some work on alpha blending, it doesnt mean every bug is suddenly due to that everywhere else.. You are however wrong in this case as polygons are out of position, otheres are completely missing and other things have incorrect textures associated with them, which to my recollection, isnt alpha blending
Well, let's say it's "calculation problem"...
Anyway, if we take a polygon with alpha layer (transparency) and place some other polygon with transparancy behind it, we could see through second polygon where first polygon is transparent... Weird... Well, forgetit, I noticed that I'm wrong already...
I just hoped to see MicroVU handling this game a bit better than SuperVU...
thanks, and keep up the good work.
Jak3 missing geometry fixed with microVU
I feared, it will take years to get it to "officially available" state. Even in SVN.
BTW, there is more than 1k warnings "controlling expression is constant" with ICL in microVU_Upper.inl, microVU_Lower.inl and microVU_Analyze.inl. Just a flood. ;P
Both flag hacks are hanging games before going 3D
Intel C++ Compiler is evil thing... Sometimes it's too verbose... Maybe there's a way to turn off this warning...
Nice update congrats mate, finally the microVU options are in the gui, i tried Ratchet and Clank 2 & 3 with this new build and the 'infinite loop' error has gone but now within about 3 secs of the ship showing on the screen and flying to the planet it crashes the whole emulator also the screen seems to flash large random white and black triangles just before the emulator crashes.
Don't know if this is the right place to talk about Flag Hacks but, well, it might help you some way:
Flag Hack 1 makes character and E.S models to dissapear at Xenosaga III, rest of the screen is showing correctly.
Sorry if this is not meant to be post here.
that warning is some stupid ICC warning saying its going to optimize something.
i purposely coded stuff so they'll be optimized. like for example:
pass1 {}
that really does:
if (recPass==0) {}
and recPass is a template param which is constant, so it obviously should be optimized.
ICC is just being annoying xD
yeah the flaghack1 speedhack seems to hurt some games.
i won't be trying to fix hacks, but i don't mind people talking about what they break (it helps to know what games are doing).
MegaThanks Cotton !!! =) Can you tell default settings or make a default button ?:)
Default settings are everything checked except for the microVU checkboxes :p
Tlb miss error in Naruto 4 is now fixed with mVU. Thanks Cotton!

Revision 1274

Minor changes.

Revision 1275

Linux: Hack microVU into the Gui.
Incidentally, the ZeroPad change is just reformatting; no code changed.
Notes: I had to meddle with where iVUzerorec was allocing VU0 because it wasn't allocating properly otherwise in Linux.
Also, having checkmarks for VU0 and VU1 on both superVU and microVU doesn't seem intuitive, especially since the microVU checkmarks are ignored in you uncheck the superVU checkmarks.
Radio buttons to choose either SuperVU or MicroVU, and then checkmarks to enable VU0 and VU1 might work better...
And a few other defines I was messing with crept into Pcsx2Defs.h, btw.
Arcum, use instead means that both VUrecs and microVUrecs should be enabled?
Normal mode would be both VU0 and VU1 checked, and neither microVU.
MicroVU mode is all 4 checked.
Anything else is likely to have issues.

Revision 1276

mVU: Disabled breaking execution on bad programs since it's not needed anymore
and costs speed.
This slows microVU down much
and makes VU stealing hack is quite useless when i get with Slight and Moderate and even Huge almost the same resoult in GoW and all games
Ah yeah, i suppose that can happen.
So your first comment was very likely bogus.
You had that hack enabled and now it didn't speed up your game, eh :p
If you tried to turn off the hacks once, you'd see that its faster now.
Anyway, this here will soon be changed back somewhat, so the hack should also work again.
Yea i tried without hacks, and i must admit that default is really faster on it's own, very ince but need a revert:)
good work pcsx2 devs, i have a question, if i want to use microVU, i must leave the VUrecs enabled too?, 'cause i tried to lunch the emu with the recs disabled and didnt work, but with the recs enabled, all runs fine, but i dont know what recs im using, thanks and good work
leave the VU rec checkmarks ON, and then check mVU checkboxes.
basically every checkbox in the CPU dialog should be checked xD
well i test mVU with SoTC, and its about 15 fps slower than sVU, but stutters less, is more smooth (i notice this when the game runs at full speed in both cases) maybe is the vu cycle stealing hack in the case of sVU that makes it stutters a little more , in persona 3 fes, runs about the same without problems
Yes this revision basically disabled the Cycle Stealing hack for mVU. So comparing sVU with mVU with any cycle stealing hack enabled is not fair, nor will it yield consistent visual results.
Maybe have the cycle stealing hack disapear entirely then when microVU is selected?

Revision 1277

Linux: Revise the speed hack and cpu dialogs a bit.
arcum42 always uses strange grammar... His changelogs sound like he is asking us to do something with the code: "Please, revise cpu dialog a bit", not "I have revised cpu dialog a bit and feel great about it"... :-)
BTW, does mVU really works in Linux?..
It's called present tence, and being succinct.
And I am typing these commit messages at a command prompt, not into a dialog box, so I usually don't feel like being that verbose about it. I'm not that likely to type:
svn ci --message "I have revised the cpu dialog a bit and feel great about it"
especially since the last should be implied.
And, yes, microVU works in Linux. It has for a while with the defines, and
now it has checkboxes to back it up.

Revision 1278

microVU: minor optimizations/changes...
Note to Hack-lovers! This modification should re-enable VU Cycle Stealing functionality.

Revision 1279

GSdx: just fixing slow texture uploads with dx9... (odin sphere back to 40-50
Odin Sphere still slow, same speed as 1272. (using dx10 hardware)
it isn't that bad here, 50-55 fps in the tutorial, but dx9 got the fps halved recently, that is restored now.
tbh I was skipping the intro (which was usually fast) and loading a problematic point where there was a significant speed decrease. Here are 2 savestates that will help you see the prob (if you have the same version of the game!)
The intro's pretty fast (the most taxing parts are when there's a fade to the character name) but right at the end when all of the pink sprites suddenly appear out of the butterfly there's a brief but large performance hit; seems like there's slowdown due to loading those sprites.
2nd cutscene in the Valkyrie (first campaign) has always been slow in GSDx for some reason.
It's strange, as the gameplay itself was quite smooth during the little of it I tested.

Revision 1280

* Lots more work on the register mapping / allocation logic -- recompiler can
actually generate a few dozen instructions now! (and then promptly crashes so
don't bother trying to compile/run it)
* Removed the BlockValidation cache, since IOP block invalidation can be
managed entirely through the RamProtection bit on the COP0 status register.
* Fixed some bugs in the disasm parameter ordering.
* Added some comparison operators (== and !=) to some of the x86emitter types.
hi do you plan to integrate it in the trunk with some choosing option as for microvu ?
when Jake's done with his IOP rec, we're just going to set it as default on the main trunk.
its incompatible with the current IOP rec, so it won't work-well having it selectable as an option.
and the purpose of this is just to have an easier way to detect bugs or is there an impact on performances ?
i heard jake said once it would make games faster with 4-7% i think it's good for high graphic games like gow but i think it will be more useful if it help to detect errors cause you need to make the programe more comilatable than making it fater right now
Jake's IOP rec will most-likely be faster than the current one; but since the IOP isn't pcsx2's bottle-neck even if Jake's rec is twice as fast, it'll probably only be around a ~5% speedup in most games.
The main advantages of a new IOP rec is more compatibility, cleaner code, and a nice practice/guide for a possible new EE rec.
Additionally it gets us 1-step closer to getting rid of some ugly global-regalloc system all pcsx2's recs are currently using. We're eagerly awaiting the day we can totally delete that thing xD

Revision 1281

- Implemented the tri-ace gamefix.
Note: I've only tested SO3 so-far and it has some ugly graphical problems with
mVU. SO3 does some evil VU stuff that it shouldn't be doing, but it does them
anyways xD
I know the cause of the problems, so I just have to code the solutions sometime
in the future...
P.S. SO3 looks really funny with the FlagHack1 speedhack! The characters turn
into floating heads effectively turning the game into PacMan xD
lol PacMan.

Revision 1282

- Added a 1-cycle xgkick delay, fixes SO3 graphic corruption and flickering.
Theres still VU stuff the game does that isn't implemented, but the game seems
to run fine w/o the implementation (only tested the beginning though).
General stuff works, but in battles the missing code causes all kinds of bad stuff :p

Revision 1283

- Small Optimization...

Revision 1284

- fixed a bug from r1281 when the tri-ace gamefix is unchecked xD

Revision 1285

GSdx: there was a bug in unaligned 4/8 bit transfer, small texture glitches may
be fixed (simpson game, car logos in gt4).
Thanks Gabest, can you also add this
{0x4C94B32C, SimpsonsGame, Unknown},
Doesn`t fix the dx9 starting race crash in GT4 sadly. But nice to see the cars looking better.
Autor: Why would he want to add that?
i retract my comment
Hey Gabest...works fine. Thanks.
I really like the work you guys do; however, I just noticed an odd bug that seems to have appeared with revision 1236. I've seen it with both Star Ocean 3 and Grandia 3. I recreate by repeatedly hitting escape, then run->execute, and after about 5 times pcsx2 crashes. If you want more information about it feel free to ask. Regards
refraction: Cause it's CRC for another version, it works i already checked it out
Autor: I know, i realised that after i wrote my comment.. lol
this revision fixed the white dot issue for fatal frame finaly. :P
Good Job, Gabest.
BTW, Gabest, SW The Force Unleashed has the same problem which Simpsons Game had, half of the screen is covered with map's sky texture
here's the GSdump http://rapidshare.com/files/238516824/SWtFU.rar.html
please take a look
Oh, nice to hear about the white dot being fixed :)

Revision 1286

Zeropad: A bunch of refactoring and cleanup. The Windows port probably won't
compile right now.
A lot of what I'm doing is bringing things out of the linux folder where windows will be able to get at it, and getting the windows port to the point where it'll be easier to fix, because I would like this plugin to at least work on both platforms.
And, of course, taking notes on what needs to be fixed.

Revision 1287

- Changed 'recPass' from a template param to a function param. Halves MSVC
linking-time in release modes, but still slow (from ~10 minutes to ~5 minutes to
link on my PC). I'll continue working on this later... the next change will
probably reduce Release link-times to 1~2 minutes (or less than 1 minute for you
guys with macho-pc's ;p).
thanks for giving it a -1 w/o listing your problem ferrain; now please tell me how am i supposed to fix the problem or know whats wrong?
the review score is for reviews, not for people like you to just randomly vote +1/-1 on commits without giving reasons.
this is why other projects limit comments to only project-members.
now some people here actually are helpful in comments, so it'll be annoying when a few people leaving unhelpful comments (or negative score without listing their problem) ruin good things for other people.
Hi Cottonvibes, every time i do a comment as delete, people don´t care of me. I tell you, the game crashs, and when we live a race and gona choose another circuit, the menu are unconfigured, whit a lot of colors. In race buildings, eg, the windows change colors. (GT4). Sorry my english.
Will you STOP posting here about this game already?
It's seriously disturbing!
Yes WE KNOW GT4 HAS PROBLEMS. You don't need to post about GT4 in EVERY COMMENT you make.
If someone manages to fix it,good,if not WAIT until someone does. I can't see why everyone should focus on GT4 just because you're obsessed with it and not with any other game out there.
So instead of nagging the devs about that single game every single time you make a comment, try being more helpful by creating some good bug reports or by reporting bugs some new revision has made.
Not sure when this showed up, but Kingdom Hearts 2 is freezing up. Originally thought it was GSdx, but in trying a bunch of different modes and versions of it, it still froze. Speedhacks/mVU on/off makes no difference. The latest stable version of Pcsx2 still works, but the newest svn version doesn't. Only freeze spot is in Twilight Town whenever a sunset appears in the background.
In other news, love mVU, keep up the good work on this, guys.
yeah its a vif problem, i already told ref about it. so hopefully he can fix it ;p
justice league heroes NTSC
goes a bit ingame and shows massive possible infi loops messages
the game didn't go ingame on zero recs so it's a great improvement^^
also wild arms 3 works almost as fast on µVU now (+ plus it looks better less vertical stripes in text still not gone though)
I hope you'll improve µVU further so that we can use it as default ^^
carry on now cYa
Front mission 5 still fine with Mvu but zero has more less (tiny) speed but that's fine.
as a note:
i give 1+ because i support the proggress.(especially what arcum did to 'port it into linux and the attemp to 'fix' for some plugin like zeropad to be more compatible)
so,ferrarin, there are still many games you can try.
hope i didn't spam here.if i do....just delete this post.
(i rarely give comment, just if it only necessary)
hope that's fine ^_^
if you +1 a revision its fine to not leave a comment because its understood that you support the change.
but anyone that puts -1 should leave a comment explaining why they don't like the revision and what problems they had with the revision.

Revision 1288

Zeropad: Windows is back to compiling, though the config dialog is still broken.
Incidentally, if anyone feels like hacking the configuration dialog box in Windows to work in Zeropad, send me a patch, and I'll be happy to commit it. I *hate* working with Windows APIs...
Windows APIs are not a pleaseure to program, but what about GTK? That's like the worst nightmare for a sane programmer.
Yeah, it's a pain, too. I'm a lot more familiar with it, though. And glade and libglade helps a lot.
Partially it comes down to what you're familiar with, and I haven't spent nearly as much time with Windows Apis as with Gtk+ (I'm a member of a project that entirely C based. No C++ at all. Limits the choice of apis a bit...). That and Visual C++ Express may not be the best way to go.
I'm tempted to just port the plugin to wxWidgets, but if I do that, I'll find myself rewriting the joystick code in wxWidgets as well, and pretty soon I may as well have written a new plugin...
I understand you, programming habits are hard to change.
Well, sooner or later you'll switch the whole thing to wxWidgets... that's pretty good (I prefer QT because it's a little less "raw" but still).
Have you guys ever considered Qt? It's the best framework I've worked with so far, and also has by far the best documentation I've seen anywhere. If you guys ever decide to switch to it, I could help you with it.
See the branches, there's a branch for wxWidget. Qt4 is a good ideal, but since we're using wxWidget.

Revision 1289

Couple of fixes, one for Kingdom Hearts 2 Issue 239 , others might help textures
in the GT games (maybe!)
Also prepared some code to add support for VU looping in MTGS mode, this will
require a GS Spec update, so its commented out for now until i can sync an
update with Gabest.
hurray for KHII fix :D
i'll test when i get home ;p
Oh and this also allows you to use MTGS mode in VUint xD
Annnd i just noticed it was broken lol, fixed in r1290
KH2, GT4, and streange lines *like was in tekken5* on some textures in Simpsons Game are fixed, thanks Ref
im pondering the strange line issue was actually from gsdx, however i fixed the strange line syndrome a while back :P
SSX 3 not playable (ingame problems - black screen)
because of these changes...
Tested up to (including) r1299 and still the same.

Revision 1290

From 1289 you can use MTGS mode in VUint, but the new code was enabled :P now
disabled it so MTGS will work
Thought initially that MTGS crash was caused by GSdx plugin, but it's not.
The game now works great with mVU enabled. However, running it without
mVU, I got a 'flood' of messanges saying that 'VU0 perma-stall, breaking
executation...', though the game still runs fine (not sure 'cause I've
just tested it for a while:p).
I think you might be confusing "mtgs" with "metal gear solid"?
MTGS stands for "multi-threaded GS", which is the checkbox in pcsx2 that lets the Graphics-Synthesizer(GS) run in its own thread.
Oh, that was a shame xD. Thanks for the correction, cotton :]
Hi, refraction
this revision breaks fatal frame again.
dma trans error and crash.......
it won't be this revision, can you please check back properly thx. however it works fine for me
1288 is ok.
setting: eecycle is default, advance is default.
Then its likely to be r1289. There isnt a chance in hell this could break it unless you play the game with the recompilers off (i doubt it) and MTGS mode on, even then you would need an obscure situation to cause dma errors
recompilers is on.
if MTGS off, can't enter game, black screen.
log message:
sceGsSyncPath: GIF does not terminate
are you using microvu or supervu (original recs)?
nvm i knoq what was going on, fixed in my next rev

Revision 1291

- It took a while, but I managed to convert 100's of template functions to
normal functions, reducing release link times by about ~50% again.
pcsx2 takes about ~2 mins to link on release build, which is a lot more
tolerable than ~10 minutes from a few days ago...
using template slow down the compiler...but I don't know it slow that MUCH :(
Nice commit i admited that mVU compiles longer than ZeroRec, when it was seperated, it's faster now, thanks cotton but i also want to say that after r1282 geometry in GT4 is totaly disappeared, there is no 3d objects in Gran Turismo Mod menu or cars anymore
This will be a massive time saving for the compilation process on such 'crap' computers :]
Hmm okay, i'll see what the game is doing. Hopefully i can find a nice solution to get both that game and SO3 running.
Currently its not possible to accurately emulate xgkick due to many factors (we'd need a threaded dmac that correctly handles DMA transfers and priorities; and even then it'd be hard to accurately emulate this instruction on a vu rec.); so i'm hoping i can find some 'fake' way to emulate it to make the games happy.
okay i think i found the problem Autor, its not as bad as i feared.
its mainly a glitch in my code not accounting for a certain case (nothing to do with xgkick delay timings as i feared).
i'll fix it on my next commit.

Revision 1292

- Fixed a bug with my xgkick delay code from r1282. Fixes GT4.
Thanks to Cottonvibes, Refraction, Arcum42, Jake.Stine, Gabest11, Ramapcsx2, and all the team, for the wonderful work. GT4 is fine, the only thing i can configure is, the circuit George V Paris, it is very slow. Thanks to all.
fatal frame occurs "infinite loop"
Now's fixed, thanks Cotton
No infinite loop here in fatal frame 1, check if you have a hack enabled that is causing this. Still I get numerous dma errors at some point, but dont have the time now to check if its really a new bug, or mvu related.
yes, if disable "flag hack 1", no infinite loop
Great, you guys should stop reporting "problems" when you have hacks on.
It's not like you don't know that. We've been preaching it for months..
I still Love GT4, but i'm gona try play FFXII, that a colleague of my son borrowed. Thanks to all.

Revision 1293

microVU/Linux: Since __mVUdumpProgram is of type microVUx, vuIndex is already
defined, and shouldn't be redefined. Fixes Linux compilation.

Revision 1294

Zeropad: Fixes a minor mistake in r1286.

Revision 1295

Fixing up Fatal Frame, removed redundant path3 masking code from the olden days!
Maximo - Ghost To Glory playable again
Ah nice Maximo`s playable again? good stuff.

Revision 1296

Various VifDma cleanups.
On second thought, I'm going to move the memory locations I added to VifDma.h to Hw.h. A few other places are using them, so it'll be cleaner. That's next revision, though.

Revision 1297

Assorted cleanup involving VifDma, the Hw files, IopMem and Fifo.

Revision 1298

- Gave the rec a better IR (intermediate representation) implementation.
- Renamed microVU_Alloc to microVU_IR
Shin Sangokumusou 4 (dynasty warrior 5) was broken more than r1297.
Could you clarify this, saku?
Was the game broken by r1297, or is it broken by this revision?
Basically, Terrain was broken in microVU(~1297). However, this revision also breaks up messagebox.
Ok, this is likely the same bug then. Just affects more stuff now.
there should be no functional changes in this revision.
so either that means the report is false, or i bugged something.
i think more games will be broken if i bugged something, so i'll wait for someone to mention a game i have so i can test and fix the problem.
and rama get on IRC! xD

Revision 1299

- Fixed a bug from r1254. (Fixes weird circles on the logo of ffxii after
selecting new-game)

Revision 1300

- Tried a complex optimization with status flag updating.
Didn't seem to work out as well as I thought.
I need some benchmarks of mVU (w/o hacks) before this update and after this
update to see how effective it is.
If its not much faster I might just revert the change (because I'm sure no-one
is going to understand how it works this way).
Shin sangokumusou 4(dynasty warrior 5) Text bug was fixed.
but FFXII Text was invisible.
FF12 has some issue.
speed no obvious change with 1299, still slower than svu about 10%
k thanks for the testing guys.
i didn't know i broke ffxii, so obviously i bugged something xD
i'm going to think about reverting, or maybe just modding this version to be easier.
The text loss in FFXII only happens in mVU1 if it helps.
Persona 4 save state load would also kill it (it'd load but at 1fps), something about "microVU Error: Program went over its cache limit" "microVU1: Cached MicroPrograms = 1"
And again disabling microVU1 got ride of this as well.
Cheers for 1300 svn :)

Revision 1301

- Backing up some changes before I revert...

Revision 1302

- reverted to r1299
GT4 Movie Intro crash..
thats not caused by mVU, thats caused by speedhacks.
i also had a version of gsdx that made that crash, but it might've been because i compiled the version myself with an old directX sdk version...
using Gabest's compiled builds fixed it for me.
I'm using PCSX r1302 and GSDX 1285 and crash, but i try with GSDX 1250 and still the same.
(EE) Tlb Miss, addr=0x24a0e60 [load]
(EE) PC: 0x00569c80 Cycle: 0x0c9c1328
Does it look like that? If so I'll have to confirm this. It was working once as well..
rama, I have something that looks just like that when I'm playing FFX and switch between windows (for example pcsx2 and firefox, or the desktop, or whatever) while pcsx2 is running. I'll make a ticket about it though, this ain't the place for it :-P

Revision 1303

- Non-functional change... just storing some IR info I'll need to use later.

Revision 1304

- Implemented some bizarre behavior where conditional branches will read old VI-
reg values if the previous instructions continuously read+write to the VI reg.
example from zerorec's comments:
SQI vi5++
SQI vi5++
IBNE vi4, vi5
vi5's value in the branch should be the value before all the SQI's...
more examples in iVUzerorec.cpp
Fixes Magna Carta, as expected.
Good to know finally what all these bugs really were ;)
oooh i like magna carta thanx man

Revision 1305

R3000air: Minor fixes and cleanups for the BIU register handler.
oooooooh man i missed you
jake you got groupies?

Revision 1306

Improved the cpu speed/ghz detection. It should be a bit more accurate, and is
faster (pcsx2 startup times are near instantaneous now).
Very cool, the half second it took to load the main window after the console before this revision always bothered me a little bit :P

Revision 1307

Quick cleanup of my prev commit -- changed some u32's to u64's, and deleted some
code made obsolete by the new cpu detection.

Revision 1308

- Minor Changes/Cleanup
Super VU:
- Used the Linux SysMmapEx address for windows as well.
Probably for the best. When I made that commit, I didn't realize it was failing on the first try at allocation for Windows as well...

Revision 1309

- Second try at a status flag optimization. Still needs tweaking but too tired
Here is a picture of what happens when the same site of the GT4 intro. I do not quite understand these codes, but I think you know :
And that occurs from this commit? If not that post is irrelevant.
avatar earth burning the graound is black but the charcters are still good
it got normal when i disable microvu
[email protected]
I had the same error before in GT4 when starting lincense race, set EE Clamp to Normal and error should be gone

Revision 1310

GSdx: mfc-free
Good job! Now we needn't use damn M$ Fried Chicken ;)
.. and dll got another 100k smaller
at dx10 hardware all options can ticked :P
yea, mfc had callbacks to update controls, it's gone, but I might reimplement it later.
plus, obviously not your priority (just reporting) odin sphere is still slowww (at the slow parts :P)
i know this hasnt anything to do with the GSdx code but for a while now everytime i compile the latest source with VS 2008 Pro Edition i keep getting 2 errors both are 'error C3861: 'XInputEnable': identifier not found e:\pcsx2-read-only\plugins\xpad\xpad.cpp' in lines 666 and 694, i have the latest DX sdk installed (march 09) just wanted to know if it was problem at my end or not?
You need to put the windows sdk at the top of the global include dirs of visual studio.
Gabest, on another note. Can you watch issue256 ?
I've posted a "big" optimization on the DirectX9 Hardware renderer with a simple patch. (I'm still trying to get the hang on the whole way GSDX manages DirectX)
BTW, Gabest, SW The Force Unleashed has the same problem which Simpsons Game had, half of the screen is covered with map's sky texture
here's the GSdump http://rapidshare.com/files/238516824/SWtFU.rar.html
please take a look
Nice that fixed my xpad compile errors thanks for the help Gabest.
Good improvement, but when there is too much light or sun, it becomes very slow. Keep good work.
Hmm, pcsx2 can't resume anymore with this.
Run a game, hit escape, hit run > The gs plugin failed to initialize
Hey gabest11, excellent work on the gsdx plugin, and the same for all the pcsx2 team. Your efforts are being too much apreciated :)
My question is, ¿why I don't have the SM 4.0 option in this rev using DX10 hardware? I have a dx10 card of course, and I never had that problem before with other versions. Is just a doubt.
+1 rampapcsx2,
"Run a game, hit escape, hit run > The gs plugin failed to initialize"
with this new version I can't resume too.
I'm happy with anything that makes MFC dissappear a little more from the world XD
but out of curiosity... what was the gain for gsdx from seperating from MFC ? except smaller dlls of course XD
Just trying to make it more portable.
GSWnd/GSDialog should be abstracted just a bit further, and if there was an opengl device class that can do the merging and interlacing stage, we could probably already compile it on other platforms.
(I found wxWidgets too much to setup for the beginner, ref could never compile it :P)
Same here as ramapcsx2 and erk.alx resuming doesnt work anymore.
Good to see more work on being portable thou :)

Revision 1311

GSdx: Streamlined several instances of CComPtr use in the Shader caches, as it
was causing general slowdowns due to internal reference counters. Gives fairly
significant speedups (6-15%) across most games and both DX9 and DX10 alike.
The objects in question are all perma-pinned via the CComPtr<> containers in the hashtables, so using CComPtr object copies within the scope of the Shader lookups isn't needed.
In cases where the hashmap lookup is always done (such as vertex shaders), I just used the iterator result directly. In other cases where the hashmap lookup is done conditionally (stencil shaders), I switched from a CComPtr<> to a basic object pointer.
Main benefactors of this change are a ff12 scene (176 to 226fps) and the xenosaga engine also likes it a lot.
Perfect, right now I'm playing XenoIII and i can test this rev these days.
I was using 0.1.6/0.1.7 due to a problem with some videos (the opening one, i.e.) generated with game's engine, do you know if this problem it's still there?
Here i posted the exact error with 2 captures:
Bye :)
Greatly SpeedUps FFXII especially to cutscenes
You're magician, Jake... GS is a bottleneck for a lot of games, it will be highly appreciated if you help Gabest with some optimisations...
If only "Mi'ihen Highroad, south end" in Final Fantasy X could run full-speed... That's a dream... That location is too heavy for GSDX...
Wow! Thanks Jake!! Xenos and FFs are my favorites :)
OMFG... MGS3 fps just doubled with this, congrats Jake and all the team.

Revision 1312

GSdx: the BeginScene/EndScene optimization for dx9 ( Issue 256 )
no one calls BeginScene the first time, but who cares :P
lol, it was ticking me too, but it work, so who cares. :D
gabest, quick question here:
In what way is DX10 better/faster than DX9? Same goes for SM4.0: Why use it?
when I asked what I asked I of course meant for emulation purposes...
I can answer for small part to this. One of the most important thing is that DX10 cost per draw call (of CPU power) is a lot lower allowing an higher number of call per frame.
I doubt anyway SM 4.0 will have any kind of performance improving over SM 3.0 or others because they rely on the fact that you have to use the new features or higher limits. The PS2 use very simple shaders so over the SM 3.0 i seriously doubt there will be any difference.
for some reason the shaders are compiled in some cases as vs_4_0 and ps_4_0 and I wanted to know why exactly.
I'd be very happy if gabest would add to your answer, feal87.
one issue: if I open a game, then press ESC back to main gui, then open another game, it will report GS init error. I must close the pcsx2 and run it again. But old revision is not so.
correct if i'm wrong, the differences are mainly two, first dx10 is a lit bit faster than dx9, and second dx10 is usually a lit bit less glitchy in terms of graphics...
but keep in mind this is very game dependent, you might encounter games with no advantage between the two or even games where dx10 could be a lit worse, these are just a general rule...
junrgao its a problem not with this build, but with the MFC removing one some commit ago. I think gabest already know...
- texture uploads (managed textures/locking/dirty rects vs UpdateSubresource) and downloads (GetRenderTargetData vs CopyResource) are faster
- region repeat addressing mode does not need in-memory repeated and separately uploaded textures, which could make a significant difference for games that using it
- sprites are expanded to triangles in the geometry shader (not much but still)
- vertices are sent as is, no need to convert the components to floats because sm4 has proper integer arithmetic
- [email protected] already mentioned it, states are combined into a few larger blocks, less calls to modify them, even though I'm already caching them similary.
XTra.KrazzY: sm4 is dx10 exclusive.
junrgao: never ever felt like doing that, why would you escape then resume?
Esc > Resume works nicely now. (Well, used to :p ).
So you can use it to change options on the fly (debugging), or just pause the emu.
kebrus: Not all of us want to upgrade our operating systems just to be able to use direct x 10 though.
While I'm shocked it doesn't pop with a mismatched beginscene/endscene, works like a champ with a nice speedup.
the debug runtime gives a warning though

Revision 1313

- Removed flaghack1 since it didn't do much over flaghack2 (except break games
Flaghack2 is now renamed to "Status Flag Hack", and so-far we haven't found a
single game it breaks, so compatibility is high.

Revision 1314

GSdx: escape/resume fix
Yay :)
Great, working perfectly now :9
min fps on Xenosaga is now 32-35 on the first heavy scene (fluid enough - native), in the begining of FFXII even at 1024*1024 int res it is pretty playable on the slow parts average of almost 40, that pretty nice for my 3.0Ghz SSSE3 and 2600xt.
I want to report, in each of GSDX version DBZ infinite World is more slow on the parts that the sun shines, especialy on the desert stage, from the desert intro and when the screen rotates to view the sun PCSX2 sais 55fps but the scren moves arround 5-10fps and is worst in each build of GSDX it also happends on Zone of the enders 1, is very very slow, on later revision
I used to play to an 40-35fps but now it says 12-15fps, this not happend whit Zerogs plugin.
Excuse My English
I've just noticed that Gsdx lost it's post-build event in VS2008 project, so it doesn't rename and copy it to desired folder... Maybe it's a bug on my side, but check it anyway... I've reloaded project file and gsdx folder from SVN - all the same...
I had to remove one of the style sheets a while ago, it set to many other paramters that conflicted my own.
Please, add ".\postBuild.cmd "$(TargetPath)" "$(TargetName)" $(TargetExt) $(PcsxSubsection)" in post-process with next commit then... I think it will not interfere with anything important...
jerrymelendezh what pcsx2 version are you using, are you using dx9, are you using VU cycle stealing (its sucks with Devil may cry 2 make it slower)?
I used ver 0.96 r1314, and 096 official, but testing gsdx dx9 new builds, tried diferent things vu (not vu stealing), it appear to be a gsdx thing not emulator (slowness do not happend with zerogs plugin)

Revision 1315

- Minor Changes. Shouldn't effect anything.

Revision 1316

- Further optimized status flag updating...

Revision 1317

- Fixed a bug from r1315.
That was quick, and xs works again :)
the "shouldn't affect anything" bug.

Revision 1318

- Implemented m-bit functionality. Fixes Crash Twinsanity and most-likely other
Note: If anyone has any games that have broken graphics when mVU prints
"microVU0: M-bit set!" to console, then please notify me about it.

Revision 1319

- Fixed a very rare case, where both upper and lower instructions read and write
to each others regs.
ADD.xyzw VF1, VF2, VF3
MOVE.xyzw VF2, VF1
- Forgot to commit iVU0micro.cpp on my last update...
Hey! Missing snow particles (and probably others) in ToA are now properly showing on world map as of this rev. :)
Disappearing geometry upon approaching towns remains, however.
red terrain bug in Shin sangokumusou 4(Dynasty warrior 5) was fixed.
but character polygon is still a bit broken.

Revision 1320

GSdx: config dialogs disable unrelated controls again

Revision 1321

- Minor Change...
Castlevania Curse of Darkness: at save point appears
microVU Warning: Block List Overflow
microVU Error: Program went over its cache limit. Size = 0x404e8

Revision 1322

GSdx: added post build step

Revision 1323

Fix for Tekken Tag Issue 259
Removed the doubled up timings on SIF DMA cycles (should have been done when it
was spotted really)
Put in a fix for Scratchpad reads which cause a VTLB error.
thanks, ref :)
Tekken Tag GIF bug was fixed in this rev.
but pcsx2 crashed during fighting.
thats not uncommon, that's happened for eons ;p

Revision 1324

Couple of very minor changes for GIF/MTGS GIFTag reading
"very minor" usually means that nothing is going to work till the next fix up!
I admire you guys for working so hard !
we aim to break..
i..i...i mean please

Revision 1325

- Changed sVU/mVU allocation order and addresses to hopefully solve allocation
problems a lot of people were having.

Revision 1326

Linux:Fixed up the speed hack dialog to show the correct speed hacks for

Revision 1327

Re-enabled Precompiled headers in release builds. Believe it or not this fixes
crashes in the IPU's coroutine system that started happening in r1319. Yes, as
you might recall, we *disabled* PCH on release builds back during
Pcsx2-Playground because it was causing crashes in Coroutine. Now re-enabling
PCH *fixes* the crashes in Coroutine. I'm not making this up.
No, Ferrarinews, this revision *won't* improve GT4's graphics.
Pointing out, the crashes ONLY happened in release build
lulz, funny enough i was reading something that i showed krakatos
Limitations on LTCG Use
While LTCG is generally a good thing, there are a few potential pitfalls that might affect you. First, precompiled headers and LTCG are incompatible. This shouldn't be an issue for most users, since you typically only turn on LTCG in release builds, where compilation time usually isn't a problem.
So there you have it boys and girls, something which is incompatible stops it crashing...
This is prolly outdated. Otherwise I'd be fairly shocked the compiler doesn't even warn you about that :p
Yeah that applied to VS 2002 and maybe 2003. Definitely not an issue in 2005 or 2008 (where-by microsoft fixed up the PCH system nicely).
Yeah back in the VS 2002 days I avoided PCH because it was buggy and stuff, but I've really never run into any problems with 2005 or 2008 versions. The current PCH engine even handles Boost, in all of it's templated macrofied glory! :D
Ferrarinews comment made me chuckle.
I like the last sentence in your svn log :P

Revision 1328

IPU1chain is now a function rather then a define.
Thought I'd get this off my to-do list...
I'll probably refine this a bit; I'm noticing things I could do differently.

Revision 1329

Revised Ipu1Chain, and tweaked Ipu1Dma.
good job!
It occurred to me after my last commit that I didn't *really* have to pass totalqwc back in ipu1chain, then I noticed a bunch of repeated code and some conditionals that were tested more often then they needed to be and things snowballed a bit.
What sucked was having to sit watching a bunch of opening movies to have a reasonably good idea of whether I broke anything.
And I don't own "Britneys Dance Beat", and I doubt I ever will, so this still could have broken things, though I don't think it did...
Ive actually rewritten the IPU dma, however i havent committed it as the IPU bitstream is a mess (got it to the star ocean fmv's work and Growlancer, before it was one or the other) so half the ipu is going to need rewriting for it to work properly.
Haha i can hear saqib screaming: "Don't mess with my IPU!!" :P
Seriously though, good job team :)
If you're rewriting the IPU dma, that'll be nice to see. The IPU on a whole needs work.
Depending on how much rewriting it needs, we could always do an IPU branch... :)
IPU isn't that also why mana khemia doesn't work XD (which is completely broken atm btw, don't know which rev did it but i'm too lazy to test right now)
is it just me or is the ipu one of the buggiest parts of pcsx2 atm? (many games I play have probs with that... or with GSDX xD)
It's one of the buggier areas of pcsx2. There are others (there's a reason why the Vu's are being rewritten), but it's up there.
And just checked Mana Khemia, and it looks like the same issue as Ar Tonelico 2. Do a savestate any time it hangs on a black screen, and it'll start working again.
It looks like that may be more of a new Gust issue, since Atelier Iris 1 seems to have the same issue[1]. I'll have to test a few other Gust games.
[1] I noticed it was also having issues while testing my commit, and verified that it was from before my changes...
And I mean *any time*. Takes doing it 5 or 6 times before the title screen. :(
Right, Gust games use the IPU in a weird way (nothing fancy, just weird).
And bending the code so this works often breaks a few other games :/
Nice work on the rewrite :)
Reminds me of when I rewrote the ipu dma as part of my ipu implementation... then someone told me saqib was also making one, and lost my mood.
In the end saqib kept most of the old stuff, so I coudl have still implemented that IPU, but once somethign like that happens, I rarely get my interest back... :p
Ill put my dma code on pastebin later when i get home (unless i can get my housemate to enable my remote access)
Cool. And that's a good reason to put it in a branch, too. Makes it easy for multiple people to work on it.
And I can confirm that it's a gust bug. I've now tested, and found spots where movies hang on Atelier Iris 1, 2, 3, Mana Khemia, and Ar Tonelico[1]. I suppose I should update Issue 253 .
Though I'm still wondering how r1295 would have broken something in ipu...
[1] And, yes, I own all 5 of those. I like Gust games.
depends if they use path3 at all or send some images through vif, however i dont get it either :p
I can have a look at that to see why its causing it to hang though. However it might be due to ipu being rubbish, the fact there was a bug elsewhere too cancelled it out, it has happened in the past.
I hope to solve the Katamari damacy opening movie problem.
arcum: I hear you ^^ I like all ps2 nippon ichi games (disgaea series and spinoffs + atelier iris and some more I think) I buy every game from them I can get my hands on XD
damn you google for not having an edit button...
meant to say that
I didn't note the mana khemia issue to have it fixed soon just thought it should be noticed Oo but I do hope that it will be fixed eventually XD (I can't play ntsc games on my ps2 so I never played the game further than to the "off campus map" and no I will not use the gust "hack")
here we go, my ipu1dma i redid

Revision 1330

GSdx: Found three other instances of CComPtr that could be removed. (DX9 only)
After this change, almost all calls to addref/release were finally eliminated from the profiler results. So I don't think there are any more left, or if there are, they're not in speed-critical situations. :)
I also just realized the syntax ends up looking pretty hilarious in a sense, since the various typecast operator overloads make it do things that allow totally illegal-looking syntax to be working syntax (assigning a dereferenced object to a pointer, for example).
How is that even compilable? Shouldn't it be something like:
if ((IDirect3DSurface9*) surface = *this)
I assume you're typecasting it to a pointer of a surface...
take a look at the redefined * operator david. Its EVIL. :D
(anyway no, its declaring a new variable inside the if(), i know as well its strange, but it works...)
oh boy, you redefined that operator? damn :-P
and yeah, creating vars in if tests, never did that, gives weird stuff with the return values and testing those... But I suppose you guys really know what's going on here.
That assignment just calls for operator IDirect3DSurface9*, which makes sure m_surface was queried from m_texture and returns it.
... same as if(IDirect3DSurface9* surface = operator IDirect3DSurface9*()) {}
And I also like switch(type t = funct()) {} if I need "t" inside the switch :D
With an older msvc version constructors like if(type t(...)) also worked, but not anymore.
Speaking of which, does that if(Type var = name) stuff fly in GCC? Ie, is it part of the C++ standard? I've never seen anyone else use it, and never thought to bother to try or look it up myself. It'd be typically fitting if GCC doesn't allow it since it is actually fairly practical in many cases.
it's standard
6.4 Selection statements [stmt.select]
1 Selection statements choose one of several flows of control.
if ( condition ) statement
if ( condition ) statement else statement
switch ( condition ) statement
type-specifier-seq declarator = assignment-expression
Actually, if I'm not mistaken, you can declare vars anywhere you want in c++ (not in c). But depending on where you declare them, you won't always be able to access them because of scope stuff. That's why I put (most) of my declarations at the beginning of functions.

Revision 1331

GSdx: cleaned up some obsolete code
those dx9 surface ptrs were initialized in the constructor anyway... :P
Nice clears, make the code more easier to read.
(Anyway take a look at issue262 , we had a finding into the code that may fix slowness in lots of directx9 games, it seems that the dirty rect calculation in DirectX9 is wrong somehow and get XenoSaga2 and other games to do 1024x1024 texture update lots of times a frame. I've tried to resolve it, but i'm quite lost at some point. (More information in the issue))
xeno games use one huge texture and each small area has a different palette, even addressed in region repeat mode, that really hurts dx9 mode.
... and for dx9 I have to create the repeated textures in memory on the whole surface, that's why the full texture gets updated.
I "searched" something interesting in Browse -> search
GSRendererHW.cpp - trunk/plugins/gs/gsdx9
line 815 & 829
// FIXME: region clamp returns the right rect but we should still update the whole texture later in TC...
Some old commit?
Hey, I'm not saying it's wrong to initialize vars in if tests.
It was my mistake commenting on something without really checking the whole code...
lovecs0079: looks really old code, that time the pixel shader did not do region clamp
david.jennes: I'm not saying you are saying it's wrong :D
stupid remark , but in vs2008 , Release SSSE3 sould be Release SSE3 , no ? or is it like the dust that makes a diamond perfect
SSSE3 is correct. It's only affecting GSdx btw, and that has SSSE3 opts but no SSE3 ones.
Confused yet? :p
SSSE3.1 is part of SSE implement right ?.
Release SSSE3 or Release SSE3 doesn't matter, since we only use SSSE3.1

Revision 1332

R3000air: Implemented new Event Scheduling System from scratch! Probably still
buggy, but so far it boots some games and runs ok. Need to add better logging
options, cleanups, other stuff (ie, much work to be done yet >_<).
I also have several improvements to the recompilers in this commit, they're very nearly capable of executing code now... but they're disabled for the moment since I'm making sure the new event system is solid.
I believe I just wet myself. nice.
Nice job jake, one thing i will point out, in the counters where youve gone the gates, you arent stopping them at the start, so they are actually counting way before the gate is triggered. I did fix this recently in the normal trunk.

Revision 1333

R3000air: Maintenance merge against trunk (lotsa revisions since my last merge

Revision 1334

- Implemented a faster block-compare algorithm.
Note: Some games might crash in the release build with this revision.
This is an old IPU pcsx2 bug that has just decided to show up now because my recs have altered pcsx2's memory allocation and randomly 'woken' up the bug.
In a few updates, it will most-likely randomly fix the bug.
For now, devel build is probably the best choice to use if you want stability.
Also, note for arcum: there's no actual need for that function to be naked. Just remove the naked and the ret and it'll still work fine. That way it can be translated into gcc inline asm.

Revision 1335

non-functional change [Win32/msvc only]: Small cleanup to pragma packing syntax.
I hate #pragma pack. What an albatross.
gow 2 have mpeg unexpected error!!! should it fix it

Revision 1336

Fixed Linux, and merged a few minor changes I had lying around that I hadn't
committed yet.

Revision 1337

microVU: Improved struct alignment method using placement new syntax, reducing
microBlockManager's heap allocation count from 2-per to 1-per. :)
oh noes, the l33t revision goes to Jake
for the 1337 rev http://icanhascheezburger.com/2008/03/23/funny-pictures-happy-chair-enjoys-life-to-fullest/ you won happy chair
Of course it does. That's 'cause Jake is 1337... :)
This also fixed the Release mode mpeg/coroutine/ipu failings! I'm a miracle worker, because I still have *no idea* how or why coroutine causes breakages like that (besides the obvious fact that it breaks like a half dozen basic rules of writing code that's intended to run under the umbrella of a co-operative operating system like XP).
when will i get a cool revision number :(
I think 9999 is a (super) nice number.
You should camping for it :)
There's 1357. It goes up in twos from left to right.

Revision 1338

GSdx: should fix Issue 263 , but I could not verify it
better luck next time for l33t XD
Thanks gabest, it worked.
I would have probably noticed it sooner, that was my first time compiling in like 1-2 months though due to OS switch and laziness however.

Revision 1339

GSdx: added vs2010 project files
This new MSBuild system is still a huge mess though.
If I add directx to the global include/lib path (Microsoft.Cpp.$(Platform).user.props), it will auto-surround it with quotes, but if there are quotes in the path then apparently nothing gets inherited from that sheet. Had to manually remove the quotes them to make it work.
Another prob that it can't see user defined macros like PcsxSubsection if the sheet containing it was included later. The order of ProjectRootDir.props and common.props is important in GSdx_vs2010.vcxproj:
<Import Project="vsprops\ProjectRootDir.props" Condition="exists('.\vsprops\ProjectRootDir.props')" />
<Import Project="vsprops\common.props" Condition="exists('.\vsprops\common.props')" />
<Import Project="vsprops\debug.props" Condition="exists('.\vsprops\debug.props')" />
>> If I add directx to the global include/lib path (Microsoft.Cpp.$(Platform).user.props), it will auto-surround it with quotes, but if there are quotes in the path then apparently nothing gets inherited from that sheet. Had to manually remove the quotes them to make it work.
I had the same issues when I tested it with pcsx2 -- after the converter crashed and I had to make the pscx2_suite solution by hand. >_< It totally butchered the gnu gettext defines, which are like FOLDER=&quote;lang&quote. The converter just stripped it all out and put in some random quotes around another define later in the list -_-
On the bright side it seems the new macros system has other features that would allow for the whole of the vsprops system to be simplified. Namely, it defines a lot more path information, and so some of those user macros can be replaced with VS-level ones (yay). But re-factoring all the build setups isn't something I want to do until after beta's over.
I'll also make note that I preferred the old syntax of the project/props XML, as far as human readability goes. New syntax is the full-on ugliness of XML, where the actual value of the attributes is like lost in the sea of CamelCases and <>s.
The happy medium would have been:
<opt id="FavorSizeOrSpeed">true</opt>

Revision 1340

GSdx: Applied normalization of UV in the DX9 texture repeat shader, allowing it
to be re-enabled. Fixes massive slowdown in the Xenosaga 2 opening menu ( Issue
262 / DX9 only) [note: collective fix uncovered by sudonim, feal87, and
drk||raziel -- I'm just the patching boy]
I'm not sure if that is a good idea, it adds another level of texture lookup, which was too slow when I last tested it.
Note to users: The specific feature fixed by this patch isn't really used much by most games, so don't expect much in the way of general speedups.
palettized lookup was also removed for the same reason, that would further reduce cpu-gpu traffic, but just was not worth it, expanding it to 32 bit in memory was much faster.
There should not be a problem as almost nobody is GPU limited. Almost every of the gsdx slowdown are CPU related. (From the test we've done, no slowdown occurred on ours machines)
Well, let's wait for the users to say their own, if it is a problem we can make this an hack maybe? Only for Xenosaga likes game? What do you think gabest? (the change is from 10fps to 200fps in xenosaga2)
Still, it could make a huge difference between gpu generations. Dependent texture lookups were dead slow a couple of years ago.
Anyway, I'm going to clean up that normalized, full range texture coordinate conversion mess :P
Rama and I have tested across many games with internal res native and high both (his gpu awesome, mine fairly sucky), and neither of us found any speed regressions. So I think it's fine.
Maybe it causes some slowdown for 7300GTs or something? Do we care? :)
I had a 6600gt that time.
Oh, I had to use a 6600GT as replacement for a while.
It didn't play any game half decent anyway :p
Yeah I just tested it on a laptop with an intel965 (dated 2004, PS2.0 only, even! O_o) and this rev is same speed or faster for all games tested. I think it's good to go. Whatever vexed the 6600GT isn't relevant anymore, and if someone *really* has fault with it, they can use an older version of Gsdx to go with their older version of technology. ;)
ok, nobody moves, I'm rewriting the shaders! :P
rewriting shaders !!!!!! i think i gonna cry"""""hope it do any better""""
just hope it won't be worse :D
Just to ask gabest, i'm actually debugging star ocean 3. It seems that while the whole scene is only 500 or less draw, actually do 1500 draws with a 1000 draws loop of
1) Draws finished scene into a 1024x1024 texture stretching.
2) Draws 1024x1024 scene back into the finished scene stretching.
3) Draws a game primitive.
Why is that? Any idea? I'm trying to find the reason without success by now. :P
could be some kind of fullscreen effect
If it helps, slowness can be fixed by uncommenting this one (known as the tri ace speedhack :p ).
if(GSUtil::HasSharedBits(fi.FBP, fi.FPSM, fi.TBP0, fi.TPSM))
// skip = 1;
well, manual bilinear sampling fixes a few problems like yuna's face, but four times texture sampling kills the fps on my 8600gt, and if I added palette lookups... that would be awesome slow :D
Hmm, make it optional or so? Or have the code commented out? :p
Mhn...thanks rama, so it seems like its really a postprocessing effect. I think we should make an hack option for it and not a real change, because that hack may have unwanted effect for other games.
What do you think gabest? Should i make a checkbox with the activation for that line?
It'd really make sense to have that hack optional.
Not only does it speed up stuff, it sometimes fixes some serious post processing errors.
don't change that line rama showed, instead a crc based function should cut that part based on addresses and pixel formats, if it does not change the look of the game of course
ok, i'll work on it and test it well before doing anything.
maybe it's my desktop tricking me, but on my notebook texture lookups run much faster, which has a 9600M GT...
if you make a patch we can test on ours machine before and after and tell you the results. :)
First one lets d3d do the bilinear sampling for wms/t < 2 (non-regional addressing modes), second one does everything itself.
The problem with region clamp (wms/t == 2) that the four texture coordinates must be clamped and d3d won't do that.
Ok, I've been testing patch 2 under dx10 mode (mostly).
It makes quite a few games loose fps. I didn't see any problems fixed by it either.
Didn't know what to look for especially, so I might be missing something :p
Same here, first patch is the same as the actual svn, using the second one i lose some fps.
gabest, i've made the patch for star ocean 3. Can you tell me if this is the right way? (it works fine ingame thought, i just want to ask if the coding style is correct. :D)
Its the first time i tinkered with the CRC patching system.
(lol i typed wrongly, change 3 into 1 in the skip value)
This revision gives about a 10 fps speedup on Soul Calibur III menu's on my computer. where the menu only ran at about 5fps or lower on the main menu screen and character select screen they both now run at 15 - 17 fps. also seems to have very minor improvements in speed in other areas of the game but nothing as noticable.
If it's important at all - 3.0ghz P4 proccesor(w\hyperthreading) and a geforce 6600 card.
> well, manual bilinear sampling fixes a few problems like yuna's face, but
> four times texture sampling kills the fps on my 8600gt, and if I added
> palette lookups... that would be awesome slow :D
Do you mean her face looking like it's split in half? or maybe better said, there's a black line going down her chin? If so, where did you enable it? in your graphics card control panel or something similar?
Im not sure to post this here or not or if it's even relevent. But just recently upgraded my graphics card -
Old: Geforce 6600 w\256MB (AGP)
New: Geforce 7950 GT w\512MB (AGP)
Um I guess i'll keep it short compared to what i was just writing...
From this exact same revision/settings the SCIII menu's once again got slightly faster.
But the big thing was looking at the character profiles went from .5-ish fps to almost 20 fps. and battles are now semi playable too still slow with two moving characters on screen but abig improvement.
Im guessing the extra memory on my new graphics card helped it out??? If anyone sees this and wants to better inform me please do. other then that i just felt like reporting my info.

Revision 1341

GSdx: pixel shaders were reorganized, things might be broken :P
Xenosaga 2 title screen on my Intel x3100 DX9 mode has gone from 53 fps to 59 fps thanks to this patch...:)
how much vram do you have?
mhn...0 dedicated, because its integrated. It is autosetted to 384 of system ram however.
words missing in FFX startup and incorrect textures in intro
hm, did you build it yourself? make sure you recompiled the rc (right click compile).
rebuilding gsdx corrected the problem.
Everything right, except movie intro, crashs. Thanks.
Yes GT4. I take the opportunity, to give you congratulations for the great work. (before someone delete this)
You just never give up do you about GT4, you must be the biggest fan of the game in the world lol
Lots of interesting stuff going on with GSdx these days (like experimental changes :p) and huge speed increases have been noticed over a couple of SVNs, very nice.
ferrarinews, if you want to thank us in away way shape or form for our work, i ask you never post on google code again, this would be HIGHLY appreciated.
FFX is almost totally untextured now, the same bug is presented in Crash of The Titans
rebuild it fully, vc does not notice changes to the shader files refered in .rc2
this revision broke the texture filtering option its now always on for 2D and 3D and cant be disabled even if the box is unchecked.
gabest11 thanks now works, BTW faces in FFX on DX10 not splitted anymore thnks again
I wonder if DX11 will have anything good for speed or more accurate graphic emulation.
Any words on this?
Also, hair in FFX in DX10 is *almost* fixed. There are a few issues with transparency (border of Wakka's hair is sometimes fuzzy and a bit of hair texture floats in the air next to his "horn", but that depends on the environment too, sometimes it's perfect) and shading (instead of gradually, Tidus's hair changes its shade abruptly), but it's a lot better than before and you have to actually look for the inconsistencies because they're hardly noticeable. Maybe I won't have to play FFX in software after all.
In sw mode if you look at the wings of the chocobo there is a similar transparency problem. I'm still clueless why.

Revision 1342

Linux: Make the build system even more hackish, to avoid issues with AC_OUTPUT
and automake 1.11.
AC_OUTPUT seems to be refusing to recurse past the top directory in the latest version of automake; on clean installs, anyways. More headaches from having source files and headers outside of the pcsx2 folder...

Revision 1343

- Implemented E-bit Conditional Branches and Jumps. Should fix infinite loop
problems in games like Zone of the Enders, but it hasn't been tested yet since I
don't have the game xD.
Yeah it's fixed now, great work for not having a game to test :P
glad it worked xD
It chrashed Champions Return To Arms, wich was at least barely working before :P
i don't think this revision can crash a game.
if you're on linux and compiling with gcc its possible r1345 will crash for you.
or it could be you're compiling release build, and its the IPU making it crash.
this isn't microVU's fault, its a random IPU bug that we need to urgently fix, but it needs huge IPU rewrite and none of us have time time currently...
Im using Windows on 'Release'.
Before this change, microVU logged 'microVU1: Exiting from possible infinite loop [12f0]' and after a while it did, now it keeps on logging it :P
Anyway, thanks for your replay, sems like i still need to wait a while until it works ;)
i know the cause of the problem in that game, and i was able to hack-fix a solution; but i don't know what the 'proper fix' is.
i'm going to be doing some tests to see what the real ps2 does to try and find a solution.
That would be awesome!
Thanks ;)

Revision 1344

R3000air: slowly progressing. (working on a won't boot bug in FFXII)

Revision 1345

- Rewrote the custom compare function to use the emitter instead of inline asm.
- Set Linux builds to use the function.
Note: If this revision causes microVU to crash on Linux, it means GCC isn't
guaranteeing 16-byte alignment on microRegInfo and microBlock structs. So it'll
need to use normal memcmp instead (see microVU_Misc.h)

Revision 1346

R3000air: minor cleanups. FFXII still doesn't boot, but I've narrowed it down
to some hocus pocus with the SIF.

Revision 1347

R3000air: TortoiseSvn borked some line endings in my last commit.

Revision 1348

Linux: Not sure if this is neccessarily an alignment issue, but Kingdom Hearts 1
crashes on newgame with the new compare function, so we'll have it use memcmp
for the moment.
I didn't test under Windows, so this could be a more general issue...
well if its crashing and the debug info shows its the compare function then it means gcc isn't aligning all the struct instances.
unless its crashing on IPU, which is an old coroutines problem that randomly is effected by differences in pcsx2's mem arrangement.
anyways, the custom compare function isn't 'that' much faster, so its not that big of a deal to use normal memcmp.
Haven't actually had a chance to test it more thoroughly yet. I'm actually getting ready for work, but thought I'd test KH1 (since a good deal of my other standard test games are Gust games...), and saw this crash.
And since it worked with memcmp, I thought I'd change it till I had a chance to look into it more...
>> unless its crashing on IPU, which is an old coroutines problem that randomly is effected by differences in pcsx2's mem arrangement.
The coroutines problem is generally specific to MSVC and Windows. Linux hasn't had the problem, except maybe with GCC full optimizations enabled (which break lots of things in addition to IPU, iirc).
The GCC optimization issues tend to be version specific, which is really irritating. They are also likely to go away eventually as the code is revised. For example, I think the 2 optimization flags I turn off for gcc 3.3.1 and higher aren't relevant any more. I just haven't had a good chance to test and see if I can get rid of them yet...
Just verified the crash was in mVUsearchXMM, though.
Been fiddling with it, without much luck. Especially since __alignof__(mVUsearchXMM) reports back 0x1000.
I may as well at least set Linux to use memcmp_mmx, though...
@arcum: the variable which is alignment-dependent isn't mVUsearchXMM. It's the data that mVUsearchXMM works on. It's data nested inside a couple classes, and we've had problems before (MTGS) where GCC didn't ensure alignment of members of classes.

Revision 1349

* Fixed CDVD startup code sot hat the CRC for games is more reliably detected
when booting through Run->Execute.
* Minor bugfix to MTGS thread startup code; wasn't copying the register state
properly (probably didn't matter either way)

Revision 1350

Linux: Use memcmp_mmx instead of memcmp; Add a workaround to a segfault in iVif
on some games.
Hmm that one sure seems like another GCC bug, since it's pretty obvious that the asm code and intrinsic code *should* be doing the same thing (and furthermore that it works fine in msvc).
Someday when I get done with my recompiler, I'll do disasm dumps on linux and confirm bugs.
Yeah, the comment I deleted pretty much says it all about the bug.
I just got tired of having the current code crash in that particular case, and brought in the old code for just that one situation.
And I figured if Linux isn't going to use cottons quick search, and use memcmp instead, it may as well use zerofrogs "10 times faster then memcmp" memcmp_mmx code...
Yeah memcmp_mmx is fine. It's about 25% slower than cotton's version, I suspect, but still much much faster than basic memcmp. Only specific games which use a lot of register-based branching in the VUs are heavily affected.
That'll probably suffice for a while then...

Revision 1351

GSdx: texture filtering checkbox fixed, changed texture lookup a bit, removed
more unused code
fx files changed, make a rebuild
thnx gabest its fixed now
Shin sangokumusou 4(Dynasty warrior 5) is too blurry.
yea, dx10 mode, trying to fix it.

Revision 1352

They are vector units, not vertex units.
(Yeah, silly commit, I know :p )
+1 for the future of English :P
heh yeah, i was the one that did that typo xD
i commonly mix up 'vector' and 'vertex' lol
.... that mistake is kinda... understandable... to a certain point.... if you weren't coding the VUs that is XD (a friend made the same mistake once)
up to another point is the persona gamefix still usefull? if so for what XD
cottonvibes: Yeah, I just had to fix that xD
kabooz_k...: Sure its still usefull. The bug in svu still exists :p
in some way vertex are vectors of coords. ;p
Doesnt break anything! osm commit.

Revision 1353

- Small Optimization...
Would switch case be a bit faster than multiple if statements?
nah that doesn't matter.
the if/switch statements are done once at recompile time, and then the generated recompiled code (without the if statements) is run thousands of times.
also, in this case using switch statements won't offer any speed advantage.
switch statements are optimized better when there's a lot of choices.

Revision 1354

GSdx: dx10 hw mode sharper again
Seems faster in some parts, however I noticed in persona 4 in DX10 the left side of the screen has a extra pixel that looks bad and the "VU clip" hack in PCSX2 wouldnt work unless I "esc > execute" to resume (this used to happen to me before only if I used my monitor resolution as internal resolution).
something got broken in this revision
(thats supposed to be water)
this bug isn't present in the previous revision r1351, but it's still present in r1355
this is in directx 9, software is fine, didn't test directx 10
I can see the persona 4 problems too but the pixel on the left side can be seen on many games, also some other games are blurrier in this rev.
oh the top pixel line seems out of place too if you switch between 4:3 and 16:9 you can notice both the left and top pixel lines.
There's this type of bugs too, dx9 seemed fine so far.

Revision 1355

GSdx: fix for genji

Revision 1356

- Cleanup and organizational changes of VU related stuff.
- Separated Super VU, microVU, and Interpreter files.
- Renamed all Super VU related files with an 'sVU' prefix.

Revision 1357

GSdx: that damned different pixel center of dx10... this one should fix the
screen edge and other strange artifacts that appeared in non-native resolution.
Funny I realized only yesterday that in dx10 not texture sampling but the pixel output is shifted :D
Until the previous revision geometry did not come out looking the same as in sw mode or with dx9.
Good job!
yuna's black line in FFX fixed.
tales of abyss was sharper in r1354, now it looks blurry again.
Strange, it looks sharp enough here:
They are the same to me, if I quickly switch between them.
... so unless I made dx9 rendering blurrier too, dx10 should be ok.
... or maybe it's some effect I removed, but not in your version, do you have one of these?
{0x14FE77F7, TalesOfAbyss, US},
{0x045D77E9, TalesOfAbyss, US}, // undub
{0xAA5EC3A3, TalesOfAbyss, JP},
i have the undub and normal version, both crc match, and both of them are blurry in this revision.
Also i reverted the change in line 290 and 291 in GSRendererHW10.cpp, and the "double image" problem is gone
Did you rebuild?
yes, and i tried the builds in the gsdx thread and i have the same problem
ati or nvidia? maybe it's some weird floating point rounding problem.
This revision fixed assorted small, odd stuffs in some games.
Things like the bilinear filter now doesn't look different in dx10 than it does in dx9.
Didn't notice any sharpness problems either (in some 20 games other than tales of the abyss though).
Nice that's figured out :)
Ah, just noticed Tales has this output blur effect.
Maybe you have that option enabled, rbuldo?
Try toggling it on/off via END key while playing.
yea, that might be!
i have an nvidia, drivers 185.85
im playing in 1920x1080 internal resolution (tried other resolutions, same problem), and i didn't noticed any diference in 5 others games (rogue galaxy, ffx, xenosaga, god of war, persona 3) between the 3 revisions.
r1357: http://img3.imageshack.us/img3/9403/pcsx2r13562009061118133.png
r1354: http://img3.imageshack.us/img3/8774/pcsx2r13562009061118135.png
toggling on output blur effect makes r1354 look like r1357 (and r1357 even more blurry)
I'm getting the same image as on your r1357 pic, but the strange thing is, dx9 also just as blurry, which was not changed recently.
Going to check the drawing in details, but maybe it was programmed like that, and when I wrongly shifted the vertices it was sharpened beyond the originally intended :P
well, its much sharper by toggling output merger (with END key) here, but the pixels are still not 1:1 to the display resolution.
Also, in r1354 in dx9hw mode the game is blurry and have the double image problem but in dx10hw it looks good. In r1357 dx9 and dx10 are both blurry, and have the double image problem. Reverting the changes in GSRendererHW10.cpp lines 290 and 291 only fixes the double image thing in dx10. (All images i posted are in dx10hw mode)
Ok, figured it out, in r1354 two errors simply cancelled out, too bad :P
In ToA the scene is drawn very dark, and it uses that self-blending technique to increase the brightness (doubles the color values twice).
This is supposed to be 1:1 blend between the source and destination pixels, so the mapping goes like this: 0.5, 0.5, 512.5, 448.5 => 0, 0, 512, 448.
Half texel offset is because it uses bilinear, for no reason. If it wasn't, we had no problem, ironically.
The texture coordinates are normalized in d3d, to the 0-1 range, and then when the real sampling happens it is multiplied with the dimensions again to get the location of the texels.
When sampling the rendered textures, the dimension is not 512x512, but the resolution set for gsdx (1024x1024 by default).
So after multiplying by the dimension, we don't get back that 0.5 again, it becomes 1.0.
Then the sampler adds +/- 0.5, wraps the coordinates, reads texels from 0.5 and 1.5 (instead of 0.0 and 1.0) and interpolates them with the fraction of the first coord: 0.5 (instead of frac(0.0) => 0), effectively returning the texel at 1.0 (instead of 0.0).
If the rendering resolution was 2048x2048, the coords would be 2.0 (+/- 0.5) => 1.5, 2.5 (interpolation with 0.5) => 2.0. Which is already two pixels shifted up-left, compared to how it would look at native.
The more the resolution is increased the more bilinear shifts the re-used render targets.
I don't think there is any solution, unfortunatelly.
(good thing I used a few line breaks, stupid google :P)
The errors I mentioned were the bilinear shift and the dx10 half pixel shift (which was wrongly multiplied by the scale factor in r1354)
The two simply equaled and moved the image back to its place, just left empty rows/columns at the sides.
Stuff like that makes me wish for a good, old fashioned gamefixes tab.
Something like Pete had for his psx gpu renderers :p
Gsdx's configuration dialog are too simple right ? We need some gamefixes to make it look more high-tech :P.
Hm, then how about getting rid of the texture filtering checkbox? :P
In native it should be automatic, and checked when upscaled.
There's still games that look better (like some texts) with gray or unchecked filtering in higher resolution i think.
i agree with neferite, the texture filtering checkbox should stay. i use the gray mode to filter 3d objects but leave 2d sprites and text alone.
thanks for the long explanation gabest, at least now we know its a toa "feature" not a bug in gsdx. a gamefix would be great but for now i will use the bugged r1354 for this game :P
If no offscreen rendering happens (shadows for example) then the only problem you will see are those lines on the screen sides.
Something is wrong with Tekken games, I think this happend since the past few revs.
Check this Tekken 5 SS.
See that green texture on her legs? this is a mistake, and it keeps flashing, between correct textures and green/red ones.
I still don't have tekken. Could you find the revision where it broke and compare the renderers (dx9/dx10/sw)? A .gs would also be helpful, make it in sw mode (shift+f8).
ICO also had a strange colours bug on recent revisions.
You can see it on one of the intro scenes.
DX9 HW: http://img198.imageshack.us/i/gsdx20090613095958.jpg/
DX9 SW: http://img197.imageshack.us/i/gsdx20090613101517.jpg/

Revision 1358

Fix up Linux after r1356. Make a few changes that ought to make -fpermissive
unneccessary, though it needs more testing before I actually remove said flag.
Specifically, I need to test other versions of gcc without -fpermissive, to make sure gcc 4.4 isn't more permissive then gcc 4.3.
(I'm not really that worried about people having lower versions then that, to be honest.)
gcc is evil :(
Yep. No argument here.

Revision 1359

R3000air: I'm just running in circles atm.

Revision 1360

GSdx: looking for an opengl guru...
hm, would be better to delay load those cg dlls...
Dolphin-emu has a very good OpenGL plugin.
I hope that the future of gsdx will be OpenGL, no more people complain about thier outdated DirectX, and Pcsx2 will be more cross-platform compatible
lol, people will always find something to complain about dont worry :P
great to see work on OGL :)
The Linux side of Pcsx2 don't have any *good Graphic plugin, I mean a plugin that have a developer taking care of it. ZZogl is a nice plugin, but its performance, like ZeroGS, is not great
Hi gabest , do we have to install anu additionnal SDKs ?
Error 1 fatal error C1083: Cannot open include file: 'GL/glut.h': No such file or directory c:\emulation\ps2\source\plugins\gsdx\stdafx.h 118 GSdx
Yea, the cg toolkit:
And add include/lib path to the top in visual studio, similar to directx sdk:
C:\Program Files (x86)\NVIDIA Corporation\Cg\include
C:\Program Files (x86)\NVIDIA Corporation\Cg\lib
Sorry, Gabest, I think I could not be any help, because I don't understand you code ;-(. But GL_TEXTURE_2D is worth choise for GSTextureOGL realisation, it should be power of 2 sized. http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt is best choice.
GL_TEXTURE_2D can be used if ARB_texture_non_power_of_two supported, which is part of OpenGL 2.0, so it's more widespread than ARB_texture_rectangle, but old cards such Radeon 9xxx has very poor performance with such textures...
Gabest, I have a question - why using CG? As I know it is supported only on NVidia boards.
No, it's not only support Nvidia.
Afaik, many app using CG now, maybe because it's more friendly than OpenGL itself.
the VideoOGL plugin using by Dolphin-emu, are using CG, and I don't see any performance lost when using it in ATI cark
opengl is so confusing, maybe I just leave it like this, until someone more competent comes to help.
As far as I see, cg is only a "shader managger", still built on top of opengl.
I hope you'll find one. I prefer OpenGL over DX :)
CG is "C for graphics". Its essentially nothing more than a high-level shader language, with a compiler that compiles its code to either HLSL ASM, GLSL or GL ASM.
The idea is that it lets you write your shader once and use them in multiple rendering environments.
Theoretically, this can allow you to get rid of the DX shaders as well, and have just one set of shaders for the entire plugin. They can be compiled either offline or at runtime.

Revision 1361

GSdx: added ogl/cg to the list of delay loaded dlls

Revision 1362

GSdx: replaced switch with ifs in the shaders, kingdom hearts should be fixed
I get 17 errors when I try to compile this rev.
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewDeleteBuffers
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewDeleteFramebuffers
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____WGLEW_EXT_swap_control
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____wglewSwapIntervalEXT
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp__glewInit
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewGenBuffers
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewBindBuffer
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewDeleteFramebuffersEXT
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewGenFramebuffers
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewBindFramebuffer
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewGenRenderbuffersEXT
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewBindRenderbufferEXT
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewRenderbufferStorageEXT
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewBufferData
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewMapBuffer
GSDeviceOGL.obj : error LNK2001: unresolved external symbol __imp____glewUnmapBuffer
GSTextureOGL.obj : error LNK2001: unresolved external symbol __imp____glewDeleteRenderbuffersEXT
Hi gabest , for the glew files , maybe it should be better to put it in the 3rd party rep as for the dolphin emu projet.
Error 1 fatal error C1083: Cannot open include file: 'GL/glew.h': No such file or directory c:\emulation\ps2\source\plugins\gsdx\stdafx.h 118 GSdx
i mean using the "Including the source files / project file" option from http://glew.sourceforge.net/install.html , or i think that you will get a lot of compile complain in the upcoming revisions. Btw this is a remark from a total newbie in opengl :)
Headers only are just not enough, and I would not put libs there too.
For the error, vs did not save common.vsprops until I closed it, and glew32.lib was left out from this commit.
Texture problem in KH2 in DirectX10 is resolved thanks gabest :).

Revision 1363

GSdx: added missing glew32.lib reference
missing GL/glew.h
You need to put some include on your Visual studio.
Compiled, OGL Render unavailable
I have 3 new warnings now
1>.\GSSettingsDlg.cpp(202) : warning C4189: ogl: initialized, but not used
1>LINK : warning LNK4199: /DELAYLOAD:cgGL.dll ignored; import operations from cgGL.dll are not found
1>LINK : warning LNK4199: /DELAYLOAD:glut32.dll ignored; import operations from glut32.dll are not found
Wonder if Onimusha: Dawn of dreams will be OK too...
The opengl renderer is about 1% ready :D
I just started learning the api.
Hi Gabest11. The into movie in GT4 is gsdx Problem?
No, the GT4 intro is YOUR problem.
btw, good luck gabest, hope we will have a working OpenGL version soon :)
Are you stupid or took a course?
ferrarin :
Use ZeroGS to test if it is specific with GSdx.
After that stop ask about your f.. game in a rev that is just usefull to compile PCSX2 not for bugs or other things. If you've got a problem use forums and ask people and of course test by yourself (like test ZeroGS before ask all the time thx).
Ferrarin: If you don't shut up they're not going to fix GT4. I want to see it flawless too, but if you're just going to be annoying then you're not helping anyone.
*sigh* sorry. Keep up the good work gabest & the rest.

Revision 1364

Linux: Experimental - Add a alternate, more flexible, build script written in
First, not sure /trunk/plugins/zerogs/opengl/configure got modified in this commit. It shouldn't really be in the tree anyways. I'll have to prune excess files at some point.
And I should have another comment in a moment with the purpose of this build file...
Now, the purpose of build.rb:
I'll leave the current build.sh files in place for the moment, since I'm aware some people don't have ruby. This file can be used in place of all dozen or so build.sh files, though.
It can be called either by ruby build.rb <options> or ./build.rb <options>, depending on whether it is marked as executable. I set it as executable before committing, but who knows if it came through.
You *can* use it the same way as build.sh. But you can also just build pcsx2, just the plugins, or even just a few plugins if you want.
And you can use "dev" and "debus" to specify a dev or debug build on pcsx2.
#install a release build of pcsx2, not installing plugins
./build.rb pcsx2 install
#build a dev build of pcsx2, with the plugins
./build.rb dev all
#build zzogl, zeropad, and zerospu2
./build.rb zzogl zeropad zerospu2 all
There isn't currently a way to specify plugin options or more options to pcsx2 then dev and debug builds, but I plan to change that at some point.
Note that building pcsx2 with this script also creates a copy of the executable with the svn revision in it. :)
Note: the last example requires you to have zzogl in your plugin direcory, of course.
And this build file doesn't know about GSnull and PADnull. It's on the to do list.

Revision 1365

Delete a stray file that's automatically regenerated every time you build ZeroGS

Revision 1366

R3000air: Redid event system using a list instead of an array (tons faster), and
merged the iopEvtSys struct into iopRegs (also a small speedup and code
IopHw.h still contains
#include "IopEvents.h"
Good job on simplifying the code.

Revision 1367

R3000air: Bugfixes to event system.

Revision 1368

* Fixed crash problems when using SPU2-X with old versions of Pcsx2 (0.9.4 and
* Fixed broken Device specification override (the device GUID wasn't being
loaded from the INI).
* Added ThreadAffinity stuff to the CPUSpeed detection.

Revision 1369

GSdx: Minor bugfix for DoMerge encountering a NULL pointer in rare cases.
@Gabest: It's quite possible there's a more correct fix for this, but I knew enough to know that checking for NULL here certainly won't hurt anything else either. Feel free to review it if you think it's an indication of a higher level logic error elsewhere in device texture management.
(I should note that it happens in DX9, and I can't check to see if it also happens in DX10 or not)
oh, I'll check KH:COM, didn't test too much yet.
It's never NULL here.
Since it gets created just before that, the only way I can imagine it being NULL when texture allocation fails inside CreateRenderTarget.
>> Since it gets created just before that, the only way I can imagine it being NULL when texture allocation fails inside CreateRenderTarget
Correct. As the comment says, it's non-NULL when the function is entered, and then is attempted to be re-created (and then returns NULL). Is this a driver or video card-specific problem on my end then? Odd, everything else works fine (including the rest of the game after getting past this hiccup)
CreateRenderTarget calls into GSDevice9::Create(int type, int w, int h, int format), check hr after CreateTexture. It should fail as often as a malloc would...

Revision 1370

- Minor changes

Revision 1371

GSdx: Fixed Software-mode crash on Escape/Exit, caused by a couple destructor
race conditions. (C++ destructors and thread safety are fickle beasts that like
to claw each others' eyes out)
Basically this crash only happened reliably on quad (or better) core CPUs and when running under the MSVC debugger (F5). But it would have also caused absolute failure on GCC, which is much more picky then MSVC about trying to reference variables from classes that have already been deleted by another thread. (known from my experiences with MTGS)
For what it's worth I'm quite sure I could greatly improve the performance of the multithreaded rasterizer using pthreads' semaphores. The current system expends an incredible amount of CPU energy just testing the status of m_exit and m_sync variables. When I switched the MTGS from such a system to semaphores I got ~10-15% speedup... and I suspect the impact would end up being much more significant even when spread across multiple workers (3 for quads, 7 for i7, etc).
I think this one was the cause of the crash, m_sync should be freed after rasterizers were deleted, they are using it :P
I'm not sure how pthreads work, but OS sync objects are too slow, I checked it with intel's thread profiler.
Giving up the thread waiting on a some waitable object and getting the execution back wastes too much time (that 4ms).
Just spinning should have minimal overhead if every thread gets its own core, that pause instruction shoud make sure the cores don't go wild.
Strange gabest, i use WaitHandles for my game engine to handle multithreading (i have at least 4 threads (Draw, Update, Audio, Physics) except the main one) and i don't see any 4 milliseconds time lose on waiting/restarting the execution (otherwise, any game would not run not even at normal speed in my case (instead on a SingleCore cpu with a crappy DX9 ati card i get even 1000+ FPS with some simple game)) its more like microseconds IMHO. (I schedule them one per CPU and when the first batch has finished the others are signaled and started, and so on until every thread has finished (lock-step mode is called this method)))
Anyway I don't know the details of your implementation, so I can't be sure.
When you call wait* and the event is not set, then your thread gets suspended until it is rescheduled.
If I was doing that before every new primitive batch, which take about 1 micro to 1 ms to process, the suspension time would outweight the effective rendering time.
On sf.net in the old repository around revision 750 I still have the old code with events. With intel's thread profiler I could clearly see the inactive gaps. I might reimplement it again, just to take a screenshot of it.
I could however add a bit more parallelism by delaying the end-of-drawing syncronization.
Somewhere just before the gs memory is written/read again, or when the next batch is ready.
But for that I need to have a dedicated thread that is not rendering, just processing the display lists.
>> I think this one was the cause of the crash, m_sync should be freed after rasterizers were deleted, they are using it :P
That was one problem. I was also getting crashes on the state of the GSRasterizerMT instances on some occasions. Destructors have a bad habit of invalidating the virtual functions of a class before destruction is complete (actual state depends on the number, order, and type of inheritance the class uses). I had the same problem on MTGS. When I put the CloseThread() calls in my Thread class destructor, the threads wouldn't have a fully valid object state anymore.
On GCC it actually replaces the virtuals with a trap/handler that throws a "Pure virtual function called" assertion. On MSVC it just crashes from the debugger, and generally runs without any failure in release builds outside the debugger.
MSVC also has pure virtual call errors, I've seen tham many times :P
"them" I mean
hm, only seen them in constructors though, parent constructor calling a virtual will surely through that error
On Threading:
There are many different types of wait objects. Some are slow, some are fast. The win32 WaitFor and Semaphor objects are *very* slow for example. They invoke the kernel, which has to verify user mode permissions, securities, and other overhead in executing kernel code. On the other hand CriticalSections do most of their work outside the kernel and only have to enter the kernel for conditions where the thread is in fact idle and needs to sleep (in which case the overhead isn't costly anyway).
So yeah, WaitFor* functions are *very* slow and entirely not recommended for anything which doesn't have an execution overhead of at least a few milliseconds per job. Otherwise the cost will kill performance.
w32pthreads uses mostly interlocked exchanges and critical sections internally, and generally benchmarks with exceptional efficiency.
Isn't the implementation of those also spin loops and sleeps then? Internally.
Well, multithreaded rendering in gsdx is only about 200 lines, try to improve it if you can. I only a dual core, maybe not the most ideal to test it on.
"have" (stupid edits)
I hope google won't run out of storage space :D
Sorta. They're quite a bit more complicated in actual practice. It's the sort of thing where if you look at the w32pthreads code you'd swear with certainty that it's slow and horrible, and that a more direct route must absolutely be more efficient.
... and you'd be wrong, and feel embarrassed for not having used it sooner. That's what happened to me. I only ended up switching everything over to pthreads because I got tired of maintaining separate threading models for windows and linux, and hoped the speed loss wouldn't be too much. Much to my surprise my first implementation (using Signal no less, see below) was immediately faster than the fastest Win32 implementation I had come up with (which was a sloppy combination of critical sections, sleeps, and wait objects >_<).
Also pthreads has performance variety in functions. It's mutexes are fast, signals are slow, and semaphores are *really* fast. So for performant code typically it's best to use pthreads semaphores.
Is that ptreads lib in pcsx2's repo working?
Who inits ptw32_thread_reuse_lock for example? I cannot find any InitializeCriticalSection there... None. pthread_create just explodes inside ptw32_threadReusePop.
Other small prob with _ptw32_handle_t::operator =, it says it returns bool, while it returns nothing. Generates a compiler error.
zomg, ptw32_processInitialize is included through a .c file, but not in the project, hidden from searches...
yay, it has its own DLLMain where it secretly inits itself, wtf :P
finally, it works! just had to set the stack size from 0 to something bigger...
damn, still randomly crashing :P
something is seriously broken here, I cannot even get a simple thread running and exiting without heap corruption...
Ah crap. Yeah there's some tricky mess when using it as a static link job from DLLs (as you've noticed). When using from a DLL the safe way to use the lib is to also build it as a DLL of its own. Admittedly, I mostly only did pcsx2's as a static link because (a) I was afraid the other devs wouldn't like the extra added DLL dependency and (b) InterlockedExchange was a lot faster when it could inline (which is fixable anyway by just including and using a local version). So mostly (a). But now I'm not so worried about that, so I should probably go back make it a DLL.
Also, I was reviewing the thread job tasking process, and it dawned on me that yeah, most of this stuff won't make a significant performance difference because the current system doesn't queue jobs anyway. There really needs to be a queue system in place so that each thread can wake from sleep and have a whole list of jobs at its disposal to execute, before going back to sleep. Currently a thread would have to unconditionally go to sleep after every task anyway, which means any smarter/improved sleeping code will still enter kernel code.
How does the SW rasterizer divide jobs? If it's using a region scissor, with each thread in charge of drawing to its own area of the screen, then the threads don't need to remain in sync with each other. It should be possible to queue up a series of draws and then execute them in burst-style. It usually means a little extra management overhead to copy the structs into a queue, but usually the speedup of the thread task execution (which is typically significant, like 40-70% depending on the sort of tasks being executed) out-weighs the cost of a few extra copies by a wide margin.
It does queue up as many primitives as it can, which have the same texture and other drawing attributes, one thread may be drawing a different primitive than the other.
For interlockeds, there are inlineable intrinsics in msvc. Someone even posted a gcc compatible intrin.h in the comments before.
Ok, I reviewed the rasterization process and measured some timings and dumped some logs. I still think using pthreads semaphores should be an overall positive, although not by as much as I originally estimated. In any case it's still a good idea even if the performance increase ends up being minimal, since threads that operate on mutexes usually behave a lot "nicer" in non-ideal situations (ie, if the user has something else running in the background, you don't end up with as much high-priority thread contention and/or unresponsiveness -- which is increasingly important to account for in modern operating systems).
In any case I'll make w32pthreads into a DLL, and we can make it a policy that it'll be part of all future Pcsx2 distributions, for plugins to optionally utilize as suited.

Revision 1372

GSdx: more opengl code, please review, I have no idea if it done the right way
Jake: swapped that two things in the destructor of GSRasterizerList, please check if it crashes now.
sorry, can't spell this late, how do I edit the comments? :D
isn't there a magic function in opengl to redirect those gl* calls through some debug layer, that would check and print the errors? they are mostly dynamically hooked anyway.
Ok, seems to be working. I guess the freed m_sync ptr was causing mem corruption, as the crashes were definitely in the *this object state for the threads (when I tried to view 'this' in the debugger it'd just say "invalid" for everything, etc). But not doing it now with m_sync fixed, so hopefully all is good.
Hello, Gabest. I am not sure if this is a right place to ask...sorry if not (you can delete it anyway) The question is about texture filtering in 2d games in hardware mode (Gust's i.e) Is there a way to get rid of those ugly black borders around characters and around some background elements when filtering turned on? I mean Pete in his gpu for psx has an option when sprites smoothed and black borders removed. So is it possible to do something like this in gsdx? Because in software these games are slow for me, and in hardware when filtering is off sprites are kinda pixelated...
psx does not have bilinear filtering (and its sprites cannot be stretched, they are just 1:1 image copying), if a ps2 game uses bilinear the vertices are specially aligned on pixel centers with the decimals, which is lost when upscaling it.
I didn't mean real psx. I meant Pete Bernet's graphic plugin for ePsxe. Look: http://foto.mail.ru/mail/animus777/_myphoto/1.html
I know, I just explained why a ps2 game is different, if it has native bilinear then it breaks in different resolutions, psx did not have, so it scales better.
I expirienced black borders even in native res... Anyway, I guess it can't be helped. Thank you for gsdx improvements!
in rare cases there might be, compared to sw mode, region clamp mode is commented out in the shaders, it would be too slow... if you have a .gs dump I'll tell the exact reason.
I'll upload it when I am back home.
Here: http://www.4shared.com/file/112244218/bbc55865/Atelier_Iris2_black_borders.html
The black borders are also present in other games, is as if the alpha was failing (or some layer issue maybe), even on some rare cases on visual novels, which is really strange because the effects flips back and forth instead of being constant:
I can upload a .gs dump if it is of any help, but the borders only seems to appear briefly on (sprites?) transitions.
This is an annoying one, it has 16 bit textures.
After linear sampling the 1 bit alpha is combined into one single value, and I replace that with TEXA::TA0/TA1/0.
It should be the other way, to interpolate the replaced values. But then I have to do the slower manual sampling.
Or, I could upload expanded 32 bit textures, which is more work for the cpu and needs more cpu/gpu transfer bandwidth.
getting a compile error in visual studio 2008 pro 'Error 12 fatal error C1083: Cannot open include file: 'GL/glew.h': No such file or directory e:\pcsx2-read-only\plugins\gsdx\stdafx.h 118 GSdx' since updating to the latest version.
Read the last few GSdx commits for instructions what to do.
Thanks, even though i read all the changes and comments from the last few revisions i completely missed that. maybe i should upgrade my 22inch monitor to like a 60inch one so i notice things better...lol
Ok this is mad, i installed glew which then gave me glut errors so i installed glut and i'm now getting 'cannot open include file CG/cg.h' no such file or directory, am i doing something completely wrong here?
Kill me, Kill me now, i missed the comment about nvidia Cg toolkit install as well and will someone PLEASE make google add an edit button this is so stupid having to make comment after comment because of no edit feature
Maybe gamefix for such games? Or it's to complicated?
not too complicated either way to fix, it's just that people will repeatedly ask why they lost x fps in game y again :D
2d games are pretty fast even on laptops. I have about 600 Fps in Atelier Iris 2 (in first town). So it shouldn't hurt those speed obsessed :D ... Anyway it's up to you to decide. But it would be greatly appreciated if you could make respective option in gsdx dialog.
You can use bugle (aka gldb - free software, recommended) or gDEBugger (free trial) to debug OpenGL call errors.
In addition to that, they allow you to single-step through OpenGL calls and look at all current state, shaders, textures and vertex buffers.
They also support profiling if you install the nVidia or ATI profiling tools.

Revision 1373

xpad: fixed a crash that happened when subclassing an opengl window, also got
rid of mfc.
CallWindowProc knows something that I don't... :P

Revision 1374

Changed some code around in microVU that was causing 10+ minute link times in
Release builds (LTCG mode), also added some new x86Emitter cleanups along the
way. :)
For me, the link time decreased to 5 min, while in r1373 it takes about 10min. Wonder if there's another speedup? ;)
I also noticed that microVU runs a bit slower (also compiles slower) than before (around r1300 I haven't fully tested). GSDx works just well for me. But a revision before could let me run FFXII in ful$l fps while in recent revs about 60% speed.
I wonder if there's something wrong with the code or my compiler? :(
So, the old gsdx link time record was beaten?
gsdx always builds very fast (1 min at all), the nightmare is microVU
one reason I haven't found out which rev caused the slowdown is the really long buildtime
It's a combination of the templates in the microVU and the templates in the emitter that cause the long link times. I'll probably cut back the template use in the emitter soon as well, since the little bit of codegen optimization it provides isn't worth the hassle of the long link times.
(however some of the templates in the emitter have added purpose in the form of compile-time type strictness, so those will remain)
And here i was thinking my PC was just that slow, nice rev :P

Revision 1375

GSdx: moved 16 bit texture processing from gpu to cpu, with the pixel shader it
was either incorrectly done or too slow, please check what got slower/faster or
broken :P
this breaks toa, persona 3 and xenosaga (and probably more games) in dx10hw mode. dx10sw, dx0hw are ok.
Uhm, I just tested xenosaga at least and it was fine.
Did you do a full rebuild? (.fx files got changed).
My findings so far suggest a slight speed drop in some games. Nothing too bad.
I noticed however that in recent revisions the dx10 hw mode gets slower and slower, while the dx9 hw mode gets faster and faster.
Dx9 now oftentimes is faster than dx10 :p
Conclusion: If that change really fixes some issues, it's good :)
toa looks ok, tried persona 4 only, but that too, did you rebuild?
It was a fix for this problem:
And it probably made culdcept nicer at higher resultion too. That's another 16 bpp game. Already grate at the native res though.
Does this fix Atelier Iris' black borders? Can't wait to test it :)
yea, it should
Very Nice
This fixed the thick black borders around charcters' 2d sprites in AT2, too bad the shadows and parts of the sprites have problems similiar to characters' portraits in HW mode, with lines ala tsukihime.
Strangely enough, software mode suffers from a different problems with shadows, makes me wonder if this problem was always there but the thick borders filled those empty spaces.
sw mode
In sw mode I expected something similar to rouge galaxy and dragon quest 8, going to check it later.
Shadows in hw mode are fine with filtering set to auto, I guess it was ment to be point sampled.
okay, there is a typo in the "greater or equal" z test, that fixed the shadows but broke tidus' hair and the chocobo wings...
the problem was that i didnt do a full rebuild >_< sorry
That's interesting; you can move certain processes to the cpu? Would something like offloading the post processing effects like that in GoW2 and ToA be feasible then?
fixes black borders in AT2 thank [email protected]: does AT2 work with pcsx2 rev higher than 1289 for you?I get blackscreen right after booting up
Yeah! Black borders are gone in Atelier Iris. Gabest, thank you so much!

Revision 1376

GSdx: forgot to disable opengl code, glew32.dll isn't needed yet but cannot be
delay loaded
Now CRASH Twinsanity fog problem is gone.. I dont know which rev fixed this exactly, but very good work... I think CRASH the Warth of Cortex fog will too work correctly now, but you've made a special fix for this about a year ago.. can you please disable it ? game CRC=09f49e37

Revision 1377

Minor cleanups to my mVU commit.

Revision 1378

GSdx: just updating the vs2010 project files...

Revision 1379

Fix for Tekken Tag Issue 271
does it fix GT4? :D
lol, thought it was ferrari again... :-P
Ref, thanks
gabest, GT4 is already was working before, at least NTSC)
i think he was trying to wind me up ;)
thanks refraction, now this game is basically perfect.
Dont get me started either :p
After some more testing, it seems like the issue is still present. It still crashes at character select screen, and also random times during battles.

Revision 1380

Modified how the GS interrupts work, solves the issue of the picture flashing on
and off in some games (Street Fighter EX3). Needs some testing possibly, but
should be better.
Developer note: The reason for this is the event can only generate an interrupt
if it is enabled (via CSRw). the CSRw has to also reflect the IMR status else it
could give false readings.

Revision 1381

Nothing to see here, small missed thing :P
Is "Close GS window on Esc" (and renderer switching with F9) broken now? :p
hey refraction, can you take a look at issue 274 , soul calibur 3 doesn't go past the first two intro screens. thanks much
yeh Ref, soul calibur 3 SUcks BEcause of you :P:P:P:P:P:p Please pliz pleaze fix fix fixor etc :) (seriously try to make it work ok someday, its a nice game and its a shame it suffers these days)
shut it both of you, it was that damn game that got me looking in to this ;p
by forcing it to do the "SIGNAL" interrupt (not checking GSIMR) it works, same with soul calibur 2 without its silly time issues.

Revision 1382

Big fixes just for my friend Ferrarinews cos im sick of him
GT4: Loading screen corruption + Freezing ingame fixed
GT3: Freezing ingame fixed
Soul Calibur 3: Now loads again
Soul Calibur 2: Now loads again and should no longer have the Timeout issue.
omg, thanks a lot refraction!!!!!!!!!!!!! :)
Does this fix GT4? :P
GJ Ref
oh boy, I'm not sure this dedication is a good idea ...
then again.. ferrarin's "complaining" is kind of unique and really good at pissing off
Id ban him if googlecode had the facilities available.
yeah one of the two things about google code which I don't understand... the other is .... WTH is the EDIT BUTTON -.-
and why long lines do not wrap! google is a bunch of lazorz.
oh boy can you imagine ferrarin overjoyed with this?
awesome no more time out on soul calibur 2. great thanks.
Wow GT4 now works not only in progressive mode, that means that PAL version is Playable now too, huge thanks ref
will u fix prologue plz
Lol just kidding. Thanks ref. I've been waiting for this :)
The thing that is ironic is that its been 5 hrs and Ferrarinews has not posted yet on this tread.
Does this fix the other well known GT4 bug? :p (the crash when starting races in direct x 9 hardware mode)
I know that ones GSDX related, but you guys have doing gsdx work in addition to the work Gabest`s been doing lately :).
Good work in either case. Great to see games getting the fixes they need to proceed alittle further and better.
Replying to Ferrarinews's post i have now deleted:
you're welcome but please dont post unauthorized links on here, we dont like people getting their builds elsewhere, we prefer you to build it yourself or get it from us (when we release a beta, not by request)
sometimes i miss ferrarinews....
maybe i'm a fan of him/her.....
just kidding...
really great work...
it still has SPS..

Revision 1383

Seems all "Events" are enabled by default, which broke after my recent fix.
Thanks for that Capcom

Revision 1384

GSdx: minor fixes, ar tonelico 2 shadows in sw mode, lamune palette problems in
hw mode

Revision 1385

Jiggled some bits around to make VIF/GIF process slightly quicker (very
insignificant speed change)
Removed GIF Intermittent mode - While this maybe handy on the PS2, it causes us
nothing but problems and extra load. Disabling this fixes NFS Most Wanted Path
3 Masking bugs (This was due to PATH2 doing a transfer half way through a PATH3
Good job, ref!
cheer up!
I am cheered up, that was my last path3 masking bug :p

Revision 1386

Fixed bug in IOP Counters stopping Dead to Rights booting. Ironicly we had
already fixed this bug on the EE side.
you are so crazy
Don't know exactly which rev caused this, but in recent revs, I always get
an error massage box "(EE) Bus Error, addr=0x5031ce60 [store]" everytime I
try to load FFX Int. (Undub), though I never got this error before.
then find out which one it was and log it :P
@bin...maybe you have 'patch' with the codes like codebreaker and gameshark to modify the game....
i mean like make the 'harder mode' or 'max money'...?
i check with Front mission 5 and some of the code make that problem.some problem gone when i change 20xxxxxxx code with 00xxxxxx code.
but i didn't know the problem exactly.
just my experience.
@system.compiler: Yes, thank you, you're right. I disabled the patches and the error is gone. I didn't think that the patches would be the cause because they'd worked fine before. Also, sorry for the bad report :p.

Revision 1387

Added some code to "skip" invalid memory addresses on VIF, the old PCSX2 use to
ignore it, but it doesn't anymore. Fixes Ratatouille
Man, you are unstoppable! xD
Man ur on a role
hey refraction, just wanted to let you know that I think the tekken tag fix revision 1379 didn't work. The game still exhibits the same behavior :(
take a nice break though you deserve it =P

Revision 1388

Major Build System changes:
* Changed w32pthreads library into a DLL so that it can be used from plugins
correctly. (NOTE: you will need to make sure to build and copy w32pthreads.dll
into your pcsx2 folder).
* Switched pcsx2 from static CRT to shared CRT linking (needed to ensure
correct exception handling behavior in multithreaded DLL environments).
* Switched all standard plugins in the Suite to the shared CRT, to match
pcsx2's new style. :)
* Renamed _DEBUG (depreciated) to PCSX2_DEBUG (excluding Gabest projects since
the ATL still uses it).
* Added intrin.h to Pcsx2Defs.h (so that it is included universally), and added
intrin_x86.h for GCC compatibility.
* Current plugin version compatibility status should be unaffected. The new
shared-CRT plugins work fine with older versions of Pcsx2, and the older plugins
should work fine with the new shared-CRT version of pcsx2; so long as the
necessary CRT DLLs are available on the user's system.
* All future packagings of pcsx2 will include w32pthreads.dll and the Common
Runtimes (CRTs).
* Existing users who do not have MSVC installed can obtain the CRTs by
downloading the Microsoft Visual C++ 2008 Redistributable Package (anyone with
msvc installed should already have all they need).
The current link for the CRTs is here, for anyone that has a use for it (anyone reading the googlecode pages here *should* already have them):
... I don't anticipate this transition to be entirely smooth, but it's something of a necessity so we'll have to bear through it. If not now, I was still going to have to switch to shared CRTs when we finish the wxWidgets branch anyway. So since I was DLL'ifying pthreads I figured might as well and make the extra effort to create a safer cross-DLL threading/exception handling environment.
How do I complie padnull, GSnull?
Building and running pcsx2 was no problem here :)
There's an #ifdef _DEBUG still in DSound51.cpp in spu2-x, btw...
hm, is shared crt necessary? the only reason would be when different modules allocate and free eachothers memory.
Not *absolutely* necessary, no. But it ensures correct behavior for w32pthreads.dll when it comes to structured exception handling in threads (which we aren't using much at the moment, but that will likely change when I add more threading options to pcsx2). Additionally, wxWidgets highly recommends using the shared crt also, especially if you want to use wx as a DLL that's referenced from other plugins (which I'd certainly like to leave the possibility open for); again because the gui typically runs on a thread and typically involves some SEH spots.
If you like we can switch GSdx back to the static runtimes. I'm pretty sure there's no harm in it for now. I switched all standard plugins over for sake of consistency but as noted in my commit they currently work fine either way.
it's fine, if other parts will need vc_redist too.
nb this revision broke CDVDolio
as mfc is now used in a shared dll, in cdvd.cpp in CDVDopen() add
yea, going to convert it to native win32 calls anyway
were do i get the w32pthreads.dll i search it on google but nothing
it is built by the same sub project of pcsx2
ah, I can feel you only downloaded a new pcsx2.exe, in that case as who uploaded it to include this dll too
Where is that w32pthreas.dll?

Revision 1389

Linux: Quick fixes to get the Linux build working with the changes in r1388.

Revision 1390

Suppose I should do something about the configure.ac files and _DEBUG, as well.

Revision 1391

Fixed bug which stopped Zone of Enders booting, introduced in r1385

Revision 1392

Fixed small unpacking issue with Shox, hopefully rectified the games which
stopped working in r1289
either this or previous change totaly broke SSX3 (wont start), SSX3 was ingame broken since r1289
I will need a dump of SSX3 to fix it, i dont have the game
should be fixed in 1396

Revision 1393

Added a setup project, main advantage that it can install vc_redist and other
if you switch configuration do a rebuild, since targets from the previous config could be already built with the same name under the bin folder.
one more thing, only setup.exe launches the vc_redist installer, setup.msi won't, don't know why...
In some revision ago I got this error while compiling gsdx.
1>.\GSDeviceOGL.cpp(144) : error C2065: 'CG_DEFERRED_PARAMETER_SETTING' : undeclared identifier
1>.\GSDeviceOGL.cpp(144) : error C3861: 'cgSetParameterSettingMode': identifier not found
Any idea why?
I have my include and lib set in vs(nvidia cg and glew). Or maybe I missed something?
C:\Program Files (x86)\NVIDIA Corporation\Cg\include\Cg\cg_enums.h(105):CG_ENUM_MACRO(CG_DEFERRED_PARAMETER_SETTING, 4133)
Did you set "C:\Program Files (x86)\NVIDIA Corporation\Cg\include" as the include path?
Found the problem. I had an out-dated CG installed
>> one more thing, only setup.exe launches the vc_redist installer, setup.msi won't, don't know why...
Looks like that's intended behavior. According to the MSDN:
"-- Create setup program to install prerequisite components:
Includes the prerequisite components in your application's Setup program (as Setup.exe) so that they will be installed before your application, in order of dependency. By default, this option is selected. If it is not selected, no Setup.exe is created."
So basically the msi would be a viable package for people who already have necessary dependencies, and the exe+msi is needed for people who need dependencies (windows installer 3.1 and CRT in our case).
Cancel that, I think I just figured out how to specify all GSdx SSE build types for the installer. I'll commit soon if it works :)
The problem with exe/msi approac that windows by default hides the file extension. If I tell the average used to run the exe, he won't understand :D
the msi is unusally big, could be the mfc dependencies, once I remove it from my cdvd plugin, it will be smaller, hopefully
Yeah, I agree that having the exe/msi pair is confusing. It should be possible to rename the .msi from setup to something else tho. That's how most of the other "dependency bearing" installers I've seen work. They have a setup.exe and then a handful of things like MyProgram.msi and SomePackage.msi.
Gabest: "If I tell the average used to run the exe, he won't understand :D"
seriously? there are people using this emulator who do not know what an exe(cute) file is? I have a hard time believing this...
thanks to microsoft's "hide extensions for known files" feature as default the average user wouldnt know the difference until told exactly which is what
kabooz: the problem here is that setup.msi and setup.exe look the same without extensions.
I know both filetypes -.- (on this note it was stupid to give them the same look :P)

Revision 1394

MFIFO fixes for Project Altered Beast - Issue 155 , Tekken Tag should be better
now too (second time lucky!)
awesome, will test tekken tag now
Let's get some rest :P
Tekken tag is better now, doesn't crash at character screen but still crashes in fights. I can play longer than before though until one of these crashes happens. There also appears to be errors in the rendering now.
I saw this happen after you won a round, where it was coming out of the characters head. It crashed at that point too. I didn't screen cap it but I screen capped this.
no messages in the console or anything?
oh and tell me if it still does it with mtgs off
No messages appear in the console. When i see those triangle things pop out of characters, no msgs. When its right about to crash, sometimes the game drops to like 1fps, music plays really slow for about a second then pcsx2 crashes.
I also tried it with MTGS off and the same things happen.
Just to note, revision 1329 runs the game perfectly, I havn't had a crash so far in the game.
oops I meant revision 1323

Revision 1395

Removed intermittant mode from GIF MFIFO
I dont know if this helped Tekken Tag, but i just played about 7 stages without a single glitch
alright, i'm testing it
Ok, All looks good, no rendering errors and no more crashes.
If anything comes up, i'll let you know.
thanks ref.
Okay, I've encountered something, the game crashes but only every once in a while now. It happens sometimes at the start of the stage.
This time I am getting console spam with this error
"Vif1 running when CHCR == 30000045"
when this happens the game is frozen.
maybe this will help, but I was using the characters xiaoyu and hwoarang.
the error happens in r1323 as well, but when it happens the game is still playable.
Can you do me a favour, can you get it showing that errror, as soon as it starts streaming (i know it does :P) hit escape, go in to Debug->Logging and tick Vif Log. then Run->Execute and let it stream that a couple more times. then upload your emulog.txt somewhere for me (i recommend 7zipping it)
okay no problem will do that now :)
I'm still trying to get the game to error again but a question,
the debug option only comes up when I get that error? Because I don't see where debug-> logging is >_<.
nevermind, I am building debug version doh.
refraction, slight problem.
When i got the error, and when it starts to stream, i hit escape and put the debug option on, however run->execute just yields a black screen :(.
I will try again.
Success! It takes a few seconds before the game actually crashes when streaming that message. But I logged as much as I could until the moment the game doesn't progress further.
here you go.
thanks :) ill take a look

Revision 1396

Fix for SSX3 not booting. VIF FIFO now clears when not in Reverse mode,
regardless of MSKPATH3
SSX3 working again (including ingame). Thanx!
man, you're unstopable today
With r1397 the intro movie still freeze. Can please HELP. Just this time.
I have 3 friends, that have the same problem, and all of them have different PC's, 1 P4, 2 Core-2-Duo and 1 Quad-Core. Thanks.
Ok, I won't delete your begging right away this time.
Can you please tell my why you cannot just press start and skip the movie?
<gigaherz> maybe he doens't KNOW he can skip it xD
If its that, then yeah. Press start, play game.
ferrarin, you do know you have to enable a patch to get past the intro screen?
Hey smart, even with patch dont pass the intro.
With version 976 that dosen't happend and is not necessary enable patch.
Another thing, with version r1397, when i'm playing the game freeze or jump out. That's another bug.
Well, if I enable the patch.. I don't see a intro movie at all, I just get proceeded with a black screen, but all you have to do then is press CROSS or start or whatever button and it loads.
speaking of which, the game just froze before start of race, console outputted "GIF TIE" , then black screen but game is running, I can hear music drive the car, feel vibrations, but just in the dark.
Hey i didnt say it was perfect :p
btw you can see it if you have your brightness up high enough xD
WTB Edit button

Revision 1397

Improvements to the new installer project:
* installer automatically includes all three SSE build targets for GSdx (each
built target needs to be built manually prior to building the installer).
* Fixed some typos and abbreviated install paths from "PCSX2 Team/PCSX2" to
just "PCSX2".
* Added an "SSEtype" user define to GSdx's property sheets, which is used to
generate the SSE postfix on the DLLs automatically. (ie, GSdx-SSE2.dll, etc).
For what it's worth, installer is still very much a work in progress. We'll probably tweak it quite a bit in the coming days as we explore all the options available to us.
nice I like the nametags

Revision 1398

GSdx: removed the last bit of mfc dependency from cdvdolio
now the installer size is 4 MB + vc_redist, but I had to exclude opengl32.dll because it was auto-added again, the setup project is a bit silly :P
yay, [ProductName] as a start menu folder does not seem to change to "PCSX2"

Revision 1399

Linux: A bit more work on the ruby version of the build script. It now
summarises what built and what didn't at the end, and can be used for building
GSnull and PadNull as well...
I don't have much experience with makefile and automake system, but why not use bash script, or scons ? I saw many program use scons now ( it's Python right ? )
Well, I haven't really approached replacing the actual Makefiles yet. Scons would be a possibility, but, to be honest, I'm not that fond of python.
I wanted to be, actually. The whole white space being important thing drove me off. I could try Rake, which is ruby based, but building pcsx2's pretty complex, and I'm not sure how sophisticated it is.
As far as bash verses ruby, I'm not really comfortable enough in bash to elaborate build.sh to do the things I wanted without constantly referring to reference material.
Ruby, on the other hand, while I've gotten a little rusty in it, is one of these languages I find intuitive and easy to program in. So I was able to throw together pretty fast a script that was a lot more flexable then build.sh.
And it's already making things easier for me, since I can tell it to just compile pcsx2 or one plugin without changing directories...
I use php on windows to build and pack my dlls, everyone should use what he knows better :)
in recent revisions gcc via build.sh and ruby hung at
gcc -DPACKAGE_NAME=\"pcsx2\" -DPACKAGE_TARNAME=\"pcsx2\" -DPACKAGE_VERSION=\"0.9.6\" -DPACKAGE_STRING=\"pcsx2\ 0.9.6\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"pcsx2\" -DVERSION=\"0.9.6\" -DNDEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_NLS=1 -DSVN_REV=\"Revision:\ 1412\" -I. -I.. -I../../common/include -I../IPU -I../CDVD -I../../3rdparty -msse -msse2 -Wno-format -Wno-unused-parameter -Wno-unused-value -fno-strict-aliasing -fno-guess-branch-probability -fno-dse -fno-tree-dse -pipe -O2 -fpermissive -Xlinker -zmuldefs -m32 -MT microVU.o -MD -MP -MF .deps/microVU.Tpo -c -o microVU.o microVU.cpp
checking dependency style of gcc... gcc3
checking for gcc... gcc
checking whether we are using the GNU C++ compiler... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for ranlib... ranlib
checking dependency style of gcc... gcc3
checking gcc version... 4.3.3
cleaned pcsx2 folder .. same results.
If you wait a few minutes, it'll go through; it just takes a long time at that spot.
ok, i will try again now with different versions (release,dev)
nope nothing good "dev","debug","release" eat mem&cpu constantly ....
1000 16441 16440 93 147544 578972 0 00:39 pts/2 00:01:37 /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -quiet -I. -I.. -I../../common/include -I../IPU -I../CDVD -I../../3rdparty -MD microVU.d -MF .deps/microVU.Tpo -MP -MT microVU.o -D_GNU_SOURCE -DPACKAGE_NAME="pcsx2" -DPACKAGE_TARNAME="pcsx2" -DPACKAGE_VERSION="0.9.6" -DPACKAGE_STRING="pcsx2 0.9.6" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE="pcsx2" -DVERSION="0.9.6" -DNDEBUG=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_NLS=1 -DSVN_REV="Revision: 1412" microVU.cpp -D_FORTIFY_SOURCE=2 -quiet -dumpbase microVU.cpp -msse -msse2 -m32 -mtune=generic -auxbase-strip microVU.o -O2 -Wno-format -Wno-unused-parameter -Wno-unused-value -fno-strict-aliasing -fno-guess-branch-probability -fno-dse -fno-tree-dse -fpermissive -fstack-protector -o -
last warning
--28457-- supp: 12 Debian libc6 (2.9.x) stripped dynamic linker
==28457== malloc/free: in use at exit: 3,902,507 bytes in 59,548 blocks.
==28457== malloc/free: 378,134 allocs, 318,586 frees, 160,667,595 bytes allocated.
dammit need good gdb howto and fsck just in case...
Hmmmmm... See what you mean. I was thrown by the fact that you brought the issue up in a revision that I knew was working properly, rather then 1407-1408, where the issue started...
In any case, r1418 ought to take care of it.

Revision 1400

COP0.cpp: Updated the commented out Perf counter code to work on the newer
builds, also removed the line which stopped them updating at all if the
interrupt wasnt on.
Others: Fixed a couple of unpack bugs, tried to tackle an MFIFO bug with Tekken
Tag. Also re-jiggled a few bits on my recent changed, please negative if it
breaks anything.
Tekken Tag is fixed :)
played over 25 rounds and no crashes, no console spam, no glitches.
oh man, this fixed everything including tekken bowling.
using bryan used to crash the game as well, but now it works!
Soul Calibur 3 seems to have problems now, there is random flashing in the menus and in game.
When the flashing occurs in fighting, you can see graphics corruption, and also there are hiccups when fighting too.
Hi a found a speed regression in rule of roses! In r1225 it was fully playable (50-60+ fps) and now I have only 25-47fps with same config, hardware and software is the same even emulator configuration…
And one more thing why cpu load is so random? Now days I have always 100% on one core and about 10-22% on second core (core duo 2450) in official 0.95 cpu usage was better on my laptop
Sorry for my English
This project is fantastic keep up good work
well can you find where it actually slowed down, there has been over 175 commits since r1225! also can anybody else confirm this.
AzNLuCiDX: Definately started here?
The next time you start GT4 do this!
For your information, the game freezes when I play, besides the intro movie. Some people think is very smart.......
@mysie: Speedstep is your problem. It sounds rediculous, I know, but it's true: Recent optimizations to GSdx probably sped it up enough that your CPU no longer sees enough dual core activity to kick into high-speed mode. Yes. Speeding up code can result in major slowdowns on laptops.
Old 0.9.5 versions of pcsx2 had "dummy" busy loops that fooled the cpu into thinking there was a lot of work to be done, and thusly thwarted the aggressive stupidness of Speedstep. This is, however, generally bad coding practice, leads to cpu heating in excess, and slowed the emu down for all of us who have the knowledge and ability to disable stupid Speedstep.
@mysie: also! make sure you have microVU disabled in the CPU options. It's known to be slower than sVU for certain games. That might also be causing slowdowns, and the cpu load imbalances.
@Jake on my laptop (Clevo m660/corrino 609l) speed step is disabled by default because it was pain in...
Without microVU game is defiantly unplayable (20+/- FPS)
Can you revert changes that you mentioned as hack in speed hack section?
And one more thing in past revisions ROR was playable but it was choppy but at full speed it wasn’t so annoying
sounds like you had frame skip on, which hasnt changed. Rama has just confirmed there has been no speed change in RoR, which is why we are saying the problem is at your end
Maybe he was using the old VUSKIP on older version. WHen it worked, it was choppy but faster.
Still missed the feature sometimes...
Ok, so you made it ingame. Now forget about the movie. It has nothing to do with the rest of the game.
Hi Ramapcsx2, you are not obliged to do anything, I want it solved the problem of video input, but now I'm even more worried about the CPU Core1, is always at most. Thanks.
Refraction: not sure, I'll check.
@refraction: yeah pretty sure now this revision broke it, tried 1399 and soul calibur 3 worked fine, with this revision, I get all sorts of graphical anomalies, flashes of white, black, and graphic corruption.
Also, for some reason i have horrible performance with SC3 whereas my brother's computer can play it full speed.
In short, my specs are 3.6GHZ C2D & Geforce 8800GTS, I get 10FPS in fighting with this.
My brother's specs, 4.4GHZ C2D & Ati Radeon 4870, he gets full speed all the time.
Could his better video card and his higher clock justify the 40-50 fps difference. Because it seems like a lot? >_<

Revision 1401

Minor cleanups to the new installer; made it default to packaging Release output
only (will add a custom installer for Devel packaging soon).
nope, still doesn't fix GT4.
look this image if you can http://img200.imageshack.us/i/image2cqx.jpg/
i think its because the game freeze when core1 full. thanks-
looks serious
Eh I probably shouldn't have defaulted everything to Release. I was thinking in terms of consistency, since I have GSdx pointing to release builds. But then I remembered that GSdx only has Release and Debug, so everything else in a Devel build is the same anyway. Oh well, I'll revert it later. Leaving for now, back in a couple days.
I won't touch setup.vdproj, every tiny change turns everything upside down in it :P
Not svn-friendly.
Eh, yea I was noticing that too. It's like the vcproj files but worse (usually when I do cross-branch merges I have to update vcproj files by hand because the merges completely fail).
vs deployment projects simply suck. give it a shot with WiX: http://wix.sourceforge.net/
might be better if you like to create your installer by hand, this one took 10 minutes to throw together and does everything we need...

Revision 1402

GSdx: trying to fix gaps between sprites that may still appear with d3d in
native res
Trying some games, many of mine have that issue.
Btw, is it safe to have "gsvertex.h" included in stdafx.h?
Speeds up compiling a lot :p
anything can be included there which do not change much, but if it does once the whole project is recompiled, so usually it's a place for only 3rd party includes.
The fix was based on this game:
Fixes lots of small issues in Xenosaga :D
<rama1> hmm, that shader file is interesting
<rama1> has a commented out line for some sprite handling
<rama1> put it back in, and it got rid of vertical lines in 2 games :p
The line is "input.p.xy = (input.p.xy + 15) & ~15; // HACK" :)
rounds up every vertex, completly wrong though :P
Well, yeah.
I must add that the lines only appear when upscaling.
I wonder if we should use alternative shaders for upscaled mode (we should! :p ).
it can also break interlaced games, if not the offset has the half pixel shift but the vertices themselves, 50-50 of the interlaced games
Hmm, only thing left is some kinda optional fix then I guess :/
Hacked around a bit, I think adjusting for the upscale amount could fix
some nasty issues like here:
Can't choose this revision in config after copying dll into plugins directory :( ?????????
Wow; definitely relevant to my interests there rama. Might fix the ghost layer on GoW2 as well...
Double thanks, the gaps are gone now on TLS3 even the small ones in the menus, and Moonties works fine now on HW mode.
Amazing, now I remember Growlanser II/III and IV had this same issue (don't remember about V&VI), this fixes those lines on the characters.
http://img200.imageshack.us/img200/7131/gliiir1397nontf.jpg [1397]
http://img150.imageshack.us/img150/9973/gliiir1397.jpg [1397 / Filtering]
http://img221.imageshack.us/img221/8702/gliiir1402.jpg [1402]
vertical lines are displayed now in tekken 5 when using the 1270 x "something" trick.
Use the 1200 x "something" trick then.

Revision 1403

Just changing a couple of logs back i accidently changed during development

Revision 1404

GSdx: ignore this...
dx11 'support' :P
You gave me a real reason to get Windows 7 =D
Same as dx10, no new dx11 features used yet.
It works with the reference rasterizer, takes about half a minute per frame.
But on Win7 it should fall back to DX10 (or whichever DX is supported in hardware, down to 9.0c) and use software rasterization only for DX11-exclusive functions... At least, this is how I understand this WARP thing.
Anyway, GSdx is as always, on the edge of technology :)
Heh, you've said the same thing 2 revisions later :p

Revision 1405

GSdx: another useless revision...

Revision 1406

GSdx: everything should be back to normal now
Nice work, good thing I installed win7 earlier :p
Also, I spent a while trying to adjust the final image when upscaling is used..
Results are pretty ok imo, but I'm sure you can do better ;)
Tell me if you have the time/will to look at the patch please :)
Nice work. I guess we cant use dx11 yet because the video card for it doesn't exits yet. (it crashed the emu if I try to use it in win 7 rc1 with my GTX295)
works here 8600GTS win7 (of course :P)
I only tested Persona 4 NTSC and only for a short time ^^
Strange. maybe its because of the new driver nvidia released today... or I do somehing wrong when I compile.
FForgot to say, I use Ssse3 version. since my processor is not supporting Ssse4 sadly ...
SSE2 only q.q *wishes for intel right now* ~.~
I updated my driver 2 weeks ago ... native win7 driver not the vista one
dx11 has different compatibility levels, it runs in dx10 mode if dx10 is available,
... it even supports dx9, but that just means it can compile and use 2.0 and 3.0 shaders, if the card only supports those.
HUmm verry weird. Ill test a few things here.
Gsdx I compile work in dx9 and dx10 no problem. But if I put it in dx11, the crash happen even before a windows if gsdx appear.
I tried rolling my driver back to win 7 official one. still doesnt work. Even disabled SLI just in case....
Ill wait for someone to compile it and try it since its maybe my .dll thats its wrong.
Thanks for help guys.
Sorry to almost "spam" I just tryed it in another win 7 system with a ATI 3870X2 card and same thing happen... must be the compilation but I dont know whats wrong because it does compile.....ther are quite a few warnings tho..
try the debug build and launch that in the debugger, it will stop in the source where the crash happens.
BTW, wouldnt Direct3D 10-level-9 on Windows 7 help the DX9 hardware a bit? or just the features needed wouldnt work...?
If you mean dx9 hw through dx11 runtime, which is possible, who knows...
The only thing that keeps me removing dx9 renderer from gsdx that dx11 is not available on xp, in "dx9-only mode" I mean.
But once dx11 is officially out, dx10 will go, it won't be needed anymore.
Here is what I got when compiling in debug mode:
1>LINK : fatal error LNK1000: Internal error during IncrBuildImage
1> Version 9.00.21022.08
1> ExceptionCode = C0000005
1> ExceptionFlags = 00000000
1> ExceptionAddress = 0237CCAB
1> NumberParameters = 00000002
1> ExceptionInformation[ 0] = 00000008
1> ExceptionInformation[ 1] = 0237CCAB
1> Eax = 0237CCAB Esp = 0038EF20
1> Ebx = 400084D8 Ebp = 0038EF4C
1> Ecx = 0111D670 Esi = 40871138
1> Edx = 0038EF3C Edi = 0121D6C0
1> Eip = 0237CCAB EFlags = 00010246
1> SegCs = 00000023 SegDs = 0000002B
1> SegSs = 0000002B SegEs = 0000002B
1> SegFs = 00000053 SegGs = 0000002B
1> Dr0 = 00000000 Dr3 = 00000000
1> Dr1 = 00000000 Dr6 = 00000000
1> Dr2 = 00000000 Dr7 = 00000000
1>Build log was saved at "file://c:\Users\Wagnard\Desktop\CODE\pcsx2\plugins\GSdx\Win32\Debug SSE2\BuildLog.htm"
1>GSdx - 1 error(s), 31 warning(s)
P.S Dont know if this matters, Im compiling from a VMWARE system
Oh and in this vmware, I compile from windows 7 RC1 (7100) x64.
Wish there was an edit button.....
k I fixed the debug error by intalling a MS kb for it.
Ill just test the debug file in the debugger now.( i guess you mean pcsx2 compiled in debug mode?)
just gsdx has to be compiled in debug mode.
ok. console in pcsx2 give me a sysliberror Message: <null>
I saw on the forum that we needed the c++ 2008 sp1. But its already in on my windows 7.
Ive installed it just in cased but didnt changed a thing
Ok ive got a gsdx compiled by someone on the internet and its doing the same thing. so I guess its in the code.
Anyway its no big issue because dx10 work.. and dx11 suppossly use the same feature as dx10 for now.
Crashes the window here too, it simply closes but dx10 works just fine.
I used the latest dll compiled in the GSdx thread, ssse3 and sse2 are the same (cant use sse4.1).

Revision 1407

microVU: minor changes

Revision 1408

microVU: more minor changes...

Revision 1409

Fix for Izumo Complete Issue 277 , due to lack of understanding of VIF reset.
Many thanks, this makes the game playable ingame. The intro still freezes, the sounds keeps playing for a few seconds (buffer?) and then just freezes, reminds me to the issues from WA5, however this isn't random is always on the same frame.
I won't reopen the issue, unlike the menu freeze the intro doesn't spawn any console message to know where to look for the crash.
well as long as the game works, im not too fussed about intro videos, the IPU is due a rewrite anyway :)
That's really good news, for the record D/A - Black freezes on the company logo FMV before it actually finishes and it can't be skipped, like Izumo Complete there is no console error, I remember this same problem with some of the Metal Slug games.
there are lots of videos that freeze, unfortunately there is no quick fix in a majority of cases.

Revision 1410

Fixed up Soul Calibur 3 regression in r1400. It was a test bit of code, which is
obviously wrong :P
yeah its fixed thanks!

Revision 1411

Just a couple of unpack changes, some games thought they were overrunning when
they weren't (punisher for one)
Sly 2: Band of Thieves for another...
Well, it breaks FF12. Again. :p
good :p
And star ocean 3 starts with a black screen saying:
UNKNOWN VifCmd: 37
(not good! :p)
well get your arse on irc n give me dumps
And that on my free day.. ;)
check again on my next commit, FFXII as well, i cant see any other bugs which should effect it there.
Oh i forgot to say, the reason for me doing this is because the code these games were picking up is much slower, so by avoiding this incorrect situation the games run much quicker.
Punisher being my example was about 16-18fps before, it is now 28fps

Revision 1412

GSdx: fixes for ffx2 menu
The code that skips depth textures in GSState::IsBadFrame causes the valkyrie profile graphic corruption in the forest scene.
Disabling this and also the "if(!tex) return;" line fixes this somewhat.
This is the bug that plagues a lot of games btw, and there exist a few hacks for other games to avoid it.
Hope there is a way to properly render this thing.
Any info is appreciated :p
it does random things either way
the menu is a lot better now, thx a ton ^^
the only "annoyance" now are the textures, meaning, the depth texture and the weird stretching, but that doesn't even bother much because when using a bigger resolution than native the weird stretching seems to be gone (in hw mode obviously)
so thx again ;)
Gabest, on new revs fog in GoW look's like this
even on DX10
BTW, I've compiled latest revision and noticed strange thing. I launched Devil May Cry 3 and saw a lot of white garbage on screen in DX10 Hardware mode, Everything looked perfect in DX10 Software mode... I started to write a bug-report, but soon I realized that VU Cycle stealing was set to medium... I turned it off and DX10 Hardware mode looked normal again...
The question is: where is the bug?.. VU0/1 Recompilers or GSDX, and why Software mode was perfect with cycle stealing?..
PS: DMC3 looks amazing in DX10: light, blur, shadows and all that stuff...
I thought Valkyrie Profile 2 has status "nothing". Does it actually loads?

Revision 1413

Fixed a really silly typo which possibly broke loads (Including Star Ocean 3,
thanks rama :P) masked it by removing some redundant code too.
Final Fantasy 12 working fine here.
good, last revision apparently broke it ;p
I've been away from the project for about three weeks without checking for an update here...
1>LINK : fatal error LNK1181: cannot open input file 'w32pthreads.lib'
What'd I miss? Are we using VB2010 now or something?
Indead, a new external, all plugins are now almost less than half their previous size, just keep that .dll around.
Zatara213: update ALL of your trunk checkout, including the common folder, then do a clean and complete rebuild

Revision 1414

microVU: minor changes...

Revision 1415

SPU2-X: *Really* fix compat with older versions of pcsx2 this time (0.9.4 and
prior) >_<
I managed to nail the null reference in one spot, but not the other. Bleh.

Revision 1416

R3000air: Maintenance merge against trunk (yea, boooring)
when this branch going to see the sun light, me waiting patiently..

Revision 1417

Added a new function "DevAssert", which is intended to provide assert-like
functionality to Devel builds of Pcsx2. Developers: Check the code comments for
more details.

Revision 1418

Recursive inlining appears to be driving gcc to drink, or at least, to use up
all available system memory trying to compile microVU.cpp and then failing. :(
Yeah I figured that would happen when I saw Cotton switched the mVUcompile to use the __forceinline macro. He was probably just using the macro to keep the code pretty/uniform tho without considering the ramafications of forceinline on recursives, and din't think that I had avoided use of the macro intentionally. >_< (SVC typically doesn't handle __forceinline on recursives very well either -- well, it just ignores it to be exact).
Yeah, it's just usually release and devel builds in gcc are fine with that, and debug builds fail. It's rare that it totally wipes out gcc like this.
If cotton wants it to look uniform, we could always define
#define microVUn(aType) aType
Or get rid of microVUx, microVUt, and microVUf, of course, though I'm not sure he would appriciate that...
i did consider the ramifications of __forceinline, msvc handles it just fine, i was scared GCC would suck at it, but i gave it the benefit of the doubt. seems its even more 'stupid' than i thought; msvc is so elegant, that you can even specify a nested-recursive level for inlining in recursiveness; since msvc can do all that, i figured GCC should at least be smart enough to not inline on the recursive parts...
i specifically wanted to force inline mVUcompile for the blockFetch.
from my testing, not inlining mVUcompile is significantly slower.
(forceinlining was an attempt to bring back speed lost from r1374)
why was dispatcherB changed? that function isn't recursive (although its not really speed critical so it doesn't matter if its inlined or not)
anyways i'll clean this up later.
as i said i wasn't sure if GCC could handle recursive forceinlines or not, so now i know it can't, and i'll keep that in mind.
It claimed both functions were, so I went with it.
And to be honest, if it were inline, instead of forceinline, gcc wouldn't normally have an issue with it being recursive. It's just that with forceinline, gcc throws up its hands because it's being told it has to always inline a function it can't inline.
Of course, in this case, it triggered some sort of weird bug, and *tried* to inline it recursively when not on a debug version, which I find totally bizarre.
And I just tested, and straight "inline" is fine on mVUcompile, even in debug mode on gc. It's forceinline (which is actually attribute(always_inline) in Linux) that has issues with it.
>> i specifically wanted to force inline mVUcompile for the blockFetch.
from my testing, not inlining mVUcompile is significantly slower.
Something there doesn't make sense. Recompiling should not be done very often at all, and when it *is* done, the overhead of the function call should only be like 0.0001% of the typical overhead of actually recompiling a block of VU code.
>> And I just tested, and straight "inline" is fine on mVUcompile, even in debug mode on gc. It's forceinline (which is actually attribute(always_inline) in Linux) that has issues with it.
Unfortunately MSVC will just ignore "inline" on such a large function as mVUreocmpile (actually it always ignored inline, as that is msvc's default behavior when compiling optimized targets).
Same on gcc, actually, as far as using inline goes.
If it comes down to it, we could always do platform-specific __forceinlines. Or break mVUcompile into several functions, and inline the ones that aren't recursive.
And a quick test shows mVUcompile being called around 439 times between hitting "New Game" on KH1, and the movie starting. I could see where every bit of inlining would help...
>> And a quick test shows mVUcompile being called around 439 times between hitting "New Game" on KH1, and the movie starting. I could see where every bit of inlining would help...
Nah, not a big deal. recRecompile of the EE is probably called a couple thousand times during the same gamestate change, and inlining that doesn't do any good (it's all one-time code execution during recompiling, and then once the movie starts playing the recompilers should be called less than 100 times a second).
The bottleneck on mVU is mVUfetchBlock, which is called constantly during the execution of certain programs -- ones that use Register Jumps. For some reason inlining mVUcompile (which isn't called usually, since blocks are cached) helps MSVC better optimize mVUfetchBlock. But really it should be the other way around. Not inlining mVUcompile should result in better codegen. So something's very fishy.
Thnx for fix arcum42 .. sorry for revision i also cheched diffs and stumbled at first upon dispatcherB (found it strange but decide to understand it as complex type messing), #warning "test" cases revealed something at precompiler passes and i dunno what changes caused hung ..
so i run valgrind and start messing with emacs gdb interface (but i'm a newbiew with linux :)). ..
aw.. ^past precompiler passes.
btw for cheating i use scanmem under linux( if anyone interested.)

Revision 1419

SPU2-X: Upgraded license to the LPGLv3; and changed some #ifdef mess to #pragma

Revision 1420

R3000air: Just juggling some code files around and renaming some vars for better

Revision 1421

microVU: fixed a problem introduced in r1304 (fixes bios memcard viewer hanging,
tekken 5, and probably a lot more...)

Revision 1422

microVU: minor changes...

Revision 1423

microVU: fixed a typo that broke Crash Twinsanity :D

Revision 1424

microVU: fixed a bug where xgkick delay info wasn't propagating through blocks
correctly (fixes Sega Classics Collection)
One of your Revisions re-fixed Champions RTA, thanks :)
Compat is kinda awesome now. Quick test with all problematic games shows everything working.
Even so3 battles don't need the hack anymore to look right :)
ico sps fixed in one of the last commits

Revision 1425

GSdx: moved around some code and optimized texture caching a bit, there may be a
slight speed-up in hw mode for those games that use many textures.
Odin Sphere is one of those games ?
Gonna test this out
Indeed Odin Sphere is now faster,with a 12fps increase in a difficult scene, (36fps from 24). It still isn't full speed and the cpu usage is still 99%, but its the fastest it has ever been for me. Playing with SSSE3 builds.
cool news on the speedups. Hopefully the change in GS.cpp will stop some of the "But my PC has SSE3" threads on the forums :)
wow! Onimusha 2 is perfect for the first time in dx10 hardware (probably dx9 too). The main character was disappearing after the intro, now all is good :)
Odin Sphere is indeed way faster now.
From 78 to 105fps in one stressing scene. No more 99% cpu usage there either :)
Hmm, seems like the shadows in Persona games are either missing or not shaded anymore ><
hmmmm will try FFX mihen highroad again
DATE with dx10 seems broken
Ah yeah, in dx9 the shadows are working still :p
Gungrave: Overdose broken in hardware mode, on r1412 all correct.
The Onimusha 2 missing character models bug is gone? Nice. I`d assume it fixes the same bug in the 1st game. Will have to go test.
Not tested Onimusha in pcsx2 since before even playground existed. The missing player models bug was present all the way back then. Another step in a postitive direction if thats been fixed :).
Fixes some slowness in Resident Evil Outbreak NTSC. even in native resolution.
now It give me >60fps in 1600*1600 internal res, using Directx 10 in windows 7 7077 x64.
My PC:
AMD64x2 6400+ & ATI HD 3850, 4Gb Ram DDR2 800 4-4-4-12.
when my ps2 got ruined i thoug i would never play it again.
great work!, you're awesome. :D

Revision 1426

GSdx: small fixes to the last commit
Crash of the titans is kinda broken with these last 2 revisions, dump and instructions here http://www.megaupload.com/?d=DIWISK8S
I have the iso but it does not respond to any input when it says "press start" on the main menu.
Tried with lily and xpad.
lilypad works fine for me, always did(i can press start), you could try the dump ive uploaded, it skips to ingame and youll see the prob.
Now I remember, Q is zero in this game, texture coordinates are messed up, and now the caching too, it should go away once the original problem is fixed.
Hi, gabest, i have one problem, i don't know in how rev is the problem...
But is on dragon ball budokai 3, the colors of characters is white.
if you need a dump, how i do?.
I use speed hacks.
I using dx 10 hw.
Thanks. And sorry for bothering you.
I only need the CRC, if it is tenkaichi.
{0x428113C2, DBZBT3, US, 0},
{0xA422BB13, DBZBT3, EU, 0},
{0x983C53D2, DBZBT3, Unknown, 0},
{0x983C53D3, DBZBT3, Unknown, 0},
the fog in ico is fixed :)
Its not tenkaichi. crc = 2A4B60EB
for the lilypad and xpad not responding issue, try switching to the console window and then back to the output win. they might work fine afterwards.
Thanks for adding Pia Carrot G.P.
Any progress regarding rama's work to fix the positioning of some post processing effects?
Something's up with MGS3 when they talk in the codec, the screen goes green sometimes, and if you exit the window, and try to resume emulation, you just get a black screen; same thing if you switch to software mode.
Same black screen after resume & sw in Soul Calibur 2&3.
same with Wild Arms 5
Choosing the option progressive 480p the game, GT4, seems much more clear.
I can say that also in Dragon ball infinite world the skin of the characters is white and they look like zombies (really funny though). CRC=335A5A1F
but just only the skin, not the clothes

Revision 1427

Many bugfixes and improvements to my SafeArray / SafeList utility classes.

Revision 1428

R3000air: looks like I changed a little bit of everything (WIP - doesn't compile

Revision 1429

microVU: changed VU1's cached program amount from 32 to 64, and vu0's from 32 to
speeds up some games that use a lot of microprograms at once (like ffxii)
XD yay!
I mean, good job! ^^
Thanks +10-15fps in GoW2, just wanna ask what does mean
VU0 perma-stall, breaking execution... MGS3 has tons of this messages in console during gameplay
i think it outputs that when its going to terminate VU0 microprogram execution early.
might be some hack that i should look into later.
are the graphics fine though when it says that?
Graphics in MGS Almost fine but there are some rare SPS almost in intro cutscene, and rarely during gameplay
The main graphical problems i see on mgs3 are some crazy multicolored texture over water, and half the text missing from items when you pick them up and when you look at them in your quick menu. But this happens without microvu, any speedhacks, and with all iterations i've checked of gs. But then again, i only have dx9
do the graphic problems happen when you get the VU perma stall warning?
or is it unrelated?
The problems always happen with the permastall warning, but can't say if they're related or not. Just chiming in with my graphical glitches :P. Btw, I have a small off topic request to have your current save state appear on screen when you use f2/shift+f2. Thanks for microvu, btw cotton. Makes my amd happy
Unrealated, cause in intro cutscene when it happens no VU0 perma-stall messges shows
After checking, autor is definitely right about part of it. It's a reflection texture glitch that happens without the perma stall, you can tell cause its in his shiny mask eye, and its the same as with the water for the rest of the game. The text glitch, which sometimes happens with location subtitles, does not seem to be present however.

Revision 1430

microVU: Evenly distributed rec-cache between programs.

Revision 1431

microVU: minor changes...
BTW from 1429 fps becomes unstable high fps, only if charachter just stands and do nothing, while moving fps is the same like before 1429
Autor: You could at least say what game, i dont fancy guessing between 2500+ games.
i guess he's talking about GoW, because i noticed that too (if you stand still fps is fast, but when you walk it gets slower).
anyways, there's some good news. i found out why mVU is a lot slower than sVU in GoW games.
sVU actually does some clever trick in its program caching that i thought about, but ended up thinking it would be overkill and too messy to implement for mVU.
now i know i'm going to have to implement this, so GoW games (and a few other games) don't suck with mVU.
the good part is that after thinking about it again, its not as complex to implement as i originally thought due to the nice way i designed my rec.
Nice to hear that you find a way, BTW KillZone use the feature of 1429 too, and before 1429 has lower but very stable fps compare to sVU

Revision 1432

Various changes, mainly Gif related cleanup. Fixed SafeArray.h to work with
Linux again while I'm at it...
Hmm might make a few modifications to this, "ClearFIFOStuff(true)" sounds like it should clear the fifo rather than fill it. also the transfer states, 2 was "Ready for Transfer" more than stopped. where 1 was a normal giftag in process and 0 was IMAGE MODE in progress.
Go for it. I was mainly trying to pull code that was used a lot into functions, and get names for states and constants rather then having to remember what they are.
And I think you're probably right on ClearFIFOStuff.
A lot of times I'm going by whatever comments are nearby, too, and can end up misinterpreting them. I wasn't totally sure on the Path3 Modes, in any case, so I was going mainly by the comment currently by the enum...

Revision 1433

GUST fix.
Figured out that this change was the one that broke Gust games. So, no more hitting F1 over and over.
Don't know if adding the return fixed anything, though, so refraction may still need to look at this...
Meh, you best stay clear of these things.
This breaks a ton of other games, most notably Fatal Frame.
If the "Gust fix" only was that easy.. :P
Ok, tested a few triace engine games, and surprisingly they don't die anymore with this on.
So maybe it's preferable to have it this way for now after all.
Suppose I shouldn't have reverted it then. Perhaps we should make it a gamefix?
Hah, just saw you reverted :p
Well, we know about this return making or braking games.
Its one of the ugly spots atm, which I hope will be gone with a new dma controller.
You're right though, a gamefix is likely the best option for now.
Feel like coding one? :)
I could. Probably wouldn't have a checkbox in Windows. :)
Lol, I suppose I can add it then tomorrow :p
Works. I'll commit the actual gamefix and let whoever gets to it first add a checkbox in Windows.
Sort of like how all the the gamefixes have worked, but in reverse...
this fix looks more correct from my limited understanding.
maybe we keep it on until proven it breaks something?
I've coded a gamefix.
Question is what the default should be...
Oh, and what games are broken by not returning, other then Fatal Frame?
doesn't fatal frame break from like every other dma change? xD
i'd probably make the fatal frame way the gamefix, and the gust games the real way.
I'll admit that'd make things easier for me; I've got a lot of Gust games and test with them often...
All right, committed tenatively.

Revision 1434

Revert r1433.
For anyone not following the comments in r1433, I'm going to turn this into a gamefix instead...

Revision 1435

Super VU:
- Implemented setting of GIF status regs for PATH1 transfers at execution time
instead of at recompile time on XGkick instructions.
I don't think this will effect anything since from my understanding we're basically doing:
GIF_STAT = path1_in_progress;
GIF_STAT = path1_finished;
(without anything reading GIF_STAT inbetween)
maybe we should have GIF_STAT_P1Q before if (s_ScheduleXGKICK) instead, not too sure really, it was a bit of a micky mouse emulation, really food for thought for the future, there is bound to be one annoying game that checks when the vu's are transferring via XGKick :P
Also on the XGKick front, does the VU stall while an XGKick is in progress? just wondering if this could explain some of the timing anomolies, if this is the case, it may be worth letting the dummy tag handling work out the size, then delay for the appropriate number of cycles

Revision 1436

The Gust fix is back in. The previous behavior is in as a gamehack for Fatal
Frame, and any other games adversely affected. Checkbox not yet implemented for
Feel free to revise. Hopefully this goes away with future Dma changes.
And I stubbed out the WinMain functions, to make it easy to implement the Windows side...
k, i'll implement the win side when i get the time ;p
Sounds good...
And I meant stubbed out the WinMain code, since I obviously didn't create new functions. Wish I could edit comments.

Revision 1437

Added 2 gamefixes to the Windows Side (untested since I don't have the games
- DMA Execution hack - Fixes Fatal frame problems by ignoring dma transfers
while another one is being executed.
- VU XGkick hack - Fixes Erementar Gerad by delaying XGkick. Similar to what SO3
needs, except this game needs more delay. Emulating this correctly is impossible
with the current DMAC system, and will most-likely never be fixed correctly. The
best (and fastest) way to simulate proper behavior is with a gamefix. (Super VU
was doing this by a CRC hack, but I changed it to use this gamefix instead along
with microVU.)
the xgkick hack needs to be implemented to linux; but the game is jap-only and probably rare so its a very low priority xD
In that it's something I've wanted out of the code for a while, it's somewhat higher priority, as far as I'm concerned... :)
i should mention that i was too lazy to remove the crc code completely with this commit. so the crc detection thing is still there but dead.
(i think there was a lot of other dead stuff there too)
I noticed, but I yanked most of the rest of the crc code out in r1438, when doing the Linux side. I was already pretty familiar with the code location, since I'd previously gotten rid of various obsolete crc hacks... ^_^
(a little scary considering the creator of Erementar Gerad made the Star Ocean 2 comic adaptation, not SO3 one though)
The characters' textures are now correct with the hack enabled:
http://img191.imageshack.us/img191/5681/00mvu.jpg [No Hack]
http://img218.imageshack.us/img218/8082/01mvu.jpg [No Hack]
http://img235.imageshack.us/img235/3940/00mvuxgkickhack.jpg [EG Hack]
http://img235.imageshack.us/img235/405/01mvuxgkickhack.jpg [EG Hack]
heh interesting.
thanks for the pics, i was curious on how this problem looked (and i couldn't test since i didn't have the game)
Just wondering, is this the same type of effect that plagued the character textures in Megaman X Command Mission?
If you mean the black triangles, it seems different, the comment on the code says it corrects color on certain graphics (I said texture as a generic term, on EG textures are there regardless). Though I don't have that issue:
http://img268.imageshack.us/img268/2724/mxcm.jpg [ rev 1437 ]
http://img2.imageshack.us/i/mega1v.jpg/ [ rev ???? ]
i never knew about the MXCM problem.
anyways, its possible the XGkick gamefix will fix some other games.
so give it a shot if a game has garbage graphics.

Revision 1438

Brought the Erementar Gerad gamefix over to Linux, and got rid of some junk that
isn't neccesary now that the crc version of the hack is gone.
was that the last of pcsx2's hardcoded crc-based hacks?
Most of the others were rendered obsolete previously. For a while the hacks had been there, but the code that implemented them had been redone so they weren't neccessary. Then I yanked hakcs, leaving this one and FFX.
Now both of those are done for, so the code can "softly and suddenly vanish away".
-yanked the hacks-
Steambot Chronicles got a huge speed improvement - however the vertical glitches are still there. But thumbs up - good job. From 5 fps in Hardware mode to 30 fps.
Tekke4 is not working.. not that I care but just to report :")
PCSX2 r1438: GSDX r1439, SPU-X r1419 and Linuz ISO r1390 -> emulator is giving me and error, can't start.
PCSX2 r1385: same plugins -> emulator won't load this plugins.
Unfortunately I'm not compiling, only downloading builds from re4rainbow.
@ Mr. Henky1 - you need w32pthreads.dll
I have it.

Revision 1439

GSdx: changed a lot of things, expect new bugs :P
odin sphere should be fast now
Bloom in native in Shadow of the Collosus fixed
Fast indeed; second cut scene of Valkyrie (first campaign of odin sphere) received a huge speed up in my testing so far.
But shadows now all black it's maybe right, but looks wierd
MGS3 now's broken in this way
I've seen that error, ... did you rebuild or recompiled the .rc?
Sorry that was my bad, but bloom in SoTC is back after rebuilding
Thanks for adding Kazoku Keikaku.
Odin Sphere seems to be slower to me compared to the previous revision at least on Dx9:
http://img268.imageshack.us/img268/8493/gsdx1426.jpg [1426 / 23 FPS]
http://img150.imageshack.us/img150/6231/gsdx1439.jpg [1439 / 14 FPS]
http://img268.imageshack.us/img268/5989/zerogs0971.jpg [ZeroGS / 60+ FPS]
that's odd, dx9 crawls here too, though it has become faster as in dx10 the last time I tested it
odin sphere its a lot faster: from 45fps to 64fps in one scene in dx10hw, but in dx9hw i dont see any difference
Microsoft will stopped supporting XP soon.
Then why must we support DX9
managed textures of dx9 don't seem to like many small updates, even if the sum of the updates are now much less than before, dx9 never had any good way to update textures...
Oh, I wish I could minus it twice...
First of all ATI problem is back.
Second, this commit broke Jak and Daxter games. Emulator just close without any errors at language select screen in Jak3. In Jak and Daxter it crashes, that's why I uploaded the dump http://www.sendspace.com/file/k1qayt
@ntcong.it: Mainstream support for XP 32 has already been dropped, however the extended support goes until 2014, there's XP64 and server 2003 too which get mainstream support until mid of 2010. Take in count too not everybody has a DX10 card and even if XP support was out vista and windows seven have directX 9 capacity as well.
Broke on my ATI. -1
Same here, emulator closes as soon as I enter on any 3D battle on MAR Heaven: Arm Fight Dream (sometimes giving a "read" error). Doesn't happen with 1426, likely other games are also affected.
The speed in odin sphere is welcome, however other slow games became even slower, wild arms 3 goes from 50 to 40fps in the slow scenes for me now and valkyria profile 2 seems to have gone from 30fps to 10fps in the beginning point where you cna move your character.
This is compared to r1426.
Also alot of people hate Vista with a passion ntcong since it does alot of things very differently to all the previous windows versions before it. So dropping XP support entirely would be cutting your nose off to spite your face so to speak, since more people use XP by far than those that use Vista. And that in essence would mean that pcsx2 in that one move would lose around 60% of its userbase give or take.
SO3 speed drop to 10-30 fps. Normally 60-80 fps.
your comment is useless.
at least mention the games you tried, and how they breaks.
Ok have to add a negative to this one after a bit of testing. On my tests of this new version GT4 is now completely unplayable. Causes the emulator to quit to desktop without any error messages at all. The quit to desktop occurs completely at random. On one test it quit when I went to select a car, on second test it occured as I went to start a race etc. Running in dx9 mode with no speed hacks enabled.
Pcsx2 displays the Playstation 2 logo und then crashes.
Im using DX9 HW 'Native' on XP64.
Well done, i wish i could minus it twice too :(
Lol, calm down down dozafix1992.
This is new code, give Gabest some time to fix it.
Nothing much fixed by this, out of my tests.
Odin Sphere now goes to 110fps, was 90 or so before.
All the other games suffer a lot though. From half speed to -25%.
Ah, the timesplitters blurring bug is gone :p
Worked fine in the previous version I`ll add. Minus the usual stuff.
Talking about this old bug. Couldn't even hackfix it :p
I think thats the same bug of Ace combat 4.
dozafix1992: that's bool shit, i tried start game with PS2 bios and it worked
This rev slows textures of MGS3 back down
tales of abyss crash with this new changes
toa only crashes in dx9hw, not in dx10hw
No crashes, works fine here :P
wow already working on dx11...
Is opengl already rendering? or is just a early wip?
Playing "Dragon Quest 8" PAL :
starting from this rev up to newest rev at this time (r1472), garbage display is shown as flickering during "Loading screen" (like screenshots of what was displayed moments before, but always the same screen).
Graphic card is an ATI 4870, using DX9 or DX10 under Vista 64bits.
.gs file taken less than one second maximum after the garbage is shown is available here : http://www.sendspace.com/file/wlu8l2. Althoug I don't know if it will help or not.
Thank you and have a nice day.

Revision 1440

GSdx: fixed a crashing in the previous revision, dx9 slowdown problems will be
addressed later
Last commits affected games with weird shadows. Bug in Shadow of the Colossus have been reported and I just want to add a few games. Shadows in Jak games disappeared in HW-mode, but they look as bad as they were before in software. Actually it looks better this way but anyway... Just for the record.
One question, I use Vista X64, is best to install "Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)" or "(x64)".
pcsx2 and the plugins use the x86 dlls
toa crashes fixed
shadow of colossus have corrupted shadow, but others games like toa and persona 3 have corrupted graphics too (only in dx9hw)
Aren't that just the old "enable log z" bugs? :p
yeah, thats it, i didnt know as i almost always play in dx10 :S
that tricks me too sometimes

Revision 1441

Worked on straightening up Plugins.cpp a bit.

Revision 1442

GSdx: dx9 texture uploads should be at least as fast as before
I wonder if 10level9 has an accelerated (dma) CopyResource/CopySubresourceRegion for dx9.
That would be lot better than updating managed textures, and probably as good as dx10 now.
Just there is no dx11 on xp, only people with vista or better and a dx9-only card could take advantage of it.
That sounds like me :D
this makes odin sphere faster in dx9, from 47fps in r1440 to 58fps now.
still not as fast as dx10 (82fps)
Random crashes in GT4 fixed.
Uhm, am I the only one where dx10 mode is really nerfed now? :p
Stuff like Xenosga2 or Persona4 or ff12 are -20%, some tales game is -60%
and tri-ace engine games are about -80%..
I tried a few games and here what I noticed
1. Sun shining through objects in GoW2
2. Ratchet and Clank is completely broken now. Picture just freezes.
3. Ratchet and Clank Size Matters works again in hardware but background and palette look really weird.
Plugin is still slower on ATI than it was before. Pressing F9 or Esc->Execute several times also makes games crawl.
DX10 too need to be fixed, it's slower since 1439
just tested xenosaga 2, p4, ff12, toa and star ocean 3
Xenosaga 2 its a little slower (only tested dx10) and im cpu capped in p4, ff12 and toa so i dont see any differences.
Star ocean 3 (tri-ace) is A LOT slower, from 20fps to 8-9fps in dx10 and dx9 between revision 1426 and 1439, and this revision didn't fix so3 performance in dx9.
what do you mean?
DX10 is slower for you in those games? but 80% slower, thats massive.
I think I read somewhere D3D 10-level-9 will be available only on win7 because of the new features on 7 so wont be on vista but I cant find where I read that so I cant be sure now...
I'm using gsreplays to test, so pcsx2 has no influence on it.
And 80% means a drop from 40 to 10fps.. roughly.. :p
Pilot name screen on AC Ninebreaker seems faster with these changes compared to 1426:
http://img198.imageshack.us/img198/7886/acninebreakergsdx1426.jpg [ 1426 / 38 FPS ]
http://img29.imageshack.us/img29/552/acninebreakergsdx1442.jpg [ 1442 / 55 FPS ]
Probabily applies to other AC games, I remember that screen being quite slow in comparison to the rest of the game (I might check later Wild Arms 3 and Breath of Fire V).
neferite, all directx11 features including Directx10 and directx10-level-9 will be available for vista too, that is basically SURE.
someone posted this
not sure if its a typo or if it was intentional.
xbyak isn't my creation, but that piece of code isn't used in gsdx.
ok, I need SO3 CRCs
There's 3 games with that engine, they all suffer from that slowdown (In case you wanted to crc fix those :p ).
Here's some CRCs we collected once:
Star Ocean 3, SLUS_204.88, CRC = 23A97857
Radiata Stories, SLUS_212.62, CRC = 47B9B2FD
Valkyrie Profile 2,SLUS_214.52,CRC = CC96CE93
Valkyrie Profile 2 PAL SLES_546.44 CRC = 04CCB600
SO3 uses the frame buffer alpha through a palette to self-modify it a lot of times, that re-creates a texture from it each time, I'm just going to remove that part, but it won't fix those other games.

Revision 1443

- Smarter microProgram comparison. Games will now use less microProgram 'slots'.
Speedup in games using a lot of microPrograms at once...
Still less speed in moving, bt +1 for effort
Dunno what you're testing, Autor.., but this speeds up the stuff its supposed to.
FF12 now uses less program slots, recompiles less and runs faster :)
One problem though:
It bugs dragon quest 8 ><
I'll have time to help again from thursday on. :p
it bugs dragon quest 8? ><
damn, it shouldn't break anything, guess there's some bug somewhere.
Right, I'll drop by irc a sec and give you a dump.

Revision 1444

microVU: fixed some problems from my last revision. (fixes problems in DQ8)
Nice :)
Very nice))

Revision 1445

microVU: Tweaked some stuff from my last commit.

Revision 1446

Fix for Tekken 4 black screen hang, removed some code which doesn't seem to be
needed for Art of Fighting anymore, however this game has another problem which
seems GS related.

Revision 1447

GSdx: couple of fixes
Tested the dx10 mode a bit, and it seems faster again :)
SO3 also runs nice and fast now.
For dx9, the shadows in shadow of the colossus work again.
There's just one new problem with dragon quest 8, which I think is a bug we've had once before already:
yay :P
i can confirm this buy with DQ on my machine with DX10, using Radeon 4890, also there's a bug in FFXII which causes the screen to flicker ... or shake, from time to time, hard to describe, thanks for the update :)
Shadows in castlevania still broken ;(
Nice work, tested a few games and everything in dx10 its a bit faster now (but some of them not as fast as in r1426)
SO3: 1426-> 26fps || 1442 -> 6-8fps || 1447 -> 62fps!!
Xenosaga 2: 1426-> 55fps || 1442 -> 43fps || 1447 -> 48fps
Valyrie Profile 2: 1426-> 26fps || 1442 -> 6-8fps || 1447 -> 13fps
I don't have vp2, need a .gs to see why.
xs2 uses so many textures that it cannot run on my 256mb card :P
.gs -> http://www.megaupload.com/?d=UOE1YLCJ
and if you feel like looking at it, there and old issue where the lower part of the screen its not showing in non native resolution
Thanks for adding Duel Savior Destiny.
vp2 does the same thing as so3
Lol, toldya :p
And radiata stories as well. Although far less annoying.
I can fix this issue with a hack, but I'm still missing the whole picture for a real fix.
GSdx's source is hard to understand :p
Great! SO3 is obviously faster than before :)

Revision 1448

GSdx: dq8 fix
This revision breaks a game I play graphically, it makes it too bright and textures are missing.

Revision 1449

PCSX2: Clean up on docs,nothing important.
Note from the PCSX2 Team: After getting spammed for months in our Google code
comments by a user named 'ferrarinews' and due to our inability to ban this
member,we have decided to NOT make any changes to the emulator that will affect
positively Gran Turismo 3 or 4 for which the user is spamming us,until he stops.
Sorry to everyone else,blame him for this.
one word: LOL!!!
ok 3 words -_-
I aprove this even tho no one knows who i am.
noooooooooo, was looking forward to GT4 being perfect one day, its quite obvious to the team that there are problems with it, so ferrarinews no need to spam and keeping telling them, that just gets annoying.
the sad thing is i doubt this'll stop the douchebag, but i understand it and hope it works
I wanted to apologize, but this was a way to get "revenge", of certain persons of the forum that banned me, i deal with them later. I will not post anymore, and GOOD WORK.
i hope you stay true to this promise...
Revenge? You got banned from the forum for spamming (guess about which game) and now you are spamming here. This has nothing to do with revenge and everything to do with you spamming.
I know where he lives...
+21 zomg
Meh dammit. Any chance of getting that GT4 crash bug just went out the window.
Ah well plenty of other games to play in the meantime.
ferrarinews: People get banned for a reason. If you`d read the rules in the first place you`d not have get banned. So get over it or bugger off if you cant.
why not introduce some bugged code only for his games?
:D that would be nicer !!!
Fantastic commit!!
The most possitive commit ?
That show how many people hate him, lol
nope I don't hate him, how could I? I don't know him -.-
but I do hate the way he acts here and I think nobody should act like that and if he's like that too @ home then I pity his family cause they have to put up with tis -.-
also and ultimately there is nothing wrong with standing up for things you like (pcsx2) or for people that create what you like xD
The most positive commit was about 42-45+
I feel left out now! adding to the positives for the well deserved ferrarinews slander :D
no GT4 OS then? :(
Anyone noticed that we can't see all the list of Positive user ? Another Google's bug
I can see them all, 37 now, counted it.
The commit author's box in the left side is auto scrolling, so I can't see them all.
Or do you use an old browser :P
no, I have a large monitor :D
I was curious to see what incredible change could have such a positive rating. And all I can say is..
I dont know who is VctrBarbieri but why he is the only one put -1..
maybe because he doesn't like to be punished for others^^ or he likes the GT series very much ... either way it's his choice so you should not care about what he votes xD
ah lastly it could be about the changes ^^ (but I guess he would've written something if it's about that)
I`m a definate lover of the GT games (especially GT3) but I can live without I guess. Can play em on the ps2 for now. No positive or negative from me as I can understand the reasons for choosing not to remedy it. Shame it cant get alittle love since the main things wrong with it (for me anyway) is the start game crash in dx9 HW mode + a freeze that occurs in every mode + gfx plugin I`ve tried when you crash into a wall and sometimes just randomly even when you dont crash into one.
Either way as the emulator continues to improve from strength to strength I`m sure a change or 2 in the future will indirectly fix some of the issues.
^ Actually it's not like they chose not to fix it if the first place,
they couldn't fix it properly.. infact if you read previous commits refraction
tried to fix it and succeeded to some extent, solely for ferrarinew..
I meant "in the first place" dammit why there is no edit..
I think they CAN fix it, but they will not hard-fixing any game, unless the fix the a emulator problem. Hard-fixing a game may break hundreds of other game...
I do not know what is about but there is a negative post (-1),
let me guess, it is ferrarinews's post.
+1 for free ...
59 :p
Comment by [email protected], Today (8 hours ago)
I do not know what is about but there is a negative post (-1),
let me guess, it is ferrarinews's post.
Believe it or not, it isn't. He used neutral.
Comment by gigaherz, Today (14 hours ago)
Believe it or not, it isn't. He used neutral.
Sorry ferrarinews ...
What a load of shit. Adults with a fucking child's mind. If you don't want to be bored close the fucking project.

Revision 1450

GSdx: the valkyrie profile 2 fix
Valkyrie Profile 2 running better than it ever did even with the 0.1.7 version, thank you :P
now vp2 its a lot faster,
Also i built a version of gsdx to make radiata stories (i think is the last of tri-ace games in ps2) use de vp2/so3 fix, and in some scenes the performance improves dramatically.
gs dump -> http://www.megaupload.com/?d=ODFT5A1I
yea, same thing
Hey, gabest, if you don't mind - can you take a look at Issue 282 ? I tested every version of GSdx (from the first ones) and issue still here.
yeah, yeah, I know, I already asked about it :P
odd the same problem with shadows had the PC version of Grandia 2 on my pc XD
Lol, mine Grandia 2 works fine here >_>
But it is definitely gsdx HW problem, coz everything fine on SW.
Castlevania is like SoC, color output needs to wrap around, but d3d can only clamp.
So, it is just not so easy or impossible?
impossible, I could only remove it
Can you post hack here?
Don't know if Issue 162 was greatly improved in this rev or earlier ones of GSDX. But the fps goes from <15 to >40 now. Keep up the good work!
Please alter the fix to also support the JP version of VP2 (CRC 774DE8E2)
JP version runs like @#[email protected] with 1450 gsdx.
We're trying to work something out to make the shadows work :p
Drop by our irc channel sometime?
if you want to remove the shadow completly, filter out 1 drawing step for TBP0 == 0x3180 && TPSM == 10
Checking the env.COLCLAMP.CLAMP bit, and skiping the draw() depending on if its set or not also works :p
Sorry for the question: where is the fix? The game is the same for me. The same squares and glitches and the same frame rate in the begining. I am using all defaults with the GSDX 1450 supposedly VP2 fix... with DX10 mode.. or I am not doint anything right?
if you are using the pal version, you should ask gabest to add its crc in the code, or gsdx wont detect your game
i think its 04CCB600 -> http://forums.pcsx2.net/thread-5334-post-34748.html#pid34748
oh that's a good list of CRCs
Hi, Gabest... umm please add the PAL version CRC for Valkyrie Profile Silmeria
is this a sofware mode only fix?
Ask on the forums.

Revision 1451

GSdx: added a few CRCs
just one minor thing, those crc for vp2 and radiata stories are the jpundub versions.
the crc doesn't change when you patch the US version to undub...
I'm not sure if this is the place to put this, but after a bit of testing I've found where this bug originated. r1426 broke things in Shin Megami Tensei: Nocturne. You can now see things (textures?) through walls. As of r1451 its still broken. Here's a screenshot: http://bayimg.com/bablCaACp
forgot to add... This happens no matter what dx mode you are using. I've tested 9, 10, and 11.
I wonder how did you've managed to test it with DirectX 11... =/
dx11 should run with shader model 4.0, maybe it needs the sdk to not crash, I'm not sure why it does for some people.
could you make a .gs then? in sw mode preferably, it captures a bit more.
Sorry for not including a .gs in my previous report. I'm pretty new at this and didn't even know what that was until I looked it up. Anyway! I took two snapshots. One in hardware mode and one in software mode. The bug does not seem to occure in software mode. As a side note, software mode kept freezing pcsx2 on me when trying to use 4 threads on my Q6600. I dropped it down to 1 for the snap. Also, apparently shadows are pretty messed up too, although the main character's shadow now seems to display correctly (it had clipping issues with the MC before).
Hardware mode (dx11): http://rapidshare.com/files/251466137/snaphardware.rar.html
Sofwaremode (dx11): http://rapidshare.com/files/251467181/snapsoftware.rar.html
I hope this helps!
pcsx2 needs one thread, 3 is the max on a quad.
d'oh! I figured the thread issue was something like that, but no one uses software mode so I didn't care enough to really test into it. Thanks for letting me know.
Well, this is going to be difficult to fix.
First the z buffer is read back to pcsx2, then it draws the character shadow, then it reuploads the old z buffer to the same place.
Depth buffers can only be read with dx10, and writing would be tricky too, not to mention the loss of extra resolution.
Before it worked more or less because writing did not trigger a clear and the old buffer + the remains of the shadow drawing was just good enough.

Revision 1452

Fix for plugin console logging via stdout/stderr, which stopped working when we
switched to the shared msvcrt dlls.
mVU: Quick fix to zero out some memory/pointers; fixes assertion failures when
running debug mode builds.

Revision 1453

microVU: Work in Progress commit, just committing to have a backup!
- Added Simple Constant Propagation to detect Constant Indirect Jump addresses
allowing them to act as normal branches. (speedup)
- Added a Pipeline State optimization to remove some unnecessary information.
- Severely altered mVU's memory model to dynamically allocate memory based on
how much VU programs are run (and free them when dead).
- Made microPrograms recompile to a global rec-cache instead of per-program
- Raised VU1's microprogram slots from 64 to 400.
- Fixed some memleaks that were causing ram usage to increase over time.
- W.I.P. GoW speed hack (not yet in gui)
note: I know GoW is slower in this revision, still working on that.
The reason is that GoW games recompile ALOT, so recompilation speed matters (whereas in other games it doesn't).
The GoW speedhack i mentioned basically removes some optimizations in recompilation, to speedup recompilation time.
So only GoW games will benefit from the speedhack (all other games will slowdown instead)
Anyways I'll continue working on this...
Damn, superb job, huge commit! :D
Amazing job!:P

Revision 1454

wxgui branch: Maintenance merge against trunk, plus many cleanups and project-
level changes.
* Moved the x86 emitter to /common, so that plugins can link against it if they
* Created a new "utility" class in /common which houses string utils, fast
memcpy, common exception classes, and other handy dandies.
* Removed old-style linux automake files from the pcsx2 dir since they were
hopelessly out of date (and their multi-file-per-line format makes svn merging
impossible >_<)
Note to Arcum: Do not touch! (yet) I'll hit it up from my linux install tonight and do more cleanups. I'm probably going to end up moving several more files around there as well.
There are plenty of other things I can fiddle with for the moment...
o.O, i thought you forgot this branch :P
The last time I compile this, the GUI is not complete yet
well, he is working @ new IOP too, which is much important.
i know i should be asking this here but bare with me a little, i'm just curios :P
could anyone explain in few words what exactly is wxGUI?
a quick search revealed it has something to do with how linux handles GUIs? am i wrong? if i'm not is there any benefit for windows users?
i meant: "shouldn't"
not edit button pisses me off -_-
Afaik, currently Windows side of Pcsx2 is using MFC, and Linux side is using gtk, which made the developing process take longer, and maybe it has some problem that I don't know.
wxGui is a new gui write with WxWidget, a set of API for writing GUI application. It's ( and it should be ) easy to use, cross-platform and many other advantages.

Revision 1455

A couple minor compiler warning fixes.
Ummm may I ask to test Steambot Chronicles, it still has that weird vertical yellow and blue lines and runs at 20-30 fps (used to be 3-8 fps before and now is much more faster). I used software GSDX and no problems there - 30 fps but no graphical issues. Thanx for the great job, btw.
Mortal Kombat Shaolin Monks off the first demo was loading the last
vtlbDefaultPhyRead32: 0x1E5EB2ED
vtlbDefaultPhyRead64: 0x2CF478
vtlbDefaultPhyRead128: 0x2CF478
vtlbDefaultPhyWrite8: 0x2CF478
vtlbDefaultPhyWrite16: 0x2CF478
vtlbDefaultPhyWrite32: 0x2CF478
vtlbDefaultPhyWrite64: 0x2CF478
vtlbDefaultPhyWrite128: 0x2CF478
(EE) Tlb Miss, addr=0x162 [load]
(EE) PC: 0x002da814 Cycle: 0xbd8c69e1
these wierd vertical lines are in radiata stories too Oo
but they are not that evil I mean not sims evil just manhunt evil OO
None of these comments have anything to do with this commit, these are COMPILER warnings, in no way shape or form will this effect any games or change any errors games give out.

Revision 1456

Changed some stuff around with register freezes and mutex locks in the MTGS to
make it thread-safe for concurrent threads sending packets to the GS. (packet
locking is currently commented out since it's not actually needed yet)
Shaolin Monks still dont work :/
majstersztyck (wow that name is hard to ... read/speak/write Oo) :
I'm hoping you CAN read and you just chose not to ...
1. the last commit you commented was the one before.... and about the same game...
2. BOTH commits have neither to do with the game nor break anything (in fact I believe they do nothing ,yet XD)
3. please refrain from: 1. going on about one game!!! 2. complaining about bugs that weren't caused by the same revision you commented on. and lastly being reproachfull that you bug hasn't been fixed yet..... you exhibit the same behaviour ferrarinews has....
I really HOPE you CAN read... otherwise this was pretty pointless <.<
move over ferrarinews, there's a new pain in the ass in town.
I've just thinking the same, a new GT game is born, Shaolin Monks = GT5 =)
majstersztyck: Just make an issue in the issues section with as much useful information as possible and they'll get onto when they can.
In case it hasn't been pointed out enough already - don't comment about bugs/issues on these commits unless it is related to the commit in question.
This isn't a QQ forum, do that elsewhere.
can't you guys make only the team to be able to comment on this stuff?
In the dolphin google code its seens that is impossible to me to comment on a rev
Yes, we can. But, we do not want to. There's also useful comments posted in here from time to time. So, we shall endure until googlecode lets us selectively ban people who comment in here.
Most comments are either useful, or harmless anyway, so...

Revision 1457

WIP: Zeropad fork. This is intended more as a backup copy so I have a good copy
to work from then as a release. As such, while it works, the gui is glitchy, the
Windows port is non-existant, and a lot of things are subject to change...
Including, in fact, the name, and the widget set the gui uses.
That's hard to sync the GUI process between Linux and Windows.
Hope the wxGui will be release soon
I could theoretically make this plugin use wxWidgets without the wxGui version being out, and that actually is my ultimate intention.
I ended up deciding that it'd be easier if I did a bunch of the backend changes first, and changed the gtk dialog to approximately what I want the wx dialog to look like.
This basically's letting me ease things over, because I'm also changing the dialog box from Zeropad style to something closer to a simplified version of Lilypads dialog box...
GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu)
there is too many syntax error is sh build scripts...
>>This basically's letting me ease things over, because I'm also changing the dialog box from Zeropad style to something closer to a simplified version of Lilypads dialog box...
Yes, Lilypads' dialog is ways complicated, it should be cleaner and easier to use. And I think the configuration dialog should have an image of a Ps2 pad
we doesn't need a Windows port, do we?
i think we have enough working pad plugins.
Admittedly, a Windows port isn't the highest priority. Once it's using wxwidgets, I don't really see a reason not to port it, either, though. I might reconsider if it becomes too much of a pain.
In any case, that's a ways away. I still have plenty of other stuff I need to work on on this. The dialog is flaky, and there are several things I want to redo on the back end...
@ntcong.it: Yeah, this is mainly Lilypad style in that it now has a list of keymaps on the left, instead of having text boxes below each button. Which means that I'll be able to set it to map more then two keys per pad, once I change things on the backend to allow that...

Revision 1458

microVU: fixed a bug in program comparison algorithm.

Revision 1459

wxGui branch: [linux] Updated projects, added Utilities and x86emitter

Revision 1460

wxgui: Moved some more files around in Common/Utilities, and merged against
I'm quickly reaching the point of no return on the wx branch. A few of the files I moved in an earlier commit didn't retain the history links, so merges are having to be done by hand on some things. That could become a lot of work in a hurry.
But on the other hand I'm dangerously close to getting wx in a position where it can enumerate plugins, and then from there it's time to run games. ;)
Note also, with this revision the wx branch compiles and runs in windows and Linux (linux using codeblocks).

Revision 1461

wxGui branch: [linux] Fixes for previous commits; one of my project files hadn't
been saved properly before committing >_<

Revision 1462

GSdx: Fixed crash when minimizing GS window and alt-tabbing out of fullscreen.
Omg, really?
Checking this out :p
Ok, I'm partly wrong. Fullscreen alt-tabbing is still broken with this fix. I'm checking it out.
Great, this works just fine. Guess I can change some stuff now :p
The alt-tab form fullscreen breakage appears to be DX9-specific, and looks like it's none too easy to fix, since it results in all backbuffer and texture handles being NULL.
Ok, I fixed out the NULL texture references without much trouble, but DX9 still fails to properly recover from an alt-tab. Screen just goes black and nothing updates. Feal87 will look into it further.
Even having the minimising crash fixed is huge news. Great work :). Thats been a VERY OLD bug in gsdx.
Agree, I've lost count on how many times I've lost game progress because of it ;_;

Revision 1463

GSdx: small optimizations and tried to fix that dx9 fullscreen alt+tab crash
sorry gabest,this is not relate to the revision,but since rev1310(log:mfc-free)
I got the error message like "Application Error. The memory cannot be read ", every time "MTGS > Closing GS thread..." appear,
no matter what's me settings are.
you might want to look into this if you have time,thx.
Gabest can you take a look at the ESC + Execute functionality of gsdx?
Because from what i've tested it is leaking memory (It does not properly dispose devices/textures/surfaces/D3DObjects (while pixelshaders and vertexshaders are correctly disposed)) and it crashes in fullscreen mode because of the leak of the device (you can't create 2 devices that contends over the fullscreen exclusive lock)
To test for memory leaks easily, you can also use F9 (switches soft/hard rendering on the fly). Each press of F9 will leak memory.
Ok looks like I found the main memory leak source -- m_pool isn't being emptied properly on closure. Furthermore when you do free it you need to make sure it gets freed *before* the CComPtr's for the DX devices or else the reference counters will prevent them from releasing. (in other words it needs to be done from the context of GSDevice9/10 destructors, not form the GSDevice base class).
My hackfix was to paste in a call to GSDevice::Reset() from ~GSDevice9 (using the explicit notation to bypass the virtual overload). That gets rid of most of the memory leak accumulation when exiting/resuming GS activity (F9 and such) ... But there still seems to be some remaining reference keeping the DX device CComPtrs from releasing.
Eh, take whatever I said above with a grain of salt. The results were based on analsys by feal87, and now he's back-tracking on it. That might not have fixed anything after all.
it's true that since I changed textures to pointers no one frees m_pool, and there may be more like that...
From the tests we've done, the fix Jake proposed does indeed fix part of the issues we've having. But only works for the first time you do ESC+Execute. After that the problem get even worse.
Deleting those textures GSDevice seems to work.
I also had to removing zeroing the priviledged registers from the constructor of GSState. On resuming they aren't initialized again by the emulated program.
"textures of GSDevice"
anyway, uploading it, so you can test it

Revision 1464

GSdx: fixing the (texture) memory leak
Also added a few for_each, but I should just move to vc2k10.
There are many iterations that could be nicely rewritten with lambdas, for practise.
gabest the problem is still there it seems. I'll explain how to reproduce the problem.
Use DX9 hardware. (i don't know dx10 hardware, but i think the problem is there too)
Launch a game in fullscreen mode.
Press ESC to return to the pcsx2 interface
Press Execute to restart the game.
The GS plugin should crash cause the old device (and other resources) are still present and not correctly disposed. (only one device can have the exclusive lock over fullscreen mode)
In windowed mode it does not crash but only generate lots of leaked memory.
ah, only tested dx10 in a window, no memory leak there and I could relaunch it many times.
Need to add that in order to not crash when pressing ESC already we need this:
DestroyWindow( m_hWnd );
Try it with fullscreen mode. The problem should be there. (Try doing it 2-3 times if it does not crash on first reset)
Hmm, you don't get any increase in ram usage by pcsx2.exe when hitting F9 a few times?
Ok, seems like I'm the only one that still gets ram leaking. Maybe related to me using Win7?
i don't know, but even i get memory leaking. But only little (1 MB or so each F9 unlike your 20 MB each F9).
yea, dx9 definitely leaks more
Direct3DCreate9 returns an already addref'ed pointer, oops
I can confirm with feal87 that dx9- setting a fullscreen resolution then pressing escape then resuming the game causes the emulator to crash.

Revision 1465

wxgui: Project file clean-ups and slow progressing on interface/configuration

Revision 1466

GSdx: more leak cleanup
Adding a virtual destructor to GSAlignedClass greatly helped, else derived destructors did not run :P
There were a few more forgotten texture deletes and the already mentioned Direct3DCreate9.
The debug runtime does not complain anymore when exiting.
Valgrind go!
Esc+Execute on fullscreen mode now work flawlessly!!!
The leak is nowhere to be seen right now!!!
But the F9 renderer switch now does not work anymore. (tonight it is too late, so i've not investigated why)
ahhh, I think now the compiler is confused and my callbacks do not work on IRasterizer (there is multiple inheritance), "this" has became misaligned by 4 bytes...
Makes inventing with Dark Chronicle 2 crash

Revision 1467

GSdx: last commit broke the sw renderer, the compiler seems to misalign the
"this" pointer for member callbacks when two base classes have virtual
destructors at the same time (or just virtual members, didn't test it).
[01:58] <rama1> escaping, switching renderer with F9 fiddling with options then resuming
[01:58] <rama1> all works :)
[01:59] <rama1> damn, but ESC when in dx10 fullscreen does not
[01:59] <rama1> hence no render switches either in that mode
the dx10 device class cannot switch mode itself, even if I try to put it back to windowed just before exiting, it won't do it yet :P
Hmm, I tried something with sending alt enter, then waiting a while... :p
Ah well, the dx9 mode now working fine is a great thing already :)

Revision 1468

GSdx: got rid of that bogus multiple inheritance, it just didn't feel right
Do you think we can emulate this fade effect in HW renderers somehow? :p
Escaping in and out of full-screen emulation is working fine here in DX9 land. Trying to restore from an Alt+Tab still fails to recover (get a black screen, no updates), but everything else is a-ok. :)
rama: looks like a depth of field effect
xatnys: Orly? :D
If I disable the depth stencil permanently (dsd.StencilEnable = false), the game is always in blurred state..
Rama, do you get a strange bug with VP2 causing the bottom 10% of the screen to turn black? i think its a pcsx2 bug, not a gsdx bug though.
No, that's a gsdx thing. I guess the constant rounding of floats, coupled with the game's odd sized textures causes it.
Hackfix for now:
if(ww > 0 && hh > 0)
dst->m_texture->m_scale.x = (float)w / ww /** 0.8*/;
dst->m_texture->m_scale.y = (float)h / hh /** 0.8*/;
Uncomment the * 0.8 part.
Bottom black is probably because your not running in NATIVE move.
Thanx, gabest11, just tried VP2 PAL, it was fast but the square glitches are still there, and to report that when I got in the first battle the emulator crashes.
rama, what file should be modified and where
Press Ctrl+F and find it.
I'm experiencing some flashing issues in Wild Arms 5 with this version in DX9HW some textures flash look here :
The flashing textures go away if i switch to SW mode.
And some effect is not shown properly its same in HW and SW modes:
But good work with the fullscreen, minimize and renderer switch bugs those work fine now :)

Revision 1469

GSdx: a few games fixes (one piece grand battle, xenosaga 1, chikyuu boueigun 2)
sweet a day after I bought the game (Xenosaga)
excellent timing!
Hello, Gabest! I tested Xenosaga 2 and I found that game is faster now in dx 9 (in Old Miltia at the beginning: DX9 44 FPS and in DX10 8 FPS). BUT! When I met first enemy A.M.W.S performance decreased to 0.5 FPS!!!!!!
Could you do something about it? I heard that when A.M.W.S units on screen gsdx crawls but 0,5 FPS??????????????
Now window switching crashes for me in DX10...
It is nevar crashes before, even before these "fixes" for crashes...
"these" mean latest fixes for crashing, not this rev
You've said that it's not this rev, so why did you negative this ?
Don't you want that I should negative all 5 prev commits? :P Lastest commit's comments works liek a hot-line now, it was so within few months. So it goes, it is not mine fault XD
[email protected]: xeno2 needs lots of vram, I have 256MB and it's not enough for all textures it uses at the same time, do you have more?
zantezuken: when does it crash exactly? can't repro, tried alttab, alttab in fullscreen, minimizing.
I have 256Mb too. But game run FULLSPEED with this VRAM amount except of huge slowdown (to 0.3-0.5 FPS) during field scenes with A.M.W.S units. And battles with A.M.W.S run fullspeed. That's weird...
I can't even run the intro fluently.
The game itself may be better, didn't play too much, but there could be parts where it is as detailed as the intro.
Since the last ~100 revisions everything including 16 bit textures are converted to 32 bit, so an even bit more vram is needed than before.
This game is so bad it creates lots of overlapping textures that are huge but only small parts are used, and I can't do anything but to allocate them all.
Well, I switched to desktop, then run Process Explorer and it crashed.
Hmm.. may be UAC dialog was the cause...
:( Bad news...
By the way what happened with DX10? It was always better for xeno series and now it's way slower then DX9 in xeno 2 for example.
Just tested it on my notebook which has 384MB and it ran without hickups, dx10 around 30-50 fps, dx9 slightly slower, more between 30-40 fps.
During the tutorial the slowest point I reached was at the first trap.
I can't compile it.
Performing Pre-Build Event...
SubWCRev: 'c:\Users\****\Desktop\New Folder (4)\plugins\GSdx'
Last committed at revision 1469
Updated to revision 1469
c:\users\eduardo\desktop\new folder (4)\plugins\gsdx\stdafx.h(41) : fatal error C1083: Cannot open include file: 'atlbase.h': No such file or directory
Target type: Release/SSE2
which visual studio do you have?
Xenosaga 2 is slower since r1439 (about 25-30% slower in dx10 and dx9), and its performance didnt really change since then. Also for me its has been always faster in dx10, about 25-30 faster than dx9 in every revision i tested (1426,1439 and this one), so i cant understand how you can get more fps in dx9 than dx10.
Eduarpack, that happens when you have visual studio express
OK everybody look on fps:
tested on r1469
did you test it in another revision?
I'm pretty sure that's the result of "swapping" textures in vram, like a page file and normal ram, the driver has to replace unused textures continously when it runs out of free space.
In texture managment dx10 is a bit different from dx9, dx9 keeps a copy in system memory too, but I'm not sure how it works exactly.
With cards with more vram, xenosaga2 runs quite fine.
Depending on which of the last 200 or so revisions of GSdx I use, I get either a small "hickup" when the stage loads, or no problem at all.
FPS are well over 80, too.
Card is a GTX260, with 896mb ram.
Another tester has a 9800GTX+ (512mb, I believe), and he gets more of a "hickup"..
Thanks for the explanation. It seems that upgrading of GPU is the only option...
I'm currently reimplementing palettized lookups (removed it long time ago), that will be slower but maybe not that slow on a high-end card.
It will cut back the number of different textures allocated and uploaded, while increasing pixel shader complexity and with that lowering the fillrate.
I'm looking forward to it :) Thank you for the hard work, Gabest!
@ Gabest11
Hi, Gabest. To report - I`ve tested VP2 Pal and NTSC on 1458 with all default settings, with GSDX 1469, DX9 and DX10 mode but in the frist battle in the wood the emulator crashes. The speed is great but there are still these square glitches in the woods and that crash makes impossible to reprt further progress. However I am voting POS because of the huge progress. Cheers!
Hi, I'm new to posting comments here. Just like to report that a not-so-popular game, Shining Force EXA (maybe including NEO) NTSC, did not output certain text correctly from r1447 onwards. The game ran perfectly before that. I'm using dx10 hw SSE4.1 native, MTGS, no MicroVU, with/without Speed Hacks (bug produced either way).
Also, I don't know if it was mentioned before, but Musashi Samurai Legend still renders certain visual effects wrongly (same settings, tested on a version as early as 0.1.7, and it still happens with the latest revision)...
I really hope I'm not sounding like another ferrarinews, considering that these two games are not really related to this revision, and these games are not really mentioned by other users. But I just felt that I need to mention them sooner or later (especially EXA, where the bug occurred recently)...
By the way, great work so far, Gabest.
The images of r1447 point to the same url as r1442 :P
Since I don't have every game, I can only do something if you provide me a .gs.
By the way, sorry if I'm a little noobish, but how do I output a .gs?
shift+f8, it is saved next to the bmp
Hmm...I don't quite know how this .gs works, but do you need one .gs per screenshot?
By the way, thanks for all the prompt replies so far! =)
one is enough for each game
Oh...I see...but anyway, the upload's completed...so...
It contains one .gs per screenshot, with the .gs organized into folders by revision.
So...in future...one .gs per game per revision? By the way, you're able to tell which game and which revision just by looking at the .gs, without the .bmp?
a few games fixes ,nice news :)
and there is one problem with vp2 in the forest scene in HW:
but it doesnt take place in SW. so weird ..
rchonggr: .gs is the output from pcsx2, do not change with gsdx revisions :P
Ah...I see...so it's really one .gs per game...
So...it's actually possible for you to look into every game if you have just one .gs for each of them? Nice...
Found an awful typo with the shining force dump :P
When the texture base address isn't page aligned the slower code path runs, but I switched up the sides of the ? : operator.
With musashi don't know what's wrong yet, sw renderer looks the same.

Revision 1470

- Kill programs if they haven't been used in ~7 seconds.
- Only kill 1/4 (instead of all) of total programs if all slots are full.
- Make sure programs are searched from oldest to newest. (this is needed to
ensure that new programs don't 'evolve' into old programs and repetitively clone

Revision 1471

microVU: delete -> delete[] xD
just :lol:

Revision 1472

GSdx: fixing/breaking things again... palletized texture lookup can be done by
pixel shader now (selectable, off by default), if you have a fast card it may
help with texture heavy games, otherwise it is only going to be slower.
Define fast card please? :P
faster than mine is a good start :D (8600gt)
It's an alternative way of handling big textures on cards with small amount of RAM? But usually, the faster the card, the more RAM it gets, so wouldn't cards that are fast enough to do this have enough memory to store textures normally anyway? And vice versa?
Well, few thing i noticed:
1) It always limits the output to 60fps oO
2) It's roughly -50% fps in all games here (GTX260, 696mb ram)
3) Breath of Fire 5 > a glitch in filtering is fixed by this
896mb ram :p
Same here
good work, +2-3 frames in gow2
is the 60 fps limitation in windowed mode too? cause in fullscreen (at least in DX10) the bug's been there since march or so maybe longer idk precisely
btw: is possible speed the only gain?
Just had a one hour power outage after commiting this revision...
With that new option xenosaga 2 is playable with 256MB only, at last.
I'll check that fps limiting...
ouch, the checkbox got the same id as vsync :P
Btw, longer shader code lowers the fillrate as resolution increases.
In native or not so hd mode there may be a gain, it depends on that last number on the title bar, if too large texture uploads may be the bottleneck.
This rev is great - Onimusha Dawn of Dreams and Devil My Cry 3 white screens are gone - the graphics of many games are better, but VP2 still crashes on my first battle.
@ Gabest - thanx a lot and please can you look at that thread I made for you:
Hope it was helpful.
I've seen it, but don't have the game.
yay, odin sphere got even faster :P
Any idea about that weird crash? It happens in PAL and NTSC... if I use 1450 the crash is gone however...
was 1450 the last one working?
Yes, it had the same graphical glitches but there was no crashing on the first battle and further...
xenosaga 2 with the 8-bit thing checked its faster too (not as fast as 1426 but almost there), and i also noticed that odin shpere its a bit faster too.
And vp2 1451 no crashes, with 1464 and above its crashing
Fantastic work, Guilty Gear Accent Core went from struggling to hit 50fps to exploding past 60fps fullspeed.
Shadow hearts started crashing when you select continue on the main menu in this revision both in hardware and software mode.
Radiata stories Crashes when going ingame in this rev.

Revision 1473

GSdx: the new option was accidentally linked to vsync, they got the same control
GoW2 once again has terrible sprites
hm, how should it look like?
Like this,
Even when effect covered by fog it looks right, tested on rev1469
the same bug also in GoW1
OMG!!!!!!!!!!!!!!!!! Gabest, you are a miracle maker! With 8-bit textures on, Xeno 2 now fullspeed or sometimes 200% on my 8600gts 256 Mb!
First encounter with enemy A.M.W.S unit was 2-3 fps in DX10 and now 75 fps!!!! Thank you so much!
hmm this new update improves speeds in some areas but it seems to break images abit.
what it should look like(setting is off)
what it looks like with the setting on
Notice part of logo specificly on the III is missing or broken or something. This happens in other areas too.
But this update does help out on certain games speedwise. I know i post about SCIII alot but it's pretty much my favorite game.
Crash of the titans is now even worst. Its quite darker (almost black on most areas).
that one just can't be fixed, bad input data
Ah yes, the uberslowdowns were due to the vsync, and it trying to get to fractions of 60fps :p
Now games are a good bit faster here with the new option. Great for Xenosaga indeed :p
It would be interesting to see how different cards perform in this new mode, if they become faster or slower in the same game at the same place.
I don't mind testing, but is there a list of games that are GPU intensive or bottlenecked to test on, I only remember a few.
Odin Sphere (DX9 HW mode) goes really faster with "Allow 8-bit textures", from 21~ FPS to 53~ FPS (it is still slightly bottlenecked by the GPU).
http://img136.imageshack.us/img136/2985/8bittexturesoff.jpg [OFF]
http://img198.imageshack.us/img198/2149/8bittextureson.jpg [ON]
This improved the FPS in FFXII in my HD3850 256mb, around 8% faster overall everywhere, even in the intro options before starting new game.
So far it only slowed down that Final Fantasy 12 license screen you might remember, and the especially slow scene in Xenosaga1 where you just fixed the wall in the backround.
The "New game" menu screen on grandia III had always been a GPU bottleneck for my 9600gt 512mb, the "8-bit textures" lets it increase speed and be PCSX2 bottleneck but seems stuff is missaligned. This pics are with native checkbox, you can see a line between the logo and the copyright text and another line in the middle, higher resolution makes it less noticeable
uhm actually just checked something else and if you check texture filtering with 8-bit and higher resolution in there it slows everything a lot, down to 1/3 speed while grey or unchecked runs normal speed so it's not so good with 2d? :p
I meant 1/2 speed and forgot to mention rest of the game is ok, just this screen part had this problem, also dx9 looked worse with 8bit texture
Great, +4/+5 FPS in Castlevania in "hard" places (from 37-39 to 40-44).
Sorry, almost forgot to say: GTX 260/182.xx
Mine is nVidia 9800 GT with the latest 186.18 driver. CPU is E8400 overclocked to 4 GHz. I am using 6 GB DDR2 [email protected] MHz and my OS is VISTA x64. I don`t see any slowdowns, the only slowdown is in TEKKEN5 when fighting on the rooftop and the sun shows. Haven`t tested Soul Calibur3 yet. Used to be a big slowdown in Valentine Mansion.
From r1469: Ah...I see...gotta hate 'em typos...Thanks for your follow-up comments Gabest! :)
Anyway, here's another problematic game...Grandia Xtreme USA NTSC. In many recent revisions, using the same settings as the other two games that I mentioned in r1469, certain graphics would constantly flicker. However, using 0.1.7, the graphics are perfectly okay. I can't pinpoint which revision that this bug first occurred though. I can't use screenshots to show this problem, so I resorted to short videos. You'll find them appropriately named in the archive, along with the .gs, below.
It speeds up FFXII a lot (I do not need VU cycle stealing hack anymore to get 50fps), but some glitches (text overlays and black spots on faces) appear, at least on ATI cards (HD2600) in DX9 mode... I know some ATI cards (and mine too) have very similar glitches in several games, so I'm not complaining much...
BTW, why did you disabled texture filtering in Native Resolution mode?.. Some textures (DoF blur simulation in Beyond Good and Evil intro) look pixelated if they're too stretched...
rchonggr: there was an typo in gsdx code, it did not show every second frame, and in grandia xtreme there are blanks, it's a pcsx2 problem.
eliotfur: in native mode there is no reason not to use the real settings of the game, if you see point filtered textures somewhere it may be a bug.
hi gabest , i don't know since when as i did not checkded recent revisions but the issue 246 is resolved now. Thanks

Revision 1474

Fixed System 11 emulation in Tekken 5
(EErec bug: madd should be signed multiplication, not unsigned)
Whaat? Does that mean we can play Teekn 2 now :D Great news! I would give +10 if I can
excellent! 4 tekken games in one.
so we have a system 11 emulator for ps2?...
Do you now if that has been hacked to run other things?
can someone explain what system 11 is O_O
is the sega hardware of some old arcade games.
sega hardware? system 11 is namco arcade hardware based off the original playstation with some enhancements. there was also a system 12 which had further enhancements and a system 10 which closer resembled the playstation's actual power.
If I may offer to correct - he must be refering to SYSTEM 12 which supports Tekken, Tekken2, Tekken 3 and Tekken TAG, also SF2 EX+, RIVAL SCHOOLS and many 3D games from CAPCOM, NAMCO and other devs. It`s based on Playstation ZN processor I think, while Virtua Fighter and the other STV games are based on SH2 - a.k.a. Super Hitachi 2 - DC`s cpu father.
The debug menu says its system11. So yeah. :p
if you load up tekken 5, select "Arcade History" mode.
start up Tekken 1/2, then press 'select' and it'll bring you to the System 11 diagnostic page.
So most-likely its a system 11 emulator ;p
The bad part is Tekken 3 doesn't work. According to wikipedia, System 12 supports tekken 3, while system 11 only does tekken 1/2.
So seems System 12 emulation is still broken :/
No idea whats causing that...
Actually, I checked now the bioses in the original arcades via MAME. Tekken 1 and Tekken 2 are using System 11 while Tekken 3 and Tekken TAG are on System 12.
@ ramapcsx2, good correction :)
oh rama beat me to it :p
Wonder if seeing the bioses from System 11 and System 12 and comparing them would help....
no it won't :p
all we care about is what the system 12 emulator is doing on the ps2, that pcsx2 is doing wrong :p
cotton: switch to gsdx software rendering, tekken3 works just fine :p
hmm nice xD
LOL PS1 emulator running on PCSX2, nice

Revision 1475

GSdx: couple of fixes for the new palletized lookup mode
the wild arms text craze is fixed^^ very nice though the radiata stories crash is sadly still present
going to check shadow hearts now, maybe the crashes are related
I think I broke 4-bit local to local transfer :P
has shadow hearts always been this slow? 40-50 fps, 99% cpu usage
... and why is hash_map so retarted, it does several integer multiplication and division at each lookup, just to get some magic number.
Yes, this game has always been so slow.
Software rendering is tripple the speed here :p
Star Ocean 3 crashes for me when starting new game (also when loading an ingame savestate) with latest revisions of gsdx.

Revision 1476

GSdx: 4 bit local-local transfer crash fixed (shadow hearts)
radiata stories works now <3 and star ocean 3 goes ingame so I think that works too now xD
btw Radiata stories is about 10 to 15 frames faster now (45 - 50 avrg) on 8600GTS 256 MB
thanks a lot XD
Indeed Star Ocean 3 is fixed
valkyrie profile 2 crash fixed
+10 from me! I`ll test it when I am back on Windows. BTW any ubuntu users here? I wonder if PCSX2 will run on my ubuntu 8.04 LTS.
@ Gabest11 - KISSESS!
Important bug nailed down there, GJ!
is it me or these last revisions made the image a lot more brighter? looks very strange, everything that is black looks gray
Hi, Gabest. I want to report about minor graphical problem in Xeno 2 intro:
Happens ONLY in DX10.
Oh, this change brings back the small glitches in filtering.
Maybe it can be avoided somehow?
The glitches are all over the textboxes, and it looked fine the revision before this :p
@ ramapcsx2 your textboxes are better now. I have the game - PAL and the textboxes were flickering and the text was bad. Guess I`ll try it asap.
8 bit textures helps a lot in odin sphere on dx9 from 33-37 in some places to 70-85 without any speedhacks, the only way to get almost that much fps is using EE x3 + IOP x2 + waitcycles sync that gets 65-73 without EE x3 that speed is like 33-37.
Yeah, the few glitches are no real issue. I'm just mentioning it, cause it was fixed in the revision before this ;)
U8x-9.04runs pretty good i only miss GSDX.
i use ZZogl(zerogs remake http://sanechka.spb.ru/svnroot/ruslan/zerogs).
odin sphere the same place with dx10 gets 55-60fps without any speedhack and 8 bit textures off, with 8 bit texture on gets 75-80fps, by the way its PAL and its 3.0ghz SSSE3 with a hd2600.
8 bit textures slowdown XenoSaga ep 1
VP2 and Star Ocean 3 are working normal here. VP2 only had the forest graphical bugs but works at full speed, after the forest, dungeons and towns and in-battles are great. SO3 is normal everywhere.
@ gabest11 - superb work! If you get Steambot Chronicles to work without these vertical yellow/blue lines and at the same speed - I`ll merry you!
Maybe I didn't notice earlier, but EXA works fine again. Thanks Gabest! ^^
My positive goes to your fixing of bugs for various other games though (especially VP2 and SO3). =)
@Gabest11, I`ve had some progress in VP2. I had to report that it seems all WOOD-based backgrounds are with broken graphics. There is another wood with almost the same graphical bugs, sometimes the bugs vanishes when you shoot crystals... Guess it`s VU/EE dependant... I`ve heard that VU manipulates Special FXes....

Revision 1477

wxgui: Tons of changes, additions, and improvements...
* Added some icons for use in the new configuration panel.
* Added bin2cpp project, located under a new /utilities folder (it's used to
generate wx Embedded Images)
* Renamed NewGUI folder to gui
* Relocated Resources folder to gui/Resources
Error 130 fatal error C1083: Cannot open include file: 'WinDebugResource.h': No such file or directory i:\dev\emu\pcsx2wx\pcsx2\windows\Win32.h 30 pcsx2
We can't take a look?
Ok, fixed by commenting that line, which was obvious...
yeah this is still a nice hackup job. I have a lot of work ahead of me yet to get all the dialog boxes laid out and looking sharp, and of course doing what they should be doing. :|
Well, it already look nice. Especially quick boot dialog <3
Can't wait for toolbar :P
Btw, I see you made additional separated Video/Audio/Plugin menus. If I got the idea right, that mean we can quickly select the plugins via drop menu where it will put the list of all specified plugins (the video ones for "Video", etc), right? So, we can just check SPU2-X plugin and then go in teh settings menu in the same drop-menu, right?
quickly selecting the plugin?
with basic and advanced etc it looks more like selecting plugins through a configurator XD and the Graphic and Audio menues are for faster easier configuration but maybe both in one XD
If I'm wrong ^^ I'd really like to know what'll be configured under "advanced" xD
bottomline looks nice n way better than now XD
just a question: all the windows of the gui will have their positions saved?
>> just a question: all the windows of the gui will have their positions saved?
It's usually not standard practice to save positions of popup dialogs the like configuration popups. But yeah everything else will save/restore position and size.
>> If I'm wrong ^^ I'd really like to know what'll be configured under "advanced" xD
That may or may not change yet. Right now "Advanced" will take you to the current plugin configuration screen. The rest of the menu will actually be programmed by plugins (optionally). So like a plugin can inject its own options and toggles into the Audio menu, for quick on-the-fly settings changes.
For a plugin that's been developed with the new gui in mind, "Advanced" makes sense since the plugin's own simple/on-the-fly configurations will be available right from the menu. Fur the current plugins the term seems less appealing since it's more of a plain "configure plugin" case.
Sounds wondeful.
>> It's usually not standard practice to save positions of popup dialogs the like configuration popups. But yeah everything else will save/restore position and size.
Thanks jake for this, this is always a thing that i miss on emulators. ;)

Revision 1478

wxgui: Fix Linux.

Revision 1479

GSdx: New default settings, to avoid common mistakes and problems.
If you disagree just revert. The most important thing is logz though, games need it.
Specifically, in DX9 there are like 4 games that need disabled LogZ to fix minor glithces, while about 300 others are anywhere from partially to completely broken with LogZ disabled.
I was thinking of replacing fba with the new checkbox and setting fba permanently on, but in the end I let it there.
Not sure how many games need it being off, it's a dx9-only thing, which I never really use.
Palletized mode is generally slower on my card at any higher res (1024+).
There is a trade off between doing the lookup once with the cpu for all pixels, or doing it for only those pixels that are used in the shader.
It would be quite hard to predict which method is going to be faster (number of accessed texels, gpu vs cpu speed), there are too many factors.
Yeah, well, I made some broad testing with many games at 1024 * 1024 res (the default ;) ).
For me the new option is faster in 95% of them, sometimes by a lot.
I suppose for most people with a midrange card, it'll be good as well.
Anyway, looking at those monstrous fillrates wikipedia lists for today's mid-range cards I'm sure this little resolution problem isn't going to be an issue within a few years, for anybody.
Just comparing these two makes me think the 8800 gt could perform the same at double resolution, since it has 4x fillrate for texture lookups:
8600gt 8 mt
8800gt 33 mt
And the fillrate column for GT2xx series is just ridiculous :D
I meant to link this: (just different anchor)
Erm... GTX 260 has 36.864 GT/s and 8800GTX has 36800 MT/s. Aren't those the same?
Yea, but GTX 260 is low-end 8800 GTX high-end, in their own generation.
well the gtx 260 is mid-end hehe, i have a 9600gt (is a low end now) and the new option perfoms about the same in the games that i tested (persona 3, shadow of the colossus, KOF maxium impact 2)
the gtx 250 is somewhat ambigous, it belongs to the new series only in name
"ivansal:, Today (25 minutes ago)
well the gtx 260 is mid-end hehe"
... dude... mid-end? .... there is something wrong here....
try to picture a mid-end on a sausage.... there is no way that could work... you'd most likely end up with two sausages...
Question for Gabest:
Are there optimizations for power of 2 resolutions?
Like would 2048x2048 be faster than 1680x1050?
Or would 1680x1050 be faster simply becasue it's way less pixels?
I don't think power of 2 textures would be any faster
I mean frame buffer, texture are power of two :D
I welcome logZ enabled as default always thought it was the right way, however 8bit paletized doesnt work so great always... introduces some glitches and at least in my case it doesnt like being enabled with texture filtering together (brings some slowdown in most GS limited games I tested with filtering in 9600gt).
Back when i was doing some asm x86 programming we used mmx to optimize for power of 2 resolutions, but it was in image generation, not rendering, so i'm clueless :D, Ty!
It's like multiplicaton, if it's 1 clock and has at least 3-4 execution units then it reached the max possible throughput already, there is no point replacing it with shifts.
On the gpu the whole scan conversion including the frame buffer address calculation is probably hardwired anyway :P
Yea i guess.
Know how Dolphin does to not depend on framebuffer size? like 512x512 and 4096x4096 is the same fps, it's insane.
so a CPU palletized texture lookup copies textures with correct color into the vram?
will try texmod again :p
detected a texture corruption on HighPoly Models in Grandia 3
there is also some flickering junk from the menu graphics in the background during movie playback:
Please mention the directx version you're using when you report bugs.
This is a dx9 only problem :p
Grandia 3 textures look the same to me on DX10, those errors have always been there for me but on dx9 only if using any other than native or 512 resolution but never on dx10.
I`ve tested many games, everything is great here. Capcom VS SNK2 has no more sprite bugs with texture filtering enalbed and the guard bar (known as guard gauge) is a pure green color.
Tekken 5 has great graphics too, however the Sun bug is still there... wonder if it`s only on nVidia, please report if somebody encountered the Sun bug on ATI :)
Soul Calibur 3 has a great speed in Valentine Mansion, kudos to gabest11 again!
Tekken 4 works again on 60 Hz display.
Transformers 2 is still with broken graphics, not that I care but I have to report what I saw.
Devil May Cry 3 and Onimusha Dawn of Dreams are no longer "unplayable white" a strange "too-white" screens which made the games unplayable at certain places, however the strange graphical mess in Onimuhsa DoD in the begining is still there, but it`s not a problem :) Cheers again here.
Great job! Thanx a lot, you guys! You are actually the best!
yea sorry its DX9, i'm too lazy right now to install vista XD
DX10 mode is better if you ask me... The only reason for me to use Vista is for it`s DX10 support and better graphics in PCSX2 emu. Guess MS should thank PCSX2 Devs.... Otherwies I am always using debians :D

Revision 1480

microVU: fixed some bugs...
This commit reminded me of something I'd been looking at previously in microVu_Flags.inl:
I'd noticed in mVUflagPass that aBranchAddr doesn't get initialized. Is it possible for shortBranch() to be called before it gets set to branchAddr, since that uses aBranchAddr?
Just wondering, because it occurred to me that it might lead to potential issues...
nah its a bit messy, but whenever aBranchAddr is read, it will have a valid value xD
All right, cool.
I'd played with it a little, and wasn't seeing it get called when invalid, but wanted to be just it wasn't just a really rare occurrence, or something along that line.

Revision 1481

Onepad: Added a clear all button, and did some work on the backend.
Basically wanted to have these changes saved in case I have to revert to an earlier version...

Revision 1482

OnePAD: All around my hat...
Think the hat code works properly now. Mostly, anyways.

Revision 1483

Reformatted Mpeg.cpp. Reworked mpeg2sliceIDEC a bit, and added a fix which I'm
not totally sure of, so it's currently disabled. Did a few other misc cleanups.
For the interested, all of Mpeg.cpp is functionally the same as it was. mpeg2sliceIDEC had some redundant code that I removed.
If you want to activate the code I wasn't sure of, uncomment:
Works nicely with Mana Khemia; got me past the normal crash when going outside. I'm just not sure if it breaks anything else.
anything related to mana khemia give me more reason to play any gust game.
This replaces the usual Mana Khemia hack, btw. That one causes mpeg2sliceIDEC not to be called. I observed that of all the times mpeg2sliceIDEC is called, the only time it was crashing was when so_resume had not been called before so_exit.
So this just forces it to call so_resume at the end if it hadn't been called, before calling so_exit.
I figure it's less likely to break things then that hack, but thought I'd leave it disabled by default till I have feedback from people that know this section of the code better then I do... :)
same effect as hack of IPU.CPP when go to world map.
I'm playing Mana Khemia in chapter one so I can test it as well.
I just hope it doesn't break anything so it can be made as permanent change.
On Mana-Khemia, usual IDEC/BDEC delay patch works better.
Plain pcsx2 with this new define causes strange "hiccups" and "flashes" while playing, so I went back to this rev with define off and patch applied.
There might be something else I need to test for besides whether so_resume's been called already or not. It may be getting some false positives.
I'll have to play with it a bit more...
BTW, were those hiccups & flashes in Mana Khemia, or other games?
I ask because in Linux, I get hiccups and flashes with either the patch or the define.
II'm getting ready to do some testing in Windows with GSDX, so I know how much is ZZogl and how much isn't...
Ehem... they didn't happen with previous rev and happen here _without_ the define too, now what I've playing with the old patch thing.
This is on Windows, btw, not just linux.
Hmm... I'll look into that. The other changes I made shouldn't have affected anything, but I'll try reverting a few of them on my personal copy, and see if any of them make a difference...
Actually, thinking about it, do you get the hiccups and flashes if you uncomment line 2051 of VUops.cpp?
In linux you have to use ZeroGS which not good at Mana Khemia cuz images blink.
the optimal graphic plugin is GSDX with D3D software, regardless of speed. with no glitches appeared. Although GSDX with D3D 9 hardware have flashes most appeared on dialogue images, not very often and that serious, I ignore it.
However, I dunno more about it, I currently playing Chapter one in Mana Khemia by now.
You'd better play yourself to watch over.
Let's just say that this patch could have actually been committed yesterday if I hadn't stopped to play Mana Khemia for a while...
And all the issues I was thinking of, were, in fact, due to ZeroGS/ZZOgl, since I just did some testing in Windows, and everything seems to be working fine on my system...
Uncommenting that line doesn't help with the strange blinkings.
I'm using GSdx, which was fine yesterday and hasn't been touched (so let's discard that).
works absolutely fine here... tested with mana khemia ,FFX+FFX/2 ,Seiken densetsu ,Wild Arms3 and some other nippon ichi games
tested gsdx dx10 only
According to rama, it breaks Digital Devil Saga...
blinking images solved
It's not related to PCSX2 executable whether you compiled your own modified or not. GSdx-SSE4-r1479 caused it, might also recent revision of GSDX.
reverted to GSdx-r1076-sse4 I merely retained and no frustrating blinking images occur, working with D3D 10 hardware on VISTA SP2. Guys could try old revision of GSDX should also work.

Revision 1484

wxgui: more of the slowly progressing.
* Implemented internationalization (i18n) framework.
* Made a pretty configuration dialog box!
* Many minor bugfixes.
* Removed most of the old Win32 and Linux/GTK gui code because it was causing
gettext cataloging to grab about 500 non-relevant strings (can always reference
trunk for them anyway).
Oh, that looks just wondeful <3

Revision 1485

Removed the wait cycles hack, and made it effectively always on.
The magic values for this setting were made for the old, sometimes failing
It should not be needed anymore, and testing confirmed that.
I'm not too sure I did everything correctly for the Linux side of things, please check? :p
The changes you made are fine. I'll have to actually delete it from the gui, but that takes a special program, so I'm always going to end up doing that part anyways. (Unless Jake does it, or until wxwidgets is the default...)
is this hack stable enough to let it always on?
i never used it because it doesn't give a noticable speed boost.
Yeah it's fine. Technically the hack was having it enabled (in which case it would be a "slow hack" I guess). It compensated for errors and missing syncronization points in the pcsx2 event scheduler by forcing periodic updates. Almost all such errors and sync issues have been resolved, so there's really no need for the waitcycles to be periodically enforced anymore. :)
Both Wind and Canaria boot and work fine now (by default), instead of being broken with default settings, Issue 276 can be closed.
Well, this problem is masked now.
It's still there, so these games might break again one time :/

Revision 1486

Renamed a few files so that they more clearly represent their meaning. This was
goign to be part of a bigger change but I got annoyed before I had to chance to
actually start working on it, so I'll drop this anyhow.
Gah typo. to->the
Double-post: this breaks linux building, so someoen needs to update the linux side...
Taken care of.

Revision 1487

Fixed up the Linux build. A couple minor OnePad changes.
Oops. Left a few things in that I didn't mean to. I'll clean that up in a few minutes.

Revision 1488

Fixed the last commit. :(
Figital? Oh well, not doing another commit just for that...
Just woke up, and didn't get as much sleep as I should have, but I don't think I could get back to sleep right now, so that's probably why I didn't notice the test code in there...

Revision 1489

Refactored the IsoFS crap to use better function names, and removed some stupid
remains from when this code was part of a PS2 driver.
Added a WIP Iso reader to pcsx2. Right now it doesn't do anything (meant to be a
backup in case I mess things up too much later), but the idea is to integrate
iso reading, blockdump creation and loading into pcsx2, obsoleting CDVDiso and
cdvdBlockDumper, and giving support for potential future features.
This is one of these revisions that I like while wondering if it actually works in Windows. :(
I'll be taking out that stray break; that was left in IsoFS_readSectors in a minute, as it utterly breaks Linux...
If iso reading could be a part of pcsx2 as a whole that would be awesome.

Revision 1490

Fixed a problem in volume slides that caused them to update way too slow.
Music in Ys 6 works again.
Oh, and much of the xenosaga2 score is nicer now :)

Revision 1491

wxgui: Fix linux builds and other additions/fixes.
Hmm.. I'm pretty sure my modification to sparseconfig.h is GCC 4.4.0 specific. Prior versions of GCC probably have hash_fun.h under /ext. -_-
Ah damnit. Linux decided not to commit some stuff because it decided it was in a conflicted state. Guess I'll try again... >_<
If so, remember that I've got an ifdef set up for GCC 4.4.0:

Revision 1492

wxgui: missing file updates from my previous commit.

Revision 1493

Fixed up the Linux build.
Somehow, this commit seems familiar...

Revision 1494

wxgui: Upgraded to wxWidgets 2.8.10.
This affects Windows builds only, since Linux builds use whatever shared wxWidgets library is installed on their distro.
Yep., in my case...

Revision 1495

GSdx: game fixes and small optimizations
is it just me or is this rev a lot faster in menus and some 3D areas?
in ff12 the menus letters are now all pixelated
in terms of speed the previous rev was doing 89 to 90% in a specific menu and this rev does 91 to 92% in that same menu (8800 GT)
i forgot to say the new 8-bit texture option was on in those tests
I don't see any difference in ffxii.
ops sorry, my bad i didn't notice the new default value for the texture filtering option, it was gray
now the speed came back to 89 to 90% in that particular menu
again sorry :P
almost everything i tested is a little bit faster (1-2fps faster if i use gsreplay), the biggest change i noticed was in xeno 2, about 7-8% faster
Thanks, GunBuster title screen is now displayed correctly, and Rozen Maiden GG is playable on HW.
You might be able to discard this, it is normal that certain frames or objects flash in HW with interlacing set at "none", considering RM:GG works fine in SW set at "none".
http://img219.imageshack.us/img219/730/alphavariable.jpg [correct]
http://img249.imageshack.us/img249/5464/alphavariable2.jpg [less transparent]
Screen flashes (refresh?) from top to bottom, and the colour intensity (alpha) varies, maybe is just a single trail frame over which changes the alpha, the border shadows are also darker.
Just to know if it is intented, 4 interlacing modes don't flash on HW, game is perfect now regardless of this.
Shadow: The less transparent one looks more correct to me, although i never have played the game, it would be silly to have it that transparent as it would be difficult to distinguish what is in the boxes compared to the background
I seem to have found another bug. In Rogue Galaxy there is a light source that fades in and out of walls. After testing a bunch of old versions I found that this started in r1266 and got really bad in r1279.
As of r1495 it's calmed back down to where it was at r1266, but it's still there. Here's the .gs files for it:
1495 Hardware Mode dx11: http://rapidshare.com/files/255131354/RogueGalaxyHardware1495.rar.html
1495 Software Mode dx11: http://rapidshare.com/files/255131936/RogueGalaxySoftware1495.rar.html (bug does not occure in software mode)
and just for fun, here's one from r1476 when it was still really nasty:
refraction: I also though the same, logic dictates so, but transparent colour filling on dialog frames have been since Star Ocean on the SNES and probabily before, even when it difficults proper reading. Those are only decision and in-battle frame boxes, normal dialog frames are only slighly transparent.
The characters outlines are also affected, the way the shadow borders of the frames are oversampled are just the same as in Cat Fight, eventually on that game the letters shadows become opaque due to the trails.
I tried to fix rouge galaxy as much as I could, it uses alpha values bigger than 0x80, only looks correct with dx10.
I have a transparency/visibility problem with numbers (damage, sp etc) in Persona 3 FES. Any help to pinpoint the problem? There is no such artifacts with ZeroGS or some old builds of GSdx.
I am using: pcsx2 1507 + gsdx sse2 1495
// different presets don't change the situation
There are some bogus vertices mixed in when drawing the damage numbers.
May be a bug in the game or emulator, but it confuses the texture cache. I'm just going to filter them out.
Thanks a lot.
By the way maybe it'll be good idea to add window size (for windowed mode) to the .ini file and presets window.

Revision 1496

Implemented WIP code to run a ISO image from within pcsx2, ignoring the
currently selected cdvd plugin.
I tried it and it seems to work, but I can't assure it's bugfree.
Next step is to implement internal blockdump creation and loading, and fix any
problems ppl might have with this.
(And sorry for breaking linux on every commit I do. :P)
you could have implemented this the other way around, set the internal plugin-like function in place of the real plugin, then no need to check every time every call which one to call.
Yeah we'll probably do that later on eventually. I don't mind it like this for now tho. It's a bit (a lot) easier to debug, and the macro hell that is the pcsx2 plugin function binder would be totally unfun fix up so it has renamed cdvd function callbacks (would have to rewrite it for cdvd -_-).
i have a problem with save state (sorry it is NOT related with this release) but maybe You know the solution to my problem.
When i try to make a save state pcsx2 just quit without any message/error.
First time it occured when a "new save state" (if i remember change in 7zip) was introduced.
Not a problem, though I just worked around it for now. I'll actually add it in properly later.
I'll be out of town from next Weds to Mon, though, so if anything breaks in Linux in that period, though, it'll probably stay broken till I get back...
whats this?
an own isoloader in the emu wich doesn't need any CDVD plugins? (known from epsxe)
neat :p
Hopefully this will lead to being able to launch ISO's from the command line. A boon indeed to any front-end developer
The emulator already supported that... to some extent. It would let you pass a string to the open function, which the selected plugin could use to "choose" a iso image or disk drive to run from, instead of its configured value. I just dont' know if the commandline parsing was actually working or not, of it any plugin other than CDVDiso supported it.
Thanks for the reply gigaherz, it works like a charm. I had no idea that function was there, I didn't remember seeing it last time I looked at the command line functions

Revision 1497

Unbreak Linux. (I'll wait on actually adding the new features.)

Revision 1498

Remade CDVDisoReader from CDVDiso, without removing the blockdump stuff.
Included CDVDiso's iso handing functions into core (with renamed filenames).
Implemented block dumping into CDVDaccess so that it also dumps from a CDVD
Made the blockdump creation use a timestamped filename (can be turned off in the
code), but it needs implementing a linux version of the timestamp.
The blockdump choice doesn't get saved (yet), and I'm not sure if I should make
it save, or leave it as is.

Revision 1499

Fixed a "whoops" bug on CDVD closing. Removed some unused code from