PCSX2 Documentation/Google Code svn repository comments archive 5500 to 5999

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 5500

gsdx-ogl-wnd: multiple VS compilation fix.

Revision 5501

gsdx-ogl-wnd: forget one file ...
It works with PCSX2 now, renders normally I guess.
Does it use any OGL yet?
I didn't do anythings yet ;) It was only some cleaning to allow to dynamically change GSWnd. I need to do the wgl implementation. I also want to add an EGL (initialy android, but linux drop glx in favor of EGL too) implementation, maybe one day it will be cross platform (ie with window).

Revision 5502

gsdx-ogl-wnd: * add a preliminary context and wgl management
Note: don't expect to compile/work yet

Revision 5503

* fix C compilation issue
Remain 2 issues with VCS:
1/ need to add 3rdparty dir as include dir (zzogl seem to import
2/ need to add opengl32.lib as additional lib

Revision 5504

gsdx-ogl-wnd: try to update VS to include 3rdparty and link with opengl32 lib
It builds with msvc2010.
And it starts up with the renderer set to OGL hardware. Crashes whenever it has to draw something though :p
If set to OGL software, it seems to run fine. Can't tell if it actually uses OGL presenting though.
Cool for msvc2010.
I just found that I forgot to remove various #ifdef linux so I still use the DirectX device... Besides I miss some important part of openGL, I need to init all gl function pointers either manually or by putting back GLEW. Progress is slow but steady ;)

Revision 5505

gsdx-ogl-wnd: Try to compile OGL backend on VS
* Update project files
* basic compilation fix: include stdafx, s/uint/uint32/
* add selection of the opengl renderer/device in gsopen
Remain to fix opengl function declaration/initialization

Revision 5506

gsdx-ogl-wnd: add GL function loading (done manually). It would be interesting
to do the same on linux that would allow to drop glew depency.
Still doesn't compile but you knew that. Keep going ;)
That not normal. Maybe I forget to commit something I need to double check. If you have still the log of VS, I will be very interesting.
ok I did forget to commit one thing... It must compile file now.
I don't expect to work yet because I don't know how shader file path are on windows. However it will become more difficult to test on my side, Intel is quite limtited on opengl!
I will test. thanx gregory

Revision 5507

gsdx-ogl-wnd: forget 1 file

Revision 5508

gsdx-ogl-wnd: really create a 3.0GL context
A release build currently doesn't compile because assert is unknown.
#if defined(_DEBUG) //&& defined(_MSC_VER)
#include <assert.h>
#define ASSERT assert
#define ASSERT(exp) ((void)0)
It compiles with ASSERT :p
Thanks very much. I completely forget to test release build.
One question, do you have a popup with a stracktrace on window after a crash? Maybe I need to recompile PCSX2 with debug option (and not only GSdx).
/home/willian/pcsx2-svn/src/pcsx2-build/plugins/GSdx/GS.cpp: At global scope:
/home/willian/pcsx2-svn/src/pcsx2-build/plugins/GSdx/GS.cpp:71:13: warning: ‘s_isgsopen2’ defined but not used [-Wunused-variable]
make[2]: ** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/GS.cpp.o] Erro 1
make[1]: ** [plugins/GSdx/CMakeFiles/GSdx-0.1.16.dir/all] Erro 2
make: ** [all] Erro 2
It doesn't crash anymore when selecting OpenGL hw or sw.
Both render modes present a white screen currently and are complaining like this:
3.x GL context successfully created
Supported Opengl version: 3.3.0 on GPU: GeForce GTX 670/PCIe/SSE2. Vendor: NVIDIA Corporation
Error opening plugins/convert.glsl
willian: You're using archlinux, right? Would you please provide me the build output in pastebin site so I can take a look?
Rafael.. look this!
That not too bad. Can you redo a test with a copy of glsl file:
=> cp plugins/GSdx/res/*.glsl bin/plugins/
I don't know how to install them neither if I must use ressource stuff!
@linux user
The purpose of the branch is a window WGL implementation (in progress) and a linux/android EGL implementation. I will fix linux compilation when step 1 is done.
Oh, it worked once in hardware! Gave me a green'ish but recognizable bios screen. Software worked as well, and looked just fine.
After a couple crashes though it won't start anything anymore.
Great, thank very much for you testing.
I guess there are several bugs in my opengl implementation. Hum I need to review some defines (like OGL_MT_HACK). I didn't think it would work on windows one day.
Hardware mode is similar to rama's results,
http://i50.tinypic.com/n8f2q.jpg (ff12 load game sceen)
http://i49.tinypic.com/4j7tah.jpg (ff12 ingame)
(opengl software mode looks normal so I assume that's still just using the normal software mode.)
konajonam, what GPU do you have? AMD or Nvidia?
I have an Nvidia GeForce GTX 560 Ti

Revision 5509

gsdx-ogl-wnd: Build fix
same error for me, see previous post :/
This fix was for Windows. I've no idea what your error is about, sorry :p
May someone check the build bot? ^^
Build bot is fine, this is a branch which it doesn't build.

Revision 5510

* move GL loading function into its own namespace
* Use manual GL loading on linux too and mostly drop glew dependency. (Not 100%
clean we are still depends on some glew define, it will be fixed later)
Note: shaders still need to be copied manually from GSdx/res to bin/plugins

Revision 5511

* add a new config define ENABLE_OGL_MT_HACK to replace the define OGL_MT_HACK
Ogl software works fine with this rev but hardware simply crashes again.
Anything you want me to try out?
Move onto the rpcs3 project and help those guys. By the way..can you guys make the steering wheel work so I can play Granturismo 4 perfectly.. now its just emulates the dual shock
I enabled more debug stuff (note I didn't test yet ms compilation). Normaly on debug mode, it will create a "Debug.txt" file that could contains some interesting log. Normally the shader compilation must be outputed to stderr (that said I must check if this code is still working). Otherwise is it possible to get a backtrace from a debugger (with luck it is a stupid crash)?

Revision 5512

* Remove bad redefinition of glActiveTexture and glBlendColor pointer
* Remove glew dependency on linux
* s/OGL_DEBUG/ENABLE_OGL_DEBUG/ and enable it on debug

Revision 5513

Updated portaudio to the svn revision 1885.

Revision 5514

Created a branch for an experimental attempt at removing the internal audio
module system and using portaudio for the whole output stage.
And good luck :)
Note to whoever may want to try this: I'm working with vs2012 exclusively, so if you want to compile anywhere else, you'll have to fix the other project files or cmake scripts yourself.

Revision 5515

spu2-portaudio: First step in the journey: removed the module list and hardcoded
the output to portaudio. Also fix portable.ini which I wrongly included in the

Revision 5516

spu2-portaudio: Ammend last commit.

Revision 5517

VIF: Fixed a logic error from r5380 which broke The Simpsons Game
Good job. Did you test any of the games we had issues with?
which other games? xD
Shadow Man and Soul Reaver and maybe more. The titles that recently liked to break :p
I'll go ahead and see if those are fine.
Both titles work as usual, slight SPS in Shadow Man and what looks like path 3 masking glitches in Soul Reaver.
I don't have soul reaver, can you sort me out a dump?
Irc :p
At work :p and my dcc never works :p

Revision 5518

spu2-portaudio: Project file update for msvc2010

Revision 5519

gsdx-ogl-wnd: gl.h doesn't provide same functions on linux and windows...
Software Ogl works with this output:
Hardware doesn't init correctly and says this:
Hum, it seems there is somethings wrong with the "reload" of the plugin, because GSopen doesn't depends on the renderer. I think if you close PCSX2 and restart it from Hardware directly it would work better.
Except there is a shader error (and perhaps others) that I need to fix:
>tfx.glsl (entry vs_main, prog 18) :
>0(101) : error C1008: undefined variable "VS_LOGZ"
Right, I got it to work in hardware after it failed once. I simply chose full boot once more and then it 'worked'.
(As bad as the other time, lots of glitches over mostly black :p)

Revision 5520

* implement GSWndEGL copy/pasted from zzogl.
* remove linux debugging shader that failed to compile on window
* add additional debug message during context creation
fprinf is not defined in Release AVX.
Fixed. Sorry time to compile.

Revision 5521

gsdx-ogl-wnd: ooups
Heh, didn't even see that :p
When you got some free time, can you send me the full console and the content of the "Debug.txt" file (must be built in debug mode). So at least I can fix obvious errors.
Do you have God of War1? I'm curious what you get on the "fire" menu rendering.
On linux and AMD, I got some strange (blend issue) square. Then the full screen become black except the title.
I quickly tested gow1 and I get a red line at the top of screen the rest is just black.
@Gregory, where are plugins on linux?
what do you mean ?
Not appear plugin for me on arch linux!
@willian, let me check one thing: Did you build PCSX2 using the branch 'gsdx-ogl-wnd' or the default 'pcsx2-svn' PKGBUILD? I'm asking this because if you're using the default 'pcsx2-svn', you should know that I set it to use 'trunk' (not a branch) and, therefore, there should be no business in this revision, as it would be a whole different topic.
I have the feeling that he build whatever-is-the-branch of latest revision.
Rafael could you make it harder to build branch and puts a big warning (not working and no support).
Actually, I don't provide a package based on any branch because of instability, just one package based on svn trunk.
Rama, Konajona,
I fixed a (HW renderer) shader on Nvidia GPU. If you have some spare time, could you do a retest.

Revision 5522

spu2-portaudio: Refactored the SndOut Portaudio class a bit: Separated the class
declaration from the method implementation and moved it into the header.

Revision 5523

[No log message]
I suck. I pressed ok before writing the message ¬¬
should have been:
spu2-portaudio: moved around the config dialog, and put the portaudio settings in the main dialog.

Revision 5524

spu2-portaudio: Improved the layout of the config dialog.

Revision 5525

spu2-portaudio: Refactored the Portaudio class into a static class called
SndOut, and also changed some things around and moved some classes and structs
into separate files.

Revision 5526

spu2-portaudio: Some improvements to the device selection. It now has an order
of preference for Host APIs if none is selected or the selected one isn't

Revision 5527

spu2-portaudio: I was tired of VS saying some projects were out of date. Feel
free to take the diffs and backport to trunk ;P

Revision 5528

* initialize the context status variable that take care of some startup hang
* cmake: don't link and compile EGL when it isn't requested
thanx gregory..

Revision 5529

spu2-portaudio: Another attempt to improve the DplII dematrixer.

Revision 5530

Fix for blockdumps, thanks gigaherz.

Revision 5531

spu2-portaudio: Fix config dialog. Fix initialization of WASAPI shared (non-
exclusive) mode. Partially revert the DplII changes, brought back most of the
older (simpler) algorithm that worked at least as well as the new attempt.

Revision 5532

spu2-portaudio: linux update
* update cmake
* wipeout module selection
r5535 added a new config option that will need implementing on the linux side. Sorry to cause you more work ;P

Revision 5534

Revert previous commit. I didn't mean to press ok.
You sure do have problems with that OK-button.
Let me give you something to consider:
In swedish "ok" means "yoke" - and that no joke.
Yes, I have a problem with that. The problem comes from two places:
1. At work we have the bad habit of not using commit messages, and we rely on paper-based task tracking to know when we have done something (yeah that means a sheet of paper with the list of tasks to be done, that we mark as done whenever).
2. I'm used to git for personal projects, where I commit often but it's okay since the commit history is local and I can ammend, squash, etc. before pushing into the server.
So sometimes I forget pcsx2 is neither of those, but still press ok. Most times I remember in time, and others I can cancel before it's done, but a few of them I'm too late.
yeah time for pcsx2 to move to git :)
I wish. I'm the only developer with an interest in switching, it seems. They like the revision numbering too much, and the Git workflow not quit enough. XD
From what I've seen of it, I can't stand git :P
It's really nice, it just takes a while to get used to the names of things.
If you manage to get over it, the workflow is much better than SVNs.
That said, it's not without flaws, and really, the only reason I like git now, is because TortoiseGit stopped sucking. Every other client I have seen makes things too annoying.
The one large downside to Git is that the revision names are based on a hash of the changes, so you can't easily follow the commits by name, or tell which version corresponds to which commit, but it's designed to make branch management easier, which is a very strong point of Git, and a very weak one in Svn (which you should already know if you ever did an Svn merge).
Most projects I have seen use a method to automatically generate version numbers on merges, so that even if you can't really follow the source code history without a git GUI, you can at least identify the binaries ;P
Also, there's tags, which are meant for like when you release (and unlike SVN, they are just pointers to a specific revision, not a branch with a special name).
Finally, Github has an SVN interface. You can access any repository with an SVN client, by using the standard https:// url, update and commit from it directly into the repo, if you don't want to use a git client.
yeh i think i prefer the short revision numbers than some hash crap :P its easier to work with the public using this too and it's basic. We don't really "need" better branch management as most of the time we are only ever using the trunk, so it's really not worth it.
In my oppinion "always using trunk" is part of the problem, not a reason against git, but yeah as I said, I'm the only pcsx2 developer who even likes git ;P

Revision 5535

spu2-portaudio: Merge from trunk. Partially implemented disable output option
now that there's no null output (not bound to the config dialog yet). Add a
print to show portaudio's estimated output latency after opening the output

Revision 5536

spu2-portaudio: Bind the DisableOutput setting to the dialog.

Revision 5537

spu2-portaudio: If the device info says the defaultLowLatency is higher than our
suggested value, use that one instead. In my case it returns 3ms but it may be
more helpful for other people.

Revision 5538

VU Interpreter: It seems doing JALR in a delay slot is not taken ( Evil Dead -
Fistfull of Boomstick) So the game now works in VU1 interpreter only. Tried
fixing up MicroVU but its too confusing. Got close but lots of missing textures
Great Work Ref. :)
would have been better if i knew how to fix microvu and possibly supervu, but their branch code is just a mash of code xD Will leave pseudonym or someone to do that.
Can you throw in a DevCon.Warning for me? I could check some SPS titles against this then.
Can do mate, can somebody look at this with microvu as well?
Somebody is on vacation I'm afraid :p
Damn him :p

Revision 5539

VU Interpreter Branch Delays: Rethink of this. As it's completely undocumented
and nobody seems to know exactly what goes on, i have made my own guess...
If the first branch is a branch instruction, then ignore the second.
If the first branch is a jump instruction, execute 1 instruction from the first
jump, then execute the second branch. (This is the only confirmed thing i can
find from people testing this)
Evil Dead, Hot Wheels and The Thing (the 3 games known to be fixed by branch delays slot) all work now, The Thing didn't with my previous changes.
And thanks for the devcons :)
Nps :p

Revision 5540

spu2-portaudio: Different dialog for Soundtouch advanced settings. Thanks to

Revision 5541

VU Interpreter Branch Delays: After some brainstorming amongst the team, we came
up with a theory on what should be happening. I'm pleased to say it works in
all cases.
As a bonus, the Tony Hawk Project 8 game (possibly the others using the same
engine too) now have perfect graphics in VU Interpreter :) (software mode still
required to get rid of lighting garbage however. Skipdraw 2 "kinda" works, but
not overly well)

Revision 5542

gsdx (ogl):
* Don't try to allocate a "null" array when shader log is empty
* glsl: hopefully implicit cast error on Nvidia driver

Revision 5543

spu2-portaudio: add the DisableOutput checkbox on linux too

Revision 5544

VIF/VU: Fixes for Everblue and Hitman 2 from r5404, details below. Savestate
bump needed, sorry. Also fixed a copy/paste bug i noticed along the way in
Everblue: Slightly messy fix, not as nice as id hope, but it seems to work, we
need to remember VU programs written to the VU so we can check if an unpack is
modifying it. This retains the behaviour of the Snowblind engines whilst fixing
Hitman 2: Our vif0/1VUFinish() routing which works in conjunction with the
delays wasn't paying attention to if the VIF was stalled or not and reran it
before the game wanted it to, now fixed.
Great you got this without needing to revert the VU delay :)
How can an unpack modify micro memory? Unpacks should only be touching regular VU memory. That part of the change looks wrong (the array also isn't safe, potential overflow).
I know the array has a potential overflow, gonna modify that. Not sure whats gong on there bt it works, very weird.
I guess its just luck the addresses coincide and it works.

Revision 5545

SPU2-X: Adding a log for bad pitch settings, in preparation of changing current
behavior. (Need to check some games that do it first)

Revision 5546

VIF/VU: Removed all the everblue crap, found another way of doing it. As the
savestate bummp wasn't needed anymore, i've put it back again. savestate users
Baldurs Gate is still happy, so I'm happy :P
Um, hmm. Still a very random solution but better than your first attempt so I'm in favour of this I guess.
Indeed. Neither this or the vu delay things are correct behaviour, but together the same goal s still reached without the break in compatability so its all good :)
I had a remark here about the word compatibility but instead I'll just report all affected games working. Good job :)
Screw you hippy :p
Don't call him a hippo! He's now a certified maths genius!
So ive heard! Although pete bernet (guy behind peops) was also a hippy, so its not a bad thing!
Hippies are alright :p

Revision 5547

GSDX: Mask off high bits of calculated GS memory addresses, untested but
probably what happens with real hardware. Fixes crash/memory corruption on
starting Fatal Fury Battle Archives Volume 2, hopefully some other games too.
Good work, game starts up now and seems to work.
Nice work! Battle Archives 1 + 2 now boot without resorting to arcane rituals or blind luck, as does the Art of Fighting Anthology. The only slight issue that remains is that the tops of some of the logos are still cut off.
Yeah, we noticed that one as well. Also Street Fighter Alpha Antology now crashes on my machine, which is probably just bad luck.
Boo, put parenthesis please..
"a+b+ (c & x)" or "(a+b+c) & X"
No. Learn operator precedence please.
Burned :p
I think it fixes Last Blade 1 + 2 too! So all these 2D fighting games have the same problem?
BTW can someone close issue 1130 for me? Thanks.
I'm in no rush to close issues because this may not be able to stay. It's incomplete (there's a lot of other code that calculates addresses) and in its partial state it seems it breaks a lot while in its complete state it may be unusably slow (and may still be broken this is a logic free zone).

Revision 5548

GSDX: Committing pointless extra work for the record before reverting.
Everything is terrible.

Revision 5549

GSDX: Nothing is fixed, the last two revisions did not happen.
Rough day? :P
You are awesome.
all of you :)
I enjoy reading and cheking all the commits more than testing ps2 games nowadays.

Revision 5550

gsdx-ogl-wnd: trunk sync: merge of r5497 through r5549
goal was to get the Nvidia glsl shader fix
nice improvement, colors are a lot better, more graphics are displaying, some textures are still missing though (only tested ff12 and bios so far).
Thanks for testing this konajona :)
Thanks for the test.
Not too bad, when you know the difference is a single "u" character ;)

Revision 5551

GIF Unit: Gave it some timing, kind of. Well the APATH and OPH flags in GIF
Stat will now pretend it's transferring anyway, this makes games that read these
flags and expect to see them busy very happy indeed. (187 Ride or Die as an
I'm expecting something to break, it's my code, it's bound to. But i have tested
some 40 games without problems, so my hopes are high!
That's the usual progression with PCSX2: Someone implements a hardware unit as per specs and it doesn't work as it should. Someone else tweaks the surrounding code base to better match what games expect. In the end we hopefully get the result of more games working.. So far this worked out :)
SSX3 Fails to load past firmware. No errors in log. Simply just a black screen. I will check through previous builds and let you know if this is just this revision or not.
SSX3 is confirmed operational in build 5549.
Cool thanks ill check that :)
Good to hear Agent Under Fire is working :) (I did know this actually, but I'm not sure when it was fixed.)

Revision 5552

Gif Unit/VIF: Fix up some bits from r5551. Fixes SSX 3 and Charlie and the
Chocolate Factory.

Revision 5553

VIF: Hack for Dynasty Warriors 5 Empires. Completely harmless hack to make sure
we aren't still waiting for PATH 2 data after a VIF reset. Something really odd
is going off with the VIF packets in this game (probably SIF or something), but
until we know what, this'll do.
Bosit will be happy :p
I don't play the Empires series but w/e :P
Well, it fixes all these games, including the one I debugged one time :p
excellent ;p were there more Dynasty Warriors games with the same problem then?
Awesome, just posted about this not too long ago!
I've tested them all except Special but only this one seems to freeze (so early into the game anyway)
Finally I can play this game!
Thank you a-freaking-lot!

Revision 5554

Make dev and debug builds report "PS2DVD" disks instead of CDVD_TYPE_ILLEGAL.
Need this for homebrew which wants to read disks.

Revision 5555

GSdx: Added a crc hack for Steambot Chronicles, made by miseru99. It doesn't
look perfect but at least it's rather playable now. Thanks miseru99 :)
Just a note for those reading comments, but not checking the code - if it's slow, you can try Agressive CRC in gsdx hacks(larger traffic can be somewhat demanding anyway, but usually this increased fps by 5-6 times for me).
Also shop submenus will most likely show as black screen couse some bug from r5072 in hardware rendering, soo have to switch to software there for now.
Please check my post here:
Without that line I mentioned in my post there the shadows get totally broken and who knows what else. @[email protected]
Sorries for not noticing that earlier, I continued to test the game on my own build just a bit couse my other hobby/life took more time(;c) and checked latest svn with the game just today while checking that blackscreen bug.QQ

Revision 5556

GSdx: New hack from KrossX lets users configure their own texture coordinate
offset via hacks dialog. This can be used to fine tune correction of upscale
glitches versus the problems that come with it. I guess this is able to correct
nearly all ghosting and bad text issues games can have! Thanks for this nice
patch, KrossX :)
Excellent! :)
Yay! Bugs! =D
It wouldn't have been a patch of mine if it didn't have one.
1 line-by-line comment
line 207:
207: #define TC_OffsetHack ps_params[5]
Should've been
#define TC_OffsetHack ps_params[6]
So why is it working? :p
Ah right, different shader model. Committing fix.
Dx9 is so forgettable nowadays. =P
Does it also affect black lines which are result of upscaling?
You can test it out :)
Coordinates for Tekken Tag Tournament?
Wow Excellent Update! Using Dx9 (Hardware Mode) and setting texture filtering to half option, I can use the values 0500 0500 on Atelier Iris 3 Grand Phantasm and the FMV files play without the vertical lines when running at 6X Native. It also fixes the character portraits in the game. Same values work to fix the vertical line in the FMV of all the Dot Hack games but for those you have to disable texture filtering :( so I will just stick software mode for FMV files in those games. Still really Excellent update !!
i tried death by degrees,which has black lines problem due to upscaling,unfortunately i wasn't able to affect it with this.
But good work still
The value of 0 500 almost completely fixes
bad text issue in Tekken Tag Tournament.
However you still need to use custom resolutions
like 1200 x 1200, 1080 x 1920 etc
This revision breaks the loading of GSDX ini settings on emulator startup for DX11.
The plugin will default to some strange values (inter alia no texture filtering) until the settings dialog is opened and closed. At that point the chosen settings will be properly applied, and will hold until the emulator is closed.
The issue presents itself only under DX11. The exact same ini settings will be properly loaded if the video backend is changed to DX9.
Also, the issue presents itself ONLY during normal emulator startup. If a game is loaded via a savestate made after applying plugin settings, all will be fine.
I have verified this on several machines (windows 7 and win8), using this revision as well as 5605 (latest at the time of writing). I used Orphis's buildbot as well as my own compiles just to be sure. For testing I used Devil May Cry 3, as the lack of texture filtering is especially obvious in this game.
I've been reading the GSDX code for several hours now looking for possible causes, but the issue is more complex than it would seem (and I am not really familiar with GSDX pipeline).

Revision 5557

One more patch by KrossX:
Should fix the VS2012 project files for when only VS2012 (and not VS2010) is
Yes! Thanks.

Revision 5558

GSdx: DX9 hardware fix for the new hack.
0500 0500 fixes vertical and horizontal black lines in zatch bell mamodo fury at 6x native if texture filtering is turned off, but game still slows down during no gameplay sequences.

Revision 5559

GSdx, SPU2-X: Remove old code and disable a now useless warning.

Revision 5560

Path3 Masking: Fix up some timing issues (now we have some lol) which made
puzzle quest look even worse than it already did. also as a test i have enabled
Intermittent transfer modes on GIF, however it's only very loosely working as it
should, just enough so Puzzle Quest looks right.
If it slows things down too much (initial testing is showing minimal slowdowns),
then we can always disable it again.
Any slowdowns would be in those couple known path 3 masking issue games, right?
I didn't see any speed hit anywhere yet and yea, Puzzle Quest finally working :)
Yeah, I tested the worst offenders, nfsmw and destruction derby
it looks like u fixed sly cooper nice
what was wrong with sly?

Revision 5561

microVU: Fixed linking on branch delays. There may still be some situations that
don't work correctly, but i don't have any games which use it, have ammended
console logging to inform us if the game is broken.
Fixes in this commit:
-Evil Dead - Fistful of Boomstick - Now goes ingame and works right (needs
software mode on gsdx to fix lighting)
-Tony Hawk's Project 8 - Graphics are no correct. Like earlier TH games, you
need Negative rounding to fix it all.
-Mark of Kri - The game now has collision detection! Apparently before you'd get
stuck on objects, now you can walk freely.
Great work here, let's all hope for no breakages :D
No correct? Now correct! Sorry :p
hey, just wondering can you fix crash bandicoot the wrath of cortex, level seashell shenanigans, theres a stange square on top left that flickers and its very noticeable, iv tried the skipfiles setings and other tweeks but nothing works, hope you can fix this please
its a gsdx problem, software mode is probably your only fix.
yeah software does sort the glitches, but software looks very blocky, it needs some sort of anti analyzing and resolution select, it only runs smooth when i use the speed hacks aswell for the software modes
you can't have a resolution with software mode, that's not how it works. As for anti aliasing, it possibly could be done, but it would be very slow and it's slow enough as it is. You do have the option of AA1 which is the PS2's own anti aliasing, but it doesn't do a lot.
And anyway ps2 games were blocky.
You cannot fix what is already right.
yes good job
Mark of Kri are playable now !!!
but the screen are little shake..
press F5 till it stops shaking then ;p

Revision 5562

Multiple cheat files and WIP: widescreen cheats
1. Multiple cheats files (at the "cheats' folder) can be loaded, as long as they
begin with the CRC and end in '.pnach' (e.g ABCD1234.Persona4(EU).god-
2. Multiple cheats are also loaded from the Widescreen hacks folder
('cheats_ws'). File names rules are the same as for normal cheats.
TODO: Add config and GUI for widescreen hacks. Right now the cheat files from
cheat_ws folder are loaded if cheats are enabled. We need a separate config for
Thanks to dlanor from the forum for his filenames wildcards patch:
Ah great, that was quick :)
Also thanks for taking care of dlanors patch.
Nice. :)
It'd be really nice to have a database of known widescreen patches (pnach and maybe elf ones if possible), and having these applied automatically (with an option to turn on/off of course).
Note that if there is a hack-conflict between patches,
the hack from the patch first in alphabetical order is applied,
and that the hacks from the patches in "cheats_ws" is applied over the ones from the patches in "cheats".
The output in the "PCSX2 Program Log" is be a bit unclear about this.
Yes, it's possible that items from one patch will overwrite some items of other patch if they modify the same addresses etc. It's the responsibility of the user to not use "conflicting" patches. Same goes for the widescreen patches. Just make sure they don't conflict, and if you don't know, just use one at a time it.
There's no proper solution for patches which modify the same memory addresses anyway. One of them just have to be applied before the other, making the first modification moot where they overlap.
With great power comes great responsibility ;)
It's crazy how quick we went from FFX widescreen to hundreds of games and a revised PCSX2!
Well, widescreen hacks are pretty cool and useful, so supporting them seems like a good idea :)
I got some issues related to the loading of Cheats on linux.
1/ EmuConfig.EnableCheats is always false. Why the test isn't based on src.EnableCheats? I check the ini file and I got EnableCheats=enabled.
2/ Where is set gameCRC? For me it is always "" or I miss something
nevermind for 2. It is set by the gameCRC.Printf...
I found 1 too ;) Sorry for the noise.
Would be possible to drop the .pnach extensions? IE load every file that are "CRC*". Linux support case, some people bugs me because they used .PNACH...
well, wouldn't it be better to just make the extension case insensitive?
Ok. I updated the code to match (crc|CRC)*.* and then it drop the file if it doesn't match *.(pnach|PNACH)
It must be transparent on windows.

Revision 5563

Typo fix.

Revision 5564

microVU: Found another bug with double branches, when there is a conditional in
a JR/JALR delay slot it may have ended up in the wrong place. Unknown what it
fixes, if anything.
VIF/Path3 Masking: Put a timing break in on Path2 transfers, this gives it
chance to stop being busy incase it is closely followed by a path3 mask, which
caused it to go out of time. Fixes Sensible Soccer.
VIF: Fixed up a couple of typo's, which may or may not have done anything, one
which was not setting an offset if it stalled on 1/4 of a quadword, which could
have been disasterous if done by the wrong game.
yeah , great , sensible soccer are good playable
i test this game and this revision pcsx2
thanks and continue this amelioration ;-)
Nice Jobs
Was hoping one of these few revs randomly fixed the Ace Combat games, no such luck.
No luck with Dropship either. I guess it is a question of time. Keep it up guys. <:

Revision 5565

VIF: Put in a check to make sure VIF doesn't break during a FIFO write.

Revision 5566

microVU: Fixed 1-Op flag linking (hopefully) if it kills stuff let me know and
ill revert. Hopefully it'll help MGS2 a bit, but no guarantees.
This does slightly modify the behaviour of branches on E-Bits (end of program). According to documentation, this isn't allowed anyway, however we had code in there to make sure the flags didn't flush and you got the right version of it when the next block starts, however it's the end of a program, the flag instances all flush out anyway, so you shouldn't need exact matches, it will always be exact.
sorry slightly misworded, you got the flag instance as of the end of the block, rather than not flushing them (it wrote the last instance back anyway). If the programmer knew that the flags would have completed writing back at the start of the new program (as you'd expect within 4-5 cycles) it would probably bugger things up more.
Again ill keep an eye on things, so if you see "microVU%d Warning: Branch, E-bit, Branch! [%04x]" and your game buggers up, you know im wrong :P however i expect the correct behaviour for this to be an extension on evil jumps like so.
read first branch
read second branch (delay slot)
jump to first instruction (E-bit) (given exact match)
jump to first instruction of second branch (if taken) (E-bit Delay slot) (should be given exact match)
program end
Currently, even before my change, it looks like the delay slot from the ebit will be run from the first branch, not the second, so this behaviour will have to be modified. Need a game to test it though :/ or of course we could write a PS2 test (pseudonym? :P)
Okay behaviour checked, looks like in at least the case of jumps (not branches) with ebits in the delay slot, its fine. Haven't found a scenario for the latter yet.

Revision 5567

microVU: Slight modification to yesterdays work. Realised blocktype 1 needs its
flag status's checking too.

Revision 5568

One of the automatic patches for GT4 causes TLB misses. Disabled it for now.
(EE full clamping, broke license test nr. 3 here.)
yes, now test permis in GT4 are correct
just bug in finish line in test Permis
just fix the little bug
thanks and continue

Revision 5569

microVU: Fixed random Unknown Opcode messages. Turns out the bios blanket
writes MOV VF00, VF00 and NOP (for lower, upper respectively) ops to the VU's on
boot, apparently some game designers new this and just left it being ran as part
of their programs. Our problem being is it was writing it to the VU MicroMem in
the wrong order!
All fixed now :)
hi, guy
test sensible Soccer 2006 , good games Arcade Football
just little Fix graphic bug in intro team country visage bug player
thanks and continue this fanstastic EMuuu
kiss from France ;-)
Oh, haha, that reason didn't occur to me but that might be it. I can't think of a specific reason for the instructions to be reversed though.
I find this revision cause a glitch in Final Fantasy XII(SLPM-66320,NTSC-J).
Program Log
The character is gone.
Well, then I guess that's not it. Maybe the BIOS is just _wrong_.
Right, FF12 NTSC is broken too. Too bad it wasn't this :p
I also found a problem with Seiken Densetsu 4 earlier but that game was kinda hackfixed before anyway. I think it was the reason for introducing the "bad opcode, exiting" behavior.
yep, know about this, looking in to it :)

Revision 5570

gsdx ogl:
* port KrossX patch from r5556 to openGL
* add a basic gui entry, would love an additional description
* also add the pointsampler hack but don't activate it yet
yeah good job continue !! ;-)
question for pcsx2 developper:
Next in Metal Slug 6 on PCSX2 0.9.8 are perfect playable
but now in pcsx is bad , my iso not boot the six game MS
WHY ? thanks for refix this game (Metal Slug Anthology)
i like the number Six MS ;-)

Revision 5571

Fixed up my changes from r5569. Change it so it only reverses the order during
the bios writes to VU memory. FFXII is fine again, games still not have the
unknown op problems, also TOCA 3 no longer has the illegal opcode errors.
I confirmed FFXII was fixed. Thanks.

Revision 5572

As previous commit - But check anywhere in the BIOS. It varies, the address i
used was for Europe 1.7 only >.<
Seems to solve the issues :)

Revision 5573

Updated zlib to 1.2.7. I skipped updating the CMakeLists.txt because ours is
probably set up to work with the rest of the project.+
This probably doesn't fix anything important.
A person from Japan notified us of this outdated lib. Thanks Pei Xia and gigaherz :)

Revision 5574

Implemented VI Backing up for branch instructions on the VU Interpreter. Fixes
Kingdom Hearts 2 and possibly others when running off the interpreters.
Did not even know there was an issue with Kingdom Hearts 2.
Man you guys are the best, fixing fully playable games so
they are even more fully playable.Kudos! :)
there wasn't. but it didn't work in the VU interpreters.

Revision 5575

Decided after discussion amongst the team to let the BIOS bugs run wild. Altered
microVU to just ignore these problems and end silently (The real VU would
probably do this anyway)
Good decision.
I agree, it is probably the most accurate behaviour.

Revision 5576

Missed a log.

Revision 5577

cmake: remove useless line that failed to build on older cmake version

Revision 5578

zzogl-pg: use the red channel instead of the alpha channel for the block data.
Alpha channel isn't supported (normally) in OGL3 and later.

Revision 5579

revert previous commit r5578. Didn't work as expected on CG and didn't solve
radeon driver issue neither.
:( Better luck in your next fix mate.
please remove freeze in enthusia racing in mode : free racing
the game in order ready racing and freeze
please developer ;-)
fix it rapidly

Revision 5580

GSdx: Committing a fix for the Steambot Chronicles hack, thanks miseru99. Also:
using a new alias, yay :p
Thanks again;3, and grats for the first commit with new alias(what sorcery is this?;p).
Don't ask :p
I know how you feel :D

Revision 5581

cmake: update wx-config option order for fedora

Revision 5582

CDVD: Corrected logging output for sector being read for DVD/CD reads. It was
reporting the sector it was currently at, not the one it was actually reading.
I just found a library that can be made use of instead of writing in support directly, here's the url:
I wasn't actually looking for it but figured might as well mention it now I found it.

Revision 5583

microVU/VU Int: Implemented T-Bit/D-Bit handling on microVU.
-Dreamworks Over The Hedge actually requires this to load. Interpreter kind of
had it right, but didn't stop the VU on these flags, causing the graphics to
look bad and hang on the start button, works fine now.
_fastcall is required? Really?
kind of, it changes on how you pass the parameters from the recompiler. I "think" (if i recall) if you don't have it fast call, you have to push them in to the stack or smth... but fastcall, you can just put the params in ECX and then call it.
But yeh, if you take fastcall off, it no worky no more ;p
Yep, fastcall is defined as using two regs for the first two parameters, where cdecl and stdcall use the stack for all the parameters. If the VU recs need fastcall or not, no clue.
That said, I don't think linux gcc supports fastcall, so I'd suggest pushing and using standard cdecl instead ;P
Ideally I think the recompiled code should just set a flag and recMicroVU::Execute should set the registers and call hwIntcIrq.
Thats another way. I wrote this at 3am so it seemed the simplest option :p we use fastcall elsewhere in mvu so it should be ok with gcc
also supervu is doing the same thing so this probably helped there too, i really don't want to change supervu.
SuperVU is being phased out :p
news to me ;p
GCC is fine with fastcall (didn't compile this version). Fortunately for me :p
this is probably what fixed the KH Chernabog battle crash ( Issue 1330 )

Revision 5584

MFIFO: Just over the top of the ring buffer is not classed as in the buffer
(reaching the top is masked anyway). Fixes DDR X and Supernova games.
Bug was introduced between r4034 and r4039.
Breaks Front Mission 4, sorry :p
Oh ffs :p I knew that would happen! Checking later

Revision 5585

MFIFO: Added protection on MADR when it is on the edge of the ring buffer when
setting the DMA Tag where the data follows the Tag.
Fixes Front Mission 4.
Fixes FM4 again. I also ran a round of FFX for good measure and no problem there either.

Revision 5586

microVU: T/D Bit handling. Improved it so it doesn't kill the BIOS.
Also adjusted the bios bug handling, there were reports of our new handling
breaking a game called Triggerheart Excelica Enhanced, hopefully this should
make it work again.
hmm... don't think that's right still, mVU still ends... curious if anything breaks though.
oooh thats why the BIOS works. I stopped D bit stopping *facepalm*
im gonna negative this cos i've obviously buggered this up
I'm sure you're enjoying this :D
grumblegrumblegrumble ;p
This is SO easy to do, if it was done at compile time. But it's not.. ;p
johncroft2580: After your behaviour, no, we aren't going to fix your damn game.
If you want to get on our good side use the ISSUES section to report a problem, don't just spam any recent comment in effort to grab a developers attention. The comments are designed for discussing THIS commit, not what problem you're having with some random game. THAT is why we are deleting your comments, besides the attitude.
lol, the only bad attitude is from yourself, am not wasting my time with this bullshit any longer, its not just me with the problem, its been mentioned time and time again over the past few years and nothing was said or done for others either not just me, and yet the games that are being fixed people can get on the pc anyway, so whats the point in emulating them, its stupid, and dont worry i wont be bothering with this emulator any more, just purchased a ps2, its alot less stressing than this slow drag of a emulator
so you just admitted being a pirate as well as an arrogant sod who seems to think we owe you something? We do this for fun, we don't give in to peoples demands, we do what we want to do, when we want to do it. Pay me a wage and i might consider doing what you ask me to when you should about your game not working.
enjoy your PC version of Kingdom Hearts and FFX and Crash Bandicoot, oh wait, that's right, they aren't on pc ;)
Wow, I can't belive people like that sob lives in this earth.
Nevermind guys, I've been following your project for years now, and I also support you with whatever I can, translating guides. Just keep up the good work.
Don't waste your breath atia. This child lacks basic basic communication skills and will have a long life ahead of him. Don't feel bad for these self-entitled types at all.
PCSX2 is one of the best emulators out there and loved by thousands. If he doesn't appreciate what it provides all of us (free of charge), then his brain is just incapable of processing basic information.
as usual: Ignore trolls and retarded people and do stuff at your own pace.
It might not look like it, but i check the SVN every day and it warms me up to see any activity going on (even if it means breaking stuff at times).
You are doing a fantastic job, keep up the good work :) .
[Shadow Hearts] this rev introduces massive spamming of this error "microVU1 Warning: Exiting... Block contains an illegal opcode. [1f30] [014]
" in fights, the latter number differs sometimes
just thought I'd mention this. Also I have random crashes on hardware rendering in this game (when not in a fight) Q.Q
Only i am allowed to pick on refraction!

Revision 5587

- Fixed up the T/D Bit handling properly this time (or at least much better).
- Moved the interrupt outside of the recompiled code.
VU Interpreter:
-Fixed the T/D Bit handling when the interrupt wasn't enabled.

Revision 5588

GameDB: Corrected Serial number for Ski Alpin 2006, should have been SLES-53867,
was SLES-53866 which is actually Over The Hedge.
Thanks for spotting that Nik1895 :)

Revision 5589

GameDB: Found and removed 4 more duplicate entries.

Revision 5590

microVU: T/D Bit on branches fixed, kinda. It's ugly, possibly wrong in places,
but it works for known games that fall for this. Fixes VP2.

Revision 5591

microVU: Made the new logs mVU logs for Rama <3
Aww, you shouldn't have :p

Revision 5592

microVU: Another branch delay slot fix. Extreme-G Racing now playable in microVU
If anybody has Mark of Kri, can you please confirm that's still working okay?
I'm expecting it to, but just to be sure.
Mrk of Kri works fine on the first senario,though I played only a few seconds , is it sufficient enough to prove that the mircrovu works as expected?
Thats perfect thanks!
It caused :
Fix graphic on monster rancher 3 on normal vu clamping on item moak soup (usually use extra vu clamping to fix it)
Fix ground on warrior orochi 2 and super dragonballz that sometimes give bad graphic
Break dynasty warrior graphic on extra vu clamping (usually both normal and extra vu clamping is ok)
But i prefer this svn
billyash: im confused.. did this fix that stuff or break that stuff? and can you confirm which revision it was exactly that did so.
I test using R5592
Iam sorry let me correct for dynasty warrior, the right one is dynasty warrior 5 empire
Break graphic if use extra vu clamping (it usually ok both extra and normal vu clamping) normal vu clamping is fine ;)
As long as one clamping setting is fine on those games, im happy with that.
Yes, im happy too cos use normal vu clamping is faster than extra vu clamping :p...

Revision 5593

microVU: Save PC when processing T/D bits on branches, this is to ensure the
rest of the block gets compiled correctly. Could have been the reason VP2 was
freaking out after loading a save.
Hey refraction in revision r5590 if I a just start a normal
game of VP2 from the beginning(NTSC USA VERSION) then
skip all the cut scenes the game just goes to a black
screen and no further. Does this Revision fix that too?
Quite possibly, try it ;p
Yup it really does fix it. Thanks for the response.
I am hoping one day that pseudonym or someone else
will be able the work out the few remaining
graphical bugs in the game like in the lost forest,
but even if that never happens
you guys are still the best.
There is so many problems with the forest scene effect that it'll never work correctly in hardware rendering. We would need more control over the GPU pipeline to emulate this.
Wow! See this is why you guys are the best!
I got a very candid and concise explanation
and I did not even ask a question.
Thank you rama !! :)
I don't like to say never but if I remember correctly it is one of the harder challenges.
It uses bitmasking, has issues with scaling or even correctly detecting the type of the texture and iirc it can't do the blending correctly :p
And sorry for hijaking your commit log, ref :p
i forgive you, this once :P You could at least leave me a + :P
He's lazy. Here's your + :p
good work
Lol thanks avih :p he owes you big time!
Tekken Tag Tournament stopped working :( Doesn't load intro screen :/
Dont think thats this build?
for me Tekken Tag Tournament are working
great release and continue
thanks ;-)
Tekken Tag works fine here. It did initially crash, not sure why, but i did a full boot, that was fine, then did a fast boot again and it was fine. strange but it seems fine ;p

Revision 5594

microVU: T/D Bit cleanup, slightly better code, makes much more sense to how the
PS2 does it. Fixed ICO's graphics.
Break vuclamping normal on moak soup monster rancher 3. (in r5593 normal vuclamping was ok )
does any other clamping work? because if it does, i don't care ;p
it used to work with extra vu clamping, can you check that again?
Yes, extra vuclamping work :).
Then can you take the negative off as this revision didn't actually "break" anything, it just restored the original behaviour before my commit previously (which did actually have bugs in which might have caused it)
Could you work for dynasty 6, the screen become black and stop when choose ling tong on mosou mode after narrator tell story? Please :) . I really love dynasty games :)

Revision 5595

Include dev9ghzdrk into the main plugins folder, and integrate it into the build
system (windows only).
Most of the work done by Rama, I just integrated the vcxproj.
Only done for vs2010, vs2008 or vs2012 will have to wait.
There's something nice coming up regarding this..
And thanks for your help, gigaherz :)
nice but i don't have vs2010.
i need vs2008 plox :) .
Interesting... ;3
Is it the old Dev9Giga? If so thats great you are supporting it.

Revision 5596

DEV9ghzdrk: These files aren't needed.

Revision 5597

DEV9ghzdrk: Either be thread safe in the whole plugin or don't try to at all.

Revision 5598

DEV9ghzdrk: Fixed the bad slowness.
Good to see some work on my favourite plugin. :)

Revision 5599

Added WinPcap to the library of 3rd party includes and made DEV9ghzdrk use them.
WinPcap version is 4.1.2 and only the /include and /lib folders of their
developer pack are included.

Revision 5600

DEV9ghzdrk: Re-enabled the stack init hack, fixing GT4 network use.

Revision 5601

Changed the stack init hack so it is consistent on plugin resets and removed a
part of it that broke OPL.
Hopefully this works for all use cases, but we should fix the initial problem

Revision 5602

Added Visual Studio 2012 solution files for DEV9ghzdrk and avoided a macro
redefinition error in WinPcap when that compiler is used.
VS2008 is harder to do as there is no automatic downgrader tools for the
solution files, sorry.
meh i don't think anybody uses 2008 anymore anyways, it's been superseeded twice :P
Happy there's a VS2012 project now!
i still do so i still need that 2008 project update. :/
All the rest of the solution is still compiling on 2008. You'll just miss out on the dev9ghzdrk code.
Get the plugin from Orphis' build bot and you'll be fine.
yeah good idea or rather free idea because VS2010 or 2012 cost money XD
Glad to see u guys finally shine the spotlight on DEV9 emulation :).
Visual Studio 2012 express is free :P
express....bleh nty :)
but hey if someone gives me a good enough reason to update all my projects to VS2010 or 2012 i might consider updating.
I usually take the "if it works don't fix/change it" approach.
I think the reason is just that with new versions you get better compiler / linker, at least i hope.
Better performances on newer hardware.

Revision 5603

* bump minimal requirement to opengl 2! Basically any Dx9 class hardware. On
intel you will need a gen4+ GPU.
* remove the bad quality integer texture to use only texture float. Again need
an gen4+ Intel GPU. Opensource users: Mesa must be built with support of texture
float (stupid patents)
What does gen4+ mean?
Gen 4 are latest GMA ie GMA X* and GMA *4500*
From steam stat: 1% of users but probably 2D games (vertex shader are emulated on the cpu!)
Clarkdale and Arrandale : gen5
Sandy : gen 6
Ivy bridge: gen 7

Revision 5604

microVU: Reverted original Xtreme G Racing 3 change as that was a hack, found
the real problem. Evil jumps on E-bits, could it get any worse????
Not exact behaviour. The vu would actually run 1 more instruction, bu due to how microvu works, his would be very difficult to emulate correctly.
Wow typing on my phone really sucked... lol. Missed half the letters >.<
Yes I noticed LOL :OD - Keep up the great coding my friend!!!
I don't know but games look less pixelatte than before on native, but i like this svn :)
billyashudhis: I don't know why you'd think that, it's impossible :P
"Wow typing on my phone really sucked... lol. Missed half the letters >.<"
Do you think is that revision's fault?
Could be :p
Do you know ? I always online using phone. googling,chat,write in forum,etc .lol :d

Revision 5605

GSDX: Applying patch for 2 small errors in GSDX provided by mathew1800.
Thanks to KrossX3 for aiding our laziness:P
Before anybody asks, I'm 100% confident this will have no baring on emulation. This is literally device capability detection and a GUI potential breakage/memleak, nothing more.
I brought it up for review but sudo was afk. I blame him :p
yeh, they weren't huge issues tbh, but obviously OCD is strong with someone xD
I knew it would help. =3
Oh right um, I reviewed, approved and thought for some reason it'd already been committed.
I expect nothing less than a tri-head monkey from this commit /joke :P
no monkeys here I'm afraid ;p
i should negative this for this debacle
im feeling generous so you get a neutral :P
Fix weird line sprite fighter on capcom fighting evolution
Billy, you're an idiot :p
Sorry coz that was fast test. But when i continue to other battle place in dynasty it wasn't fixed :d. My bad
I even put the first comment saying this will not fix any games
Derp! *facepalm*

Revision 5606

Game Index: Changes made by pgert, mostly naming changes, added what i believe
is a second disc for the US version of Persona 4 Serial: SLUS-21782B to auto
enable VU Clip Flag Hack.

Revision 5607

gsdx ogl: install a GLX error handler before the context creation. Allow to
print a nice message when the user doesn't support opengl 3.3
Not exactly related to this revision, but I'm not able to build svn version of PCSX2 in Arch Linux. Build log: http://paste.archlinux-br.org/2121 - any help appreciated
gcc 4.8 ? Didn't try this one yet.
Try to remove the function __rdtsc in plugins/GSdx/stdafx.h (from line 437 to line 448)
stopped complaining about __rdtsc, but still fails at the same point: http://paste.archlinux-br.org/2125
Just to be sure
You must delete all lines completely:
_forceinline unsigned long long __rdtsc()
} (include)
Oh, now i get it. Still fails, later: http://paste.archlinux-br.org/2127
you have another reference to rdtsc in GSRendererSW.cpp line 552
oh and line 577
Can you build PCSX2 with gcc 4.7? I will look gcc 4.8 when debian release it. That said gcc choke pretty badly with an internal segmentation fault. We might need a gcc bug fix release.
I was able to downgrade GCC 4.7.0 and to build PCSX2 without issues. This won't help much as Arch is a rolling-release distro and everyone in there have GCC 4.8.0, but I still can suggest downgrading it in order to build PCSX2. In the meanwhile, we'll wait for the fix. Thanks Gregory and refraction for the support!
Now buildbot is not working?
build bot is fine.
Then it was the web page that didn't refresh for a few days for me. Thanks.
Rafael can you test r5618.

Revision 5608

microVU: Fixes to D/T Bit handling and XGKick Delay
-Elemental Garde - Fixed up D-Bit so it remembers the microVU state when
recompiling, this fixes the bad geometry that was introduced with T/D bit
-WRC Rally Evolved - Changed the XGKick delay to an increased number, solves all
remaining SPS problems.
-Crash Twinsanity - Increased XGKick delay resolves geometry issues on Crash,
thanks to Autoran1 for debugging this :)
GameDB Changes: Added XGKick hack to Crash Twinsanity auto gamefixes, checked
the main entries for the others above have it too.
We might want to see if any games have issues with the xgkick hack permanently on.
Might be a thought, left a message on irc :P
Got it.
Could this possibly work for ace combat geometry?
Theres nothing wrong with ace combat geometry. That judt needs mipmap support which is only available in software mode (f9)
Well so that's just me being foolish that it could fix the totally messed hit detection in ac5: unsung war. And yeah, I'm playing software, black bars kill wihout it
Wait a minute, is AC5 collision detection fixed ??!? (O_O)
No. He meant the texture issues
Too bad. Ace Combat 5 is the best game in Ac series, I wonder if this collision bug will ever be fixed.
Hopefully one day, but we don't know what the issue is currently :(
didn't someone mention that it could be a VU or delay slots issue awhile back
...could be me just remembering wrong.
Ace Combat 5 doesn't do anything with delay slots, so i seriously doubt it's that ;p

Revision 5609

GameDB: Added Siren 2 to the list of XGKick hack games. Should make it playable
now as per the result of Issue 1054
Thanks for testing IceLancerSR :)
Afaik this game has been requested for ages, so should make some people happy I hope :p
Im hoping so :P

Revision 5610

GSDX: Disable a buggy vertex tracer optimisation in GetTextureMinMax (produces a
rectangle with a negative dimension leaving it still empty after the follow
block which is likely a hack itself). Fixes textures in Kingdom Hearts 2's tron
Actually the comment about zeroing and tw/th not 0... should be not 32, which isn't even valid, so yeah. I have no idea what that code was meant to do but it's not doing it.
Hmm, actually I did misread it, those variable names confused me. I now think I understand that part in isolation.
Now I've actually taken the time to try to understand it, the code makes sense. It must be wrong though, debugging is needed.

Revision 5611

GSdx: Fixed a missing clut offset which broke Disney's Golf.
Good find :)
Not exactly right, but there's a TODO comment for what actually needs to be implemented.
The whole palette buffer is used, there can't be an offset, the problem must be somewhere else.
There's no such restriction as far as I know, CSA only has to be 0 if using CSM2 (and unless you've tested what happens with non-zero CSA in that case the question of how to emulate it is open).
That's true, it is just not defined what happens when the addressing goes beyond the 1k clut buffer. Probably wraps around, but need an good example to verify it. I've already found this game, gonna check it later.

Revision 5612

GSDX: Fixed GetTextureMinMax's vertex tracer interaction properly and added some
It wasn't the suspicious code, that actually seems to be correct. The rempty()
case should now be unnecessary except in case of bad register settings, but
that's outside of our control so it needs to stay until code's added for that
case. A console warning would be appropriate.
Getting the used texture area for repeating textures is tricky, but the less data to fetch the faster it is, we can't just ignore the opportunity. Does anyone have a gs dump to demonstrate this bug in KH2?
This version of the code is not "ignoring the opportunity", it's identical to your code except the intersection is (correctly) with vr, not the unclamped tr. But I'll send you the dump anyway.
Thanks, I'll check it out, it was a long time ago, I have to re-learn what is happening there :)
I can see the problem now. The used texture area reported by the vertex trace and the clamp region do not overlap. The actual texture data is only present between 16-144. I checked the vertices manually and the trace is correct, m_vt.m_min.t.x is just above 145. This fix "uv = uv.rintersect(vr - GSVector4i(0,0,1,1));" is doing the full coordinate clamping, but I think it might interfere with the repeat modes later, when the modes are mixed, clamp in one direction, repeat for the other. It should just be done under case CLAMP_CLAMP/CLAMP_REGION_CLAMP, in the next switch. Currently vr.x is only checked against uv.x, and vr.z against uv.z, not both ways, that would limit such non-overlapping rects to the clamped area.
This code happens AFTER mask is set so it can't affect repeat modes. (Notice in the commented out code documenting the effect of mask I use uv_ rather than uv. uv_ was a copy of uv before the rintersect in my test code but that line got lost when reducing it to comments.)
Right, it is uv_, and commented out.
I went through all my old gs dumps (50+) and none of them had such a problem, kh2 is the only example for now.
I did take great care proving this function correct (if not necessarily optimal). I think it's fine except for the clamping region outside of the texture space case I mention in the comment below, which needs testing and handling. Not that any game uses that in all likelihood.

Revision 5613

GSDX: Implemented CLUT temporary buffer wrapping by mirroring writes and
hopefully fixed all CSA related bugs. There are fewer asserts on register
values in the code now.
I'm only about 75% confident in this code. Games might be broken.
How does this affect the mentioned games in comments (SFEX, Idol Janshi Suchie-Pai IV, Disney's Golf) where the CSA > 0? I think there were a few other games too, that either set it wrong by mistake or intentionally, with or without visible texture errors. Need to check some texture dumps.
Looks kinda expensive to copy all that data each time the palette is modified.
You'd think so but in reality it doesn't seem to be measurable and this is the simple solution (for GS memory as a whole, which certainly has the same problem but the implementation and standard usage masks the issue, this of course would not be viable).
Disney's Golf looks fine now and was the motivation for fixing this. SFEX also seems okay though I never found where if anywhere in that game there is a visible bug. I don't have access to that mahjong game for testing.
Can't see any changes in Disney Golf after this mirroring, already looks fine with 5611. Probably they don't use an index that would overflow. I might verify it later.
As I recall the reason it looks fine is that it was incidentally handled by
the overflow buffer, but that won't work for all cases.

Revision 5614

Cheat files: If no disc is inserted, treat CRC as 00000000 when trying to load
pnach files (previously, empty CRC would result in *.pnach wildcard, which tried
to load all pnach files).
Great work as always

Revision 5615

microVU: Parametrised D-Bit handling. This *Shouldn't* be needed in retail
games, but now it's working it could be useful for homebrew and testing. By
default this is now disabled, but can be enabled by editing the parameter in

Revision 5616

CDVD: slightly modified the way PCSX2 checks for oddly sized DVD's. Some CD's
weren't providing information as expected so it detected it as a DVD, resulting
in nothing but TLB misses.
Fixes Impossible Mission, possibly other games that do nothing but TLB miss or
fail to load an IRX module.
I vaguely recall something like this in a couple Simple 2000 games, unfortunately I can't confirm if they're fixed
can you vaguely remember which? I have a couple of simple 2000 games laying around!
Can't you guys be more precise? Sigh :p
One of the games was Vol.55 The Catfight, which I just tried in r5616 and seems to be broken (black screen). It's also broken in r5614 though. I was getting the TLB errors in r5326. In all 3 revisions the game is listed is playable, not sure if that's outdated or my rip is bad.
Fortunately V55 is one of the ones i have and yes it works fine here.
could someone test shadowman 2 i remember that always had tlb miss errors
shadowman 2 should be fine, i've never had an issue with that.
Shadowman 2 has bad textures and some SPS currently but there's no tlb misses anymore (I vaguely remember some in even earlier VIFs).

Revision 5617

DMA/Path3 Masking: Shameful hack to make Wallace & Gromit in Project Zoo work.
Game does something stupid, not sure how we will resolve it properly, but this
will be harmless to any games not using Path3 masking.

Revision 5618

* Fix a couple of GCC warning
* Fix build with gcc4.8 ( issue 1392 )
Built successfully (unable to test running pcsx2 at the moment), but FWIW I got some warnings in compilation time: http://paste.archlinux-br.org/2136

Revision 5619

Soundtouch update from 1.5 to 1.71 as per patch from lincolnh_br.
There's been changes in the VS2008 project file which we may want to look at and
port to 2010/2012 separately but it builds like this in 2010 here.
I want to wait and see if there's any issues with Linux first, too.
Thanks to lincolnh_br :)
buildbot seems happy, so thats a good start :P
Don't worry for linux. We don't use anymore 3rdparty (hopefully for me) :)
Great, I keep forgetting that, don't I? :p
I would say that you're cautious ;)

Revision 5620

gsdx (ogl):
* Use bigger index for Uniform buffer to avoid any collision with sampler.
* add a new config to disable openGL 4.2 requirement. Would be done at runtime
Hi There,can you guys check out "DT Racer" if possible.
I wanted to test that out and emu completely locked up.
I'm not sure how to report issues so forgive me if not doing it correctly.
Nate, try clicking "Issues" on the navigation bar. ;)
Having said that, my highest interest in PCSX2 is for proper DT Racer emulation. I've had a pent-up desire for wonky physics ever since my disc became irreparably scratched (luckily after I made a backup).

Revision 5621

GameDB: Updates by pgert.
-Added patch for Drakan (SCES-50006) to improve the corruption problems when
using resolution scaling.
-Many comment modifications and console comments explaining that BIOS boot is
required for correct language selection.
Thanks for the updates :)
Can you please add "EETimingHack = 1" line to all PAL versions of Mafia? It works exactly same as NTSC version.
we can do. need to add it for true crime new york too
Thank you. This will make things easier :)

Revision 5622

(Patch by KrossX): Fixed multitap (e.g. Timesplitters), New: support raw PSX
memcards (mcd/mcr), Fixed issues with pad 2 (e.g. issue 1326).
- Also, I slightly modified the default column widths at the memory card config
- Tip: If the column widths are resized, the new widths will get saved after
clicking OK/Apply, but NOT if clicking Cancel or closing the window with [X].
Oops. The actual changes to the sio were not part of the patch but rather provided as discrete files (and have a lot of changes), which I didn't include here.
Expect some followup soon.
My tests of the v7 code were all positive so far. You could just commit it, imo.
The rest of the patch, updated to v9 is now at r5703.

Revision 5623

GameDB: Entries for Mafia and True Crime - New York. Helps with bad textures in
True Crime, not sure what it's needed for in Mafia but apparently it is (was
already present on NTSC version)
True Crime (PAL) still dies on the main screen btw (with VU errors), it's not affected by any of the gamefixes.
You have to use SuperVU. microVU is broken in this game somewhere.
Thanks for adding it so quickly. To clarify Mafia needs the hack or it gets stuck after intro or when loading mission.
Game still shows heavy texture problem even with the fix activated. Log says (1 patch), but I still need software mode to fix the broken textures.
Thats a different issue. As I said it helps, but yiu still need software mode and supervu. If you dont use the patch, software mode is still broken
Software mode was fine without patch even before this revision.
Oh :/ my bad then :p
I tried it with PCSX2 1.1.0 revision 5620 and works fine (in software mode of course). Mine is the PAL version. It really runs good with minor fps loss.

Revision 5624

linux various:
* Try to launch dev/debug version when pcsx2 isn't found
* remove svn metadata from the linux tarball
* Add libaio on the cmake dependency message

Revision 5625

GameDB: Re-enable the Neo Contra IPU patch on the EE and USA versions as they
were in 1.0.0, seems it still needs it. Removed the True Crime EE Timing Fix,
apparently it doesn't need it! Software mode and SuperVU is enough.
Neo Contra Load On First Level Now? Or Not?
It may get a bit further but it's certainly not playable unless we actually find and fix the IPU problem.

Revision 5626

wiki: linux compilation guide: refresh dependency name and force the 32bits
version now that multiarch is supported on most system

Revision 5627

gsdx ogl: AMD fix some bugs in their driver ! (catalyst 13.4 branch). Let's
remove some buggy workaround now.
About time too ;p Do we know if there are any DX bugs they fixed? I know there was some calculation errors with AMD's, Pseudonym had a huge thread on it.
yes they took 1 year... When I sent them the bug report, I created a small testcase to reproduce the bug. I test it from time to time.
Good man :)
Good work :p
It wasn't meant to be a huge thread, people kept testing long after I said they could stop. I intend to leave the workaround in (but make it conditional on testing for the bug's presence) regardless of whether it eventually gets fixed
Unfortunately AMD opengl driver are very unstable. With recent driver update, my workaround create segmentation fault inside the driver... Anyway this dump driver still failed to compute the correct blending color. I think I need to reopen a new driver bug...

Revision 5628

Moved some stall related logs to DevCon(sole) as games that trigger them will
slow down.
Thanks :)

Revision 5629

gsdx ogl: use immutable texture, it would avoid multiple validation from the

Revision 5630

gsdx ogl: New config option to disable separate shader program. Not enabled by
* workaround AMD driver bleding issue (got at least a nice rendering in GoW)
* would run on the opensource driver when they support geometry shader
Stil got some crash on the driver. Arg!!!
FGLRX user if you want to do some trials
uncomment #define DISABLE_GL41_SSO in GSdx/config.h

Revision 5631

gsdx ogl: fix previous commit
* clean shader properly
* use a 64 bits map to contain shader pointer

Revision 5632

gsdx ogl: load shader from C code instead of an external file
* add a perl script to convert shader to char*
* By default use *.glsl file (handy to do some trials).
Only drawback, glsl2h need to be manually called at the moment
Looks to be a pain in the ass to maintain those header files.
Not to mention using perl.
Well the perl script is only a couple of line that said it won't work on window (I would need to fix separator).
The headers are generated by the script so you only need to call it when shader are updated. The other solution would be to install directly glsl file and properly set the path in gsdx. But my Window skill is very limited... Note: opengl doesn t support precompiled shader.
Ah, now I remember, the shader compiler is in the driver, so you can't include the binary like you would for directx.
How is the support for c++11 on the linux side? I'm thinking of using the new std classes to replace things like threads and locks.
Not too bad: here a summary
If possible I want to keep GCC4.7. GCC4.8 was released one month ago and it is not very stable yet.

Revision 5633

gsdx-ogl-wnd: sync from trunk (r5550 to r5632)
Note: Code need to be fixed with latest GSdx ogl additions

Revision 5634

gsdx-ogl-wnd: fix compilation error on linux

Revision 5635

* load extension as gl_Function instead of glFunction

Revision 5636

* replace both DISABLE_GL41_SSO and DISABLE_GL42 macro with a dynamic check
based on the extension support
* glsl2h: use static instead of extern
On Windows at least, PFNGLTEXSTORAGE2DPROC is undefined. The other defs in GLLoader.h are present in glext.h but I can't find any TEXSTORAGE there at all.
Thanks for the test. I didn't look at windows yet. I upload a newer version of glext.h. Let's hope it works better :)

Revision 5637

gsdx-ogl-wnd: update GL extension file.
Must fix some undefined in windows
That was kinda quick :p
For some reason GSdx doesn't know "uint" right now. Changing to int fixes that and the plugin compiles on Windows with MSVC2010.
Line 100 in GSDeviceOGL.h:
for (uint i = 0; i < 2; i++)
Cool. You're lucky, I got your feedback on my 10 minutes computing range before going to work :p
I will fix uint (better put uint32 to avoid warning) tonigh
Great :)
I tested the plugin on the BIOS and some FFX. Graphics are there but with the usual glitches. Notable logs are:
3.x GL context successfully created
Supported Opengl version: 3.3.0 on GPU: GeForce GTX 670/PCIe/SSE2. Vendor: NVIDIA Corporation
tfx.glsl (entry gs_main, prog 19) :
#define GS_IIP 0
#define GS_PRIM 3
Geometry info
0(158) : warning C7050: "gl_Position" might be used before being initialized
Fragment info
0(456) : warning C7050: "_t.xyz" might be used before being initialized
Fragment info
0(456) : warning C7050: "_t" might be used before being initialized
Also I noticed the PCSX2 FPS counter locked at 60 when a second monitoring tool reports a constant 120FPS. I'm getting the same with PPSSPP (also OGl) with buffered rendering enabled. DirectX doesn't do that.
mvc2012 GSdx doesn't know "uint" right now
I didn't expect any improvement on Nvidia side but it is great to know that it is still "working". Most changes were for AMD driver (now close to nvidia rendering :) ) and to reduce the requirement for the opensource driver.
I sync vsync is enabled. I got a TODO around the code :p
>> I tested the plugin on the BIOS and some FFX. Graphics are there but with the usual glitches
Rama, can you tell me how/where you get gliches on the bios? My driver crash when I used PCSX2 but it work with the GS replayer. So I can generate a .gs with the SW renderer and then replay it but unfortunately I'm not able to see the glitches...

Revision 5638

gsdx-ogl-wnd: fix compilation on MSVC201x
uint32 then, alright :p
yep, already got thousand of warning in gcc ;) One day I will need to seriously reduce them.
It joyful me, the OGL is now possible.
I know it is too early to test games realistic.
So I found out the Finalsantasy X2 German has a japanese intro screen :), even if not much else does.
Keep it up!

Revision 5639

* remove an old&useles dummy geometry shader (was used to workaround amd bug)
* use a basic X11 window for GSopen1
* redo the replayer: it is now based on dlopen rather than standard
static/dynamic library. AMD driver doesn't play nicely with the later...

Revision 5640

pcsx2 gui:
* handle cheats and cheatsWS folder like others data folders.
Note: I didn't add new gui entry but every configuration bits are here. Tell me
if you want addional entry
* replace folder name hardcoded in AppCoreThread with the new
PathDefs::GetCheats* functions
Does it fix the issues that came up on the forums?
not completely. It only fix the directory path. I still need to restore upper case CRC. Let's hope MS become case snesitive in the future :-P
By the way, what do you think to add some gui stuff to configure the folder (inside Folders panels like Savestate)?
If you're referring to the file system then that's not going to happen without changing the way the system works, there are many functions which rely on this case insensitivity to operate correctly.
But otherwise it's nice to know directories are not permanently hard coded.
He wasn't serious :p
Ah fair enough :D
rama tried the installer today, and found out that while the cheats and cheats_ws folders are installed to the install directory (on windows that's typically c:\program files\pcsx2), pcsx2 looks for them at the documents directory.
So this means that these folder are not accessible after installing pcsx2. I'm suspecting that this revision (r5640) broke it. With pcsx2 1.0, the cheats folder is installed to the install directory, but pcsx2 also looks for and finds it there.
On portable mode this is apparently not an issue since both install and docs dir are the same AFAIK.
So maybe this:
wxDirName GetCheats()
return GetDocuments() + wxDirName( L"cheats" );
wxDirName GetCheatsWS()
return GetDocuments() + wxDirName( L"cheats_ws" );
should be modified such that AppRoot() is used instead GetDocuments().
Hum, I think you're right. I don't remember but I probably tested only portable mode. It won't work on linux neither :p Is AppRoot working on Windows?
plugins/themes/langs use AppRoot(), so I figure it should work :)
Think you can fix it, gregory? :p

Revision 5641

pcsx2: fixed cheat loading on linux.
Nice find. So someone thought of the problem but used the wrong way to go about it?
Yes. Original code didn't test name != name.Upper() but retry when it failed to open the file.
At first glance code seem corret but wxString.Upper() return a string without any modification of the real string.

Revision 5642

pcsx2: support both pnach and PNACH extension (linux is case sensitive...)
can I just make a suggestion, since your using a file match thing why not go with L"CRC.*" then iterate through them getting a lowercase copy the extension to compare against so as to make sure the behaviour of this is the same as in windows - unlikely though it is that someone would set it to *.pNacH or something it is better to avoid the issue altogether since you only expect one kind of file in the folder anyway.
Either way I'm among the likely many who appreciate this change :)
I'll take it ".Pnach" isn't supported.
If you code was written in some kind of assembly (like MASM),
the case sensitivity could easily be managed with
"or al, 00100000b" which assures lower case (at least for A-Z).

Revision 5643

* fix wrong interaction when both GL41 or GL42 aren't supported
* Add a new define to downgrade opengl requirement to test the free driver and
=> As far as I can tell, they only miss geometry shader& GLSL150 (got GLSL140)
* Found a way to avoid crash in AMD driver. Skip the upload of small texture but
rendering is wrong now...

Revision 5644

* fix a bad interaction when GL_ARB_SSO is supported without
* try to replace struct with flat parameter in glsl interface
=> with some hacks of the free driver, I was able to compile SW renderer shader.
the rendering is broken. Maybe my hack :p
* remove EGL context check (wasn't working as expected)

Revision 5645

pcsx2: redo cheat loading on linux. Now it will be fully case insensitive.

Revision 5646

* Emulate Geometry Shader from the CPU.
* add some option to override opengl extension detection
* redo shader interface (again) to compile on the free driver
SW renderer is now working on the free driver.
To test it on your linux box use this cmake option -DEGL_API=TRUE
Note: (need opengl 3.0) I test mesa 9.2 git

Revision 5647

gsdx-ogl-wnd: Make the HW renderer "work" on the opensource driver
* replace most OGL_FREE_DRIVER with a dynamic detection. Remains the context
creation. Closed drivers need 3.3
* Add the CopySubImage fallback
Forget to say. It still require EGL ie -DEGL_API=TRUE. I will test GLX when I get a newer X server.

Revision 5648

* clean texture management & use different texture unit for various texture
* separate sampler and texture setup
* Always disable GL_SCISSOR_TEST before any cleaning to be sure the all pixels
are reset
* properly set upscale_multiplier in the linux gui (was mixed with msaa).
Unfortunately it is still broken...
* Fix EGL with GSopen1
* Use stdcall for function definition in the replay (avoid segmentation fault)
* Directly use gl_Position in shader instead of an extra user defined variable
+1 and a hope for progress towards hi-res upscaling in linux someday :)

Revision 5649

- changed the KH2 fix in GetTextureMinMax to my taste, should give the same
results, when the used texture rect is to the left/above the clamped area, it
returns [min, min+1], and [max-1, max] for right/below
- m_mem.m_clut.Read32 was returned to its original place from GetAlphaMinMax
- UserHacks_WildHack was moved up to GSState, special UV handlers are only used
when this setting is active
- updated xbyak to the latest available (avx2 seems incomplete, the 256-bit
promoted old instructions are missing)
- changed vtune's include path to the 2013 edition
Some other not yet commited changes from a year ago:
- WriteImageX overflow crash-fix
- moved colclamp after dithering (sw mode), it makes more sense, no visible
changes noticed
- Gif_Tag::analyzeTag(), there was a conditional I didn't like, split the loop
into two parts
So many hacks sneaked in in the last year :)))
welcome back gabest, i hope we can you here more often. ;)
Sorry for messing with your baby so much, we're just hammering it into what we need for PCSX2 :p
Hacks? Impossiburu!
That damned vtune again, update 8 says haswell is supported.
Error: PMU resources are not available. Hardware Event-based Sampling is not supported on this operating system.
VTUNE_AMPLIFIER_XE_2013_DIR modify VTUNE_AMPLIFIER_XE_DIR, as long as the user in the system variable, add VTUNE_AMPLIFIER_XE_DIR = VTUNE AMPLIFIER XE installation directory can, VTUNE_AMPLIFIER_XE_DIR soft link is VTUNE_AMPLIFIER_XE_2013_DIR
I noticed the directory links, but for me the generic VTUNE_AMPLIFIER_XE_DIR environment variable was not set by the installer. So, if I change it to VTUNE_AMPLIFIER_XE_DIR, it won't compile out-of-the-box. With VTUNE_AMPLIFIER_XE_2013_DIR at least there is a chance, if you have the 2013 version.
Or maybe you wanted to help me with the event-based sampling error? I'm not sure how that could fix it :)
Amazing, Gabest11 you are my legendary ps emulator video plugin. Im your fan :)
Stop disappearing damnit!! :P
Oo look whos back
He's like famous artist wich is waited by everyone :)
Now I'm just wandering if all these positives are just because of the code or maybe because gabest reappeared :D
Great to see you back gabest11. Hoping to see some good game improvements throughout whatever amount of time we have you back for.
Would love to see the split screen problems in Dark Alliance 1&2 + the other 2 games linked with that engine fixed as those are GSDX and not PCSX2 related (according to earlier posts by PCSX2 devs). But if not meh.
Eagerly await seeing what gets fixed either way.
Oh nice its Gabest:-), there are so many Changes in gsdx-ogl and now gsdx, also now i wanna know what is better with a amd HD 7790 Card?
And could it be possible to implement some Alternative Shaders in the Future?
Great to see KH2 glitch fixed, I reported that long ago. But I have found a new issue with this revision in Ar Tonelico: Melody of Elemia. Chests and items found on the ground pop through Lyner.
r5645 - http://img547.imageshack.us/img547/6296/r5645.png
r5649 - http://img14.imageshack.us/img14/4263/r5649.png
To be more specific, it only happens in DX9/11 hardware renderer and does not happen in software. But it did not happen in hardware before this update.

Revision 5650

* Fix shader alpha issue. Hoppefully fix lots of glitches.
* Use glBufferSubData to upload data into the constant buffer instead of
map/unmap. More fps :)
* Fix wrong api setup on EGL
* Be more portable on glsl2h
Is it affect on pcsx gsdx windows?
Except if I broke the code somewhere :p
No wonder each time i choose ogl instead dx11 on gsdx plugin games show black screen only :/
For pcsx? or PCSX2? On this branch build?
My OS Windows 7 :)
If you build this version of the branch it must work (at least the game intro). Which GPU do you have? Can you test opengl SW mode?
I have radeon HD6770. I set opengl as renderer. Software mode work
Hum amd gpu... Hum...
Open the GSdx.ini file and set those 2 options (by default -1):
override_GL_ARB_separate_shader_objects = 0
override_geometry_shader = 0
It works, many thanks.
Each time you commit i will support you :)
You are amaze me (:
Thanks :)
So AMD MS drivers are as bad as linux drivers....
Now I would need your help :p
1/ could you retry with override_geometry_shader = -1
If you've got a driver 13.4+ it must work.
2/ Could you copy/past the "MS console" ouput. I don't know where are print the message actually. I only need the line that begin with
"Supported Opengl version:"
3/ Could you tell me if you can actually play some games? Or the application crash every 5 minutes?
Hey , i just test devil king wich has missalign shadow on gsdx but in ogl it's fixed. (:
1.do you mean:
override_GL_ARB_separate_shader_objects = 0
override_geometry_shader = -1
My driver version 13.5
2. I don't understand
3. It crash if I change game and I should reopen PCSX2.
Game i test:
Dynasty 5 empire,devil king,naruto shippuden 5,monster rancher 4. All of them work.
Actually I have many titles
I see more accuracy there, but it black screen when i thick "allow 8 bit texture.
And also it run slower.
Naruto shippuden 5 background is black when play 2 player fight
1/yes (could be faster with geometry shader)
2/ I print various debug message, in the error channel but I don't know where it is printed on windows. If you can find them, copy past them.
3/ Don't ask too much ;) I will be very interested by some raw perf number
1.yes, it works and run bit faster
2.im sorry i can't find them (my stupify :))
3.i understand that.
Actually this ogl branch has accuracy than gsdx, i really apreciate your work...( ^^,)
the 5650 release not appear here (http://buildbot.orphis.net/pcsx2/) please download Windowx on x86?
I can't find the latest revision too.
I think it's because it's on linux
It is a development version and so not available on buildbot. When I feel my code is stable enough, I will merge into the main repository.
in windows or linux?
you care. Dev is dev. Dev mean not yet ready for standard user.

Revision 5651

* factorize sample object creation
* remember frame buffer attachment state
* Use a basic context on EGL. Allow to use Mesa 9.1 on AMD GPU.
* precompile vertex and geometry shader to avoid benchmark polution on replay
* Try harder to detect FGLRX driver on window
* various clean
Remain to fix the coordinate system for upscaling
Wasn't the vendor string change from "ATI" to "Advanced Micro Devices" quite some time ago?
Hum maybe. I still got ATI on linux. I'm not sure they can change it because they could break some applications.
Interesting, I'll make a note of that.
I'm relatively certain they did change it, but then again, I'm a die-hard nvidia fan.
I have my own project, and a while back, we suddenly received a torrent of crash reports, and reports of graphical glitches.
After some debugging, we discovered that new ATI drivers at that time reported "Advanced Micro Devices" as the vendor, which effectively bypassed all our workarounds for their driver, one of which was a horrible memory leak.
I think the version number at the time was 12.1, it's been a while.
I did some googling and it seems your right. Don t know why I still get the old name. It might depends on the gpu...
Why don't merge in master instead branch?
I believe if it downloadable there a lot people will test it (:
Blah for me not guessing what -wnd stands for, still thought it's linux branch;p.
Probably worth mentioning FXAA=1 = insta crash at boot
and allow 8 bit textures = garbage graphics
Anyway FMV's seem to work(pretty much as in GSdx) and lots of other graphics is being displayed correctly or close as well, missing shadows, effects etc. happens but it's a huge improvement from before it was branched(ie from black screen ;D). Nice job.^^
Oh and changing the mentioned code from ATI to Advanced Micro Devices on my radeon(hd5670) results in less stuff being displayed(and what does display is mostly broken). Soo yeah it would seem it only affects newer series.
Gsdxogl is more accurate than dx11 but slower, i don't know why my hd 6770 can't get fullspeed at 2x native, while in dx11 it run very smooth? :\
actually wnd was for window managment not Windows. Windows is a bonus :-)
fxaa is not yet implemented, it woukd easy to do. Scaling is broken because of different coordinate system between ogl/dx. I didn't test 8 bits texture but I know potential bug that could explain it. Hum missing shadows could also be explained by coordinate too. I m not confident with date setup.
On linux we got 2 drivers for AMD gpu. Catalyst is completely broken even with my workaround... open source work much better albeit 2 times slower.
Code is slower because it is not optimized for speed. The current goal is to have a correct rendering first.
I would like to fix (at least) Y coordinate before merging in the trunk.
No for windows? Too bad:(
But I wish you luck and you could achieve your goal (;. It's not easy task dude.
Since gabest disappear i doubt gsdx would be better.
Seems gsdx wnd so promising(:
window management was to include EGL interface (linux opensource driver and android by the way). I take also the opportunity to include WGL (Windows opengl interface). Except Wnd* files (OGL,EGL,WGL), all parts are common between window/linux/(and why not android one day).
Otherwise see next commit :p
Could you test missing shadow in r5656? I try to fix DATE but not sure it is really working.

Revision 5652

GSdx: Added a vector class for AVX2 and upgraded a few functions to use it,
still a lot to do. New project config AVX2, _M_SSE = 0x501, only use it if you
have haswell. Might break GCC or older MSVC, please test it.
There is something strange about the FMA instructions, a simple mul+add is faster, I have not enabled them yet.
Gather is also a bit disappointing, it is only fast with 32-bit addressing, and it can only use 32-bit indexes. They forgot about extract/insert in AVX2, so I can't even pick out bytes/words/dwords from a ymm register and do a manual lookup.
vs2012 build ok
vs2010 build error
vs2010 error message:
Microsoft.Cpp.Win32.targets (62,5): error: Element <EnableEnhancedInstructionSet> has an invalid value"AdvancedVectorExtensions".
Looks like we need a separate one for vs2010, with StreamingSIMDExtensions2 only.

Revision 5653

GSdx: attempting to fix vs2010 project files, I don't have it installed anymore.
vs2012 build ok
vs2010 build error
vs2010 error message
GSVector.h (4749): error C2039: "xx": not "GSVector8" a member of the
GSVector.h (5362): error C3861: "_mm256_permute4x64_pd": identifier not found

Revision 5654

GSdx: one more try to fix vs2010
Compiles ok now, good work :)

Revision 5655

* detect Advanced Micro Devices for newer AMD Card...
* Mess with coordinate for StretchRect. Upscaling seem to work now. Surely the
biggest diff between ogl and dx...
Sorry for the confusion within r5656, actually this one's here is causing some issue to Bleach Blade Battlers 2(and who knows what else).
Check the pic:
Just to be sure, can you set override_GL_ARB_separate_shader_objects to 0 in GSdx.ini. Normally it must be done automatically for AMD gpu.
Otherwise I would love to have a .gs file with your current setting INI file.
Setting in the GSdx.ini didn't really affect it, so catch the gs file
I cleared my GSdx.ini before doing this so it's all default + that option(but it didn't changed anything)
Just to be sure here's what's inside during this gs:
Thanks. I will see if I can fix it.
Can you test 5657. Normally it must work now :)

Revision 5656

* properly set the stencil write mask
* Multiply Y coodinates by -1. Let's hope it fixes shadows gliches.
Somehow those shadows which weren't present earlier at all still partially go under some elements when they should be on top of them:P.
Other missing stuff also is correctly displayed now, on the other hand this revision messed some other stuff, some clean 2D menus turns into loads of lines(Bleach Blade Battlers 2 for example), looks like it's messed by:
// Control which stencil bitplane are written
since commenting it out fixes it back.
Oh I just noticed, commenting this out also makes the buggy shadows mentioned earlier display same way as they are in DX(with darker lines as they would be applied 2 times cause it seems those glitchy places are overlapping terrain ~ more likely general HW accuracy problem than shadow problem itself ~ SW is clean there).
At least how it works under Windows in case it's any different;3~
+1 for the effort:).
Edit to above:
I think I confused myself with naming of different plugin builds;p, apparently commenting out that 1 code didn't really fixed anything.
The buggy shadows I tested(in Budokai Tenkaichi series) are just behaving differently depending on the place(in DX they're always with darker lines through). And the glitchy graphics in 2D menus of BBB2 seem to be caused by one of the previous commits;p, since the previous one I tried was r5651 which those menus worked fine @[email protected], gonna check which one exactly broken it.
I noticed also kind of strangeness that whenever I change GSdx config some graphic messes up untill I switch plugins. >.> it's like reverting 3D models normals or something, not sure if it's not just something related to testing it on windows through. Linux is more important here since we have DX on win anyway;3.
>> I noticed also kind of strangeness that whenever I change GSdx config some graphic messes up untill I switch plugins. >.> it's like reverting 3D models normals or something, not sure if it's not just something related to testing it on windows through. Linux is more important here since we have DX on win anyway;3.
It is the same on linux (actually it is worst). I exit PCSX2 every time I update the config... I would need to fix my reset management...

Revision 5657

* Don't write color during stencil. Keep the old method to ease debug
* Realign date shader on DX
* keep stencil ref to 1. Reduce stencil management burder
* Fix texture pitch (was in pixels but need bytes). Fix Bleach Blade Battlers 2.
Thanks Miseru for your trace
Remember note:
fxaa -> not yet implemented
msaa -> not implemented (I might drop it actually)
8 bit texture -> not yet implemented
I believe if allow 8 bit implement this gsdx will run faster. Thank anyway
Confirm fix of the problem from r5655 :)
Pretty much from what I have on hdd only budokai tenkaichi has unusual problems(I mean looks worser than on DX version) now, it's mostly about those shadows here's GS with screenshot if you're interested:
it looks different depending on place so I made it in one that has some nasty shadow over terrain that just shouldn't be there. Not sure if that information will be of any help but suprisingly when I intentionally break graphics by going to settings in GSdx which then looks like normals being reverted in 3D models, all shadow bugs dissappear and other than broken models it looks pretty much like in dx.
All other games I tried both 2D and 3D from my limited tests seems pretty much same as on DX:).
If you decide to merge it with the trunk anytime soon for more testers, you'll want this patch as well:
fixes VS2010 compile error
To avoid the usual "buildbot broken" posts/threads;p
Try next version :)
@miseru, thanks for the patch.
I give a quick test on the free driver and it seems to be fine. I would need to test catalyst too. I won't be surprised if we hit another AMD bug...
Anyway, the status is pretty good :)

Revision 5658

* Patch from miseru to fix VS2010
* Quick fix for 8-bits textures
Dunno how much this option helps now since I have loads of different limitations on GL speed, but for sure the graphics are fixed with it now.:)
well it won't be worst :p If we move jobs from CPU to GPU, I think we can gain a couple of fps.
That would be nice to see, not sure how much it might help on radeons through, GL HW is slower than software in some cases, even with other stuff like DeSmuMe, using GL there also results in less fps.
Even with low cpu&gpu usage on some 2D games, not sure if it's bandwidth as 8 bit textures doesn't help much for those cases or just the drivers stupidity.
This surely looks differently on Nvidia;3.
Don't know for nvidia. I own an AMD card ;) That why opensource driver was very critical for me. I don't know for others but GSdx is built around Dx that could explain some slow down.
I would need to profilte the code but
1/ to be efficient the GPU must run asynchronously of the CPU. There are several way to do things in opengl, I need to find the good one. One idea will be to create a command buffer thread that dispatch the command to the driver. It could be efficient but it would need a major rework of GSdx...
2/ opengl driver are less tested optimized than Dx driver (even if they're common at 90%).
More work for speed and accuracy?
You are awesome :)

Revision 5659

gsdx-ogl-wnd: implement fxaa. I directly reuse the .fx file with minor update
next plan is to merge into the trunk ;)
Hey gregory, unrelated but I'm working with an ubuntu 12.04 in a vm right now. So erh, what can we do with GL 2.1 (semi)-direct rendering? :p
Also it's a bit ugly how we just fail right now, not showing the (stdio) log about the 3.3 requirement. People with poor 3d support that use the ppa will just look at a frozen pcsx2 main window for all eternity :p
#include "res/fxaa.h" No such file or directory
What do you call semi-direct? It either direct or not ;) Anyway technically if you have only 2.1 (equivalent to Dx8) => you can't do render to texture... However it is possible that you support 2.1 + various 3.x/4.x extensions. Can you run the glxinfo command and me give the output (you might need to install mesa-utils).
You can also try to build GSdx with EGL. Set this cmake option "-DEGL_API=TRUE". EGL (install libegl1-mesa-dev too) only require opengl3.0 (on this branch).
On the freezing PCSX2, actually the issue comes from the pad plugin. I did a commit on trunk.
@yxmline, thank. I added the file on r5661

Revision 5660

onepad: Don't try to acquire the lock when it wasn't initialized. Avoid
the freezing of the window when a plugin failed to open.
Nice fix, I'll test this as soon as I've found out how to build pcsx2 my own. Noticed that the ppa doesn't auto-update, which makes sense, I guess :p
Also. Here's the glxinfo you requested:
[email protected]:~$ glxinfo
name of display: :0.0
display: :0 screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile,
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_framebuffer_sRGB,
GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer,
GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control,
GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read,
GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample,
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group,
GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control,
GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_video_sync,
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on SVGA3D; build: RELEASE;
OpenGL version string: 2.1 Mesa 8.0.4
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_ARB_multisample, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_copy_texture,
GL_EXT_polygon_offset, GL_EXT_subtexture, GL_EXT_texture_object,
GL_EXT_vertex_array, GL_EXT_compiled_vertex_array, GL_EXT_texture,
GL_EXT_texture3D, GL_IBM_rasterpos_clip, GL_ARB_point_parameters,
GL_EXT_draw_range_elements, GL_EXT_packed_pixels, GL_EXT_point_parameters,
GL_EXT_rescale_normal, GL_EXT_separate_specular_color,
GL_EXT_texture_edge_clamp, GL_SGIS_generate_mipmap,
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp,
GL_SGIS_texture_lod, GL_ARB_framebuffer_sRGB, GL_ARB_multitexture,
GL_EXT_framebuffer_sRGB, GL_IBM_multimode_draw_arrays,
GL_IBM_texture_mirrored_repeat, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_transpose_matrix,
GL_EXT_blend_func_separate, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_secondary_color, GL_EXT_texture_env_add,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_INGR_blend_func_separate, GL_NV_blend_square, GL_NV_light_max_exponent,
GL_NV_texgen_reflection, GL_NV_texture_env_combine4,
GL_SUN_multi_draw_arrays, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_EXT_framebuffer_object,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_MESA_window_pos,
GL_NV_packed_depth_stencil, GL_NV_texture_rectangle, GL_ARB_depth_texture,
GL_ARB_occlusion_query, GL_ARB_shadow, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_window_pos,
GL_EXT_stencil_two_side, GL_EXT_texture_cube_map, GL_NV_fog_distance,
GL_APPLE_packed_pixels, GL_APPLE_vertex_array_object, GL_ARB_draw_buffers,
GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_shader_objects,
GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ATI_draw_buffers,
GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_EXT_shadow_funcs,
GL_EXT_stencil_wrap, GL_MESA_pack_invert, GL_NV_primitive_restart,
GL_ARB_fragment_program_shadow, GL_ARB_half_float_pixel,
GL_ARB_occlusion_query2, GL_ARB_point_sprite, GL_ARB_shading_language_100,
GL_ARB_sync, GL_ARB_texture_non_power_of_two, GL_ARB_vertex_buffer_object,
GL_ATI_blend_equation_separate, GL_EXT_blend_equation_separate,
GL_OES_read_format, GL_ARB_pixel_buffer_object, GL_ARB_texture_float,
GL_ARB_texture_rectangle, GL_EXT_pixel_buffer_object,
GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_ARB_framebuffer_object,
GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample,
GL_EXT_packed_depth_stencil, GL_ARB_vertex_array_object,
GL_ATI_separate_stencil, GL_EXT_gpu_program_parameters,
GL_EXT_texture_sRGB_decode, GL_OES_EGL_image, GL_ARB_copy_buffer,
GL_ARB_half_float_vertex, GL_ARB_map_buffer_range, GL_ARB_texture_swizzle,
GL_ARB_vertex_array_bgra, GL_EXT_separate_shader_objects,
GL_EXT_texture_swizzle, GL_EXT_vertex_array_bgra,
GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location,
GL_ARB_fragment_coord_conventions, GL_ARB_provoking_vertex,
GL_ARB_sampler_objects, GL_EXT_provoking_vertex, GL_ARB_robustness,
You can use ./build.sh --egl --dev (or --help)
However you need to install tool chain and dependency (sudo apt-get build-dep pcsx2-unstable)
Thanks for the data.
Hm, I have some bad dependency issues trying that. I think I can't satisfy them without purging the whole system first. Better do another vm just for building.
Is it a 64 bits ubuntu? Anyway, I give a quick look. It might be possible to run the SW mode of GSdx (and maybe zzogl too). However you will need to remove the gl check (somethings like that).
Index: GLLoader.cpp
--- GLLoader.cpp (revision 5661)
+++ GLLoader.cpp (working copy)
@@ -133,14 +133,14 @@
found_geometry_shader = !!theApp.GetConfig("override_geometry_shader", -1);
fprintf(stderr, "Override geometry shaders detection\n");
- if ( (major_gl == 3) && minor_gl < 3) {
+ if ( (major_gl <= 3) && minor_gl < 3) {
// Opensource driver spotted
found_only_gl30 = true;
if ( (major_gl < major) || ( major_gl == major && minor_gl < minor ) ) {
fprintf(stderr, "OPENGL %d.%d is not supported\n", major, minor);
- return false;
+ //return false;
Index: GSDeviceOGL.cpp
--- GSDeviceOGL.cpp (revision 5665)
+++ GSDeviceOGL.cpp (working copy)
@@ -1249,7 +1249,7 @@
// First select the version (must be the first line so we need to generate it
std::string version;
if (GLLoader::found_only_gl30) {
- version = "#version 130\n";
+ version = "#version 120\n";
} else {
version = "#version 330\n";
It's a 32bit install. I was trying to get better performance out of the VM environment but going 32 bits didn't really help :p
That strange you got dependency issue. What soft/kind of VM do you use?
The virtual environment isn't the issue, but the OS might. I'm using xubuntu 12.04 with a couple daily additions to xfce.
Hum, go to setting (right clik)=> window manager tweaks => compositor then disable "compositing", if not already done.

Revision 5661

gsdx-ogl-wnd: ... forget to add the file...

Revision 5662

gsdx-ogl_wnd: Merging r5633 through r5661

Revision 5663

gsdx-ogl-wnd: port (minor) renderer update of r5649 to opengl
Now the brach is ready to be merged :)
Dears Window users. If you can test that:
1/ still compile
2/ still running on DX
3/ can run with opengl
VS2010 and it's problems:
gsdx-ogl-wnd\plugins\gsdx\res/fxaa.h(1759): fatal error C1091: compiler limit: string exceeds 65535 bytes in length
Gonna try to cut out some of the descriptions and other commented out stuff to fit the 65k bytes;p
Yep. It 's ongoing, I just get a new chainsaw :p
Ok it's done. Thanks for your feedback.

Revision 5664

gsdx-ogl-wnd: VS2010 doesn't support string bigger than 64k bytes. So remove
PS3&360 shader from fxaa
Builds ok, but...
Now shader fails to compile, from pcsx2 log:
3.x GL context successfully created
Supported Opengl version: 3.3.12198 Core Profile/Debug Context on GPU: ATI Radeon HD 5670. Vendor: ATI Technologies Inc.
DEBUG: check_gl_supported_extension
Buggy driver detected, GL_ARB_separate_shader_objects will be disabled
GL_ARB_separate_shader_objects is not supported
Override GL_ARB_separate_shader_objects detection
fxaa.fx (entry ps_main, prog 17) :
#define FXAA_GLSL_130 1
#extension GL_ARB_gpu_shader5 : enable
Fragment shader failed to compile with the following errors:
ERROR: 1:774: error(#71) Syntax error: incorrect preprocessor directive
WARNING: 1:774: warning(#64) Unexpected tokens following #if preprocessor directive: newline expected
ERROR: 1:854: error(#71) Syntax error: incorrect preprocessor directive
WARNING: 1:854: warning(#64) Unexpected tokens following #if preprocessor directive: newline expected
ERROR: 1:899: error(#71) Syntax error: incorrect preprocessor directive
WARNING: 1:899: warning(#64) Unexpected tokens following #if preprocessor directive: newline expected
ERROR: 1:900: error(#198) Redefinition error: luma4B
ERROR: 1:900: error(#132) Syntax error: "." parse error
ERROR: error(#273) 5 compilation errors. No code generated
Which results in white screen on shader enable.
And while switching to DX11 from GL I get runtime error with:
(1230,2): error X3000: unrecognized identifier 'vec2'
(1230,7): error X3000: unrecognized identifier 'pos'
in the log
Should #ifdef FXAA_GLSL_130 even be in fxaa.fx if it's not used by DX?(it uses that one you just added in fxaa.h?)
Commenting it out fixes dx versions, does nothing to shader compile errors of GL fxaa.
yep see next commit. It must be #if not #ifdef. Because it is defined to 0.

Revision 5665

gsdx-ogl-wnd: fix ifdef mess on fxaa (both dx and ogl)
1) - compile ok,
2) - runs GL fine(through it has those config problems in GL:P and switching from dx to gl = crash probably related to that reset problem, works fine while switching the other way)
3) - still runs DX.
More about that crash since emulog doesn't really show anything, I'm now very sure it happens cause this reset management problem you explained some revisions ago.
I can reproduce the crash each and every time when entering GSdx config before running in GL mode, if I run it at least once before entering config, then it's fine(the config bug still happens when entering it later ofc, but on windows this can be fixed by switching between different GL enabled builds).
Other than this I see no bothersome differences from dx.:)
Anyone give me link to download this svn?cos im lazy :p. Thanks
Globally good news. I will try to reproduce the bug on my side. Maybe it windows specific.
On another topic, fxaa and shade boost also work for SW? Or are they limited to HW renderer?
Is gsdxwnd support mip map wich gsdx doesn't?
Checked ~ fxaa&shadeboost works in both modes just fine;3.
Miseru could you share this plugin via email :)
This will most likely soon be merged anyway;p, but ok if you can't wait here's my build http://www.mediafire.com/?x9hyxjsb9b5kwyh
Really? It's going to merge? Awesome!!!
Thank a lot miseru ( ^^)d thumbs up!

Revision 5666

* update linux dialog: create a custom shader box and put it Shade boost and
* force the reloading of the inifile after any configuration update.
How to download this revision? I'm newbie here! :P
Not sure we can download it because it is a dev branch (in worst case I will merge it soon)
Please stop asking for downloads of this people. If you need to ask that question, you wouldn't be able to test it anyway. Just wait a bit until it's merged back.

Revision 5667

gsdx: merge back gsdx-ogl-wnd to the trunk
Here the list of the major change:
* Drop glew. It won't failed to load because of the wrong glew version
* shaders are include in the source code to ease release&packaging
* Port GSdx-ogl to MS Windows
* Fix lots of HW rendering bug. 8bits textures/upscale/transparency...
- rendering isn't yet perfect but some games must be playable now.
* Add Fxaa shader.
* run on the opensouce driver (require mesa 9). You will need to build with EGL
- either use this cmake option -DEGL_API=TRUE
- Or the handy script ./build.sh --egl ...
* Linux AMD users: you need to do a choice
* speed but bad rendering => catalyst
* correct rendering but slower => opensource radeon
* Some parts are still unimplemented:
- Vsync
- Fully dynamic switch between EGL/GLX
- Speed optimization
- Others stuff that I have forgotten :p
Forget to say windows user you can now download it from buildbot :p
PPA will be updated in a couple of days
Finally, port windows (: awesome
StretchRect(st, sr, dt, dr, m_shadeboost.ps, m_shadeboost.cb);
in GSDeviceOGL::DoShadeBoost
What's up with that last parameter m_shadeboost.cb?
warning C4129: '%' : unrecognized character escape sequence
% should be escaped as %%, it's in convert.h and shadeboost.h
Maybe opengl likes \% :D

Revision 5668

GSdx: minor fixes to previous commit, rundll32 window not showing and a compiler

Revision 5669

gsdx (ogl):
* fix memory leak of m_wnd
* don't escape % in the shader string
* Fix shadeboost StretchRect parameter
debian: compress package with xz
Well like I mentioned in r5673 ~ this one is the cause of crashes(for windows at least). Messing with settings after game was started(even during suspend) = crash with no trace in the log.
Oh it's this change:
delete s_gs->m_wnd;
s_gs->m_wnd = NULL;
commenting it out fixes the crashes;p apparently config window uses the close function, if you delete stuff it has nothing to get back to and results in a crash.

Revision 5670

pcsx2: increase a bit the minimum size of the plugin dialogs (GSdx name is too
* move gl function loading into GSwnd. Clean the header and avoid to rely on
* Always require libegl for GSdx. You still need to select the API at

Revision 5671

* add exception in GSWndEGL and GSWndOGL
* Try to use EGL when GLX failed => you don't need any flags for the opensource
driver ;)
cmake: don't install anymore the glsl shader

Revision 5672

gsdx: miss a part of the previous patch...

Revision 5673

i18n: refresh string translation
GSdx: nothing to see :p
I get error message when change d3d internal res from 2xnative to 3xnative (viceversa) on gsdxr5673
What error message do you have?
1st error:
3.x GL context successfully created
Supported Opengl version: 3.3.11672 Core Profile/Debug Context on GPU: ATI Radeon HD 4800 Series. Vendor: ATI Technologies Inc.
DEBUG: check_gl_supported_extension
Buggy driver detected, GL_ARB_separate_shader_objects will be disabled
GL_ARB_separate_shader_objects is not supported
fxaa.fx (entry ps_main, prog 17) :
#define FXAA_GLSL_130 1
#extension GL_ARB_gpu_shader5 : enable
Fragment shader failed to compile with the following errors:
WARNING: 0:6: warning(#62) enable/warn/disable extension isn't found, extension 'GL_ARB_gpu_shader5' is not supported
ERROR: 1:863: error(#201) Requires extension support: textureGather (GL_ARB_gpu_shader5)
WARNING: 1:863: warning(#402) Implicit truncation of vector from size 1 to size 4.
ERROR: 1:864: error(#201) Requires extension support: textureGatherOffset (GL_ARB_gpu_shader5)
WARNING: 1:864: warning(#402) Implicit truncation of vector from size 1 to size 4.
ERROR: error(#273) 2 compilation errors. No code generated
2st error on change native 2x -> 3x:
Suspending single plugin: GS
Saving GS
Closing GS
Recovering single plugin: GS
Opening GS
3.x GL context successfully created
Supported Opengl version: 3.3.11672 Core Profile/Debug Context on GPU: ATI Radeon HD 4800 Series. Vendor: ATI Technologies Inc.
DEBUG: check_gl_supported_extension
Buggy driver detected, GL_ARB_separate_shader_objects will be disabled
GL_ARB_separate_shader_objects is not supported
fxaa.fx (entry ps_main, prog 17) :
#define FXAA_GLSL_130 1
#extension GL_ARB_gpu_shader5 : enable
Fragment shader failed to compile with the following errors:
WARNING: 0:6: warning(#62) enable/warn/disable extension isn't found, extension 'GL_ARB_gpu_shader5' is not supported
ERROR: 1:863: error(#201) Requires extension support: textureGather (GL_ARB_gpu_shader5)
WARNING: 1:863: warning(#402) Implicit truncation of vector from size 1 to size 4.
ERROR: 1:864: error(#201) Requires extension support: textureGatherOffset (GL_ARB_gpu_shader5)
WARNING: 1:864: warning(#402) Implicit truncation of vector from size 1 to size 4.
ERROR: error(#273) 2 compilation errors. No code generated
Loading GS
Overall 0 Cheats loaded
Found Widescreen hacks file: '38A894C6.pnach'
comment: dot Hack - Part 1 - Infection - Widescreen Hack (16:9) (NTSC-U) (Hyakki)
Loaded 1 Widescreen hacks from '38A894C6.pnach'
Overall 1 Widescreen hacks loaded
after - hang and program close)
Try to uncheck fxaa. I will fix it later, not sure it will fix the hang.
Seems memory leak or crash? " the instruction at 0x10014095 referenced memory at 0x00000004.The memory could not be read"
fxaa have check/uncheck options?.. where?
In the option (at least on linux). Or wait a couple of hours :p
Everybody that got a crash use an AMD GPU right? If you are able to compile rise your hand.
During the run the emulator settings can not be modified gsdx
Such as:
Open hw hack
Open 8bit texture
Open shadeboost
will crash
ps dx9/dx11 mode
Why do you people give negative to harmless commit while it was r5669 that broke stuff?:P Lazy much?
"If you are able to compile rise your hand."
Rises hand
;p what do you need?
Try this patch please
Index: GS.cpp
--- GS.cpp (revision 5673)
+++ GS.cpp (working copy)
@@ -178,15 +178,6 @@
delete s_gs->m_dev;
s_gs->m_dev = NULL;
- if (s_gs->m_wnd)
- {
- s_gs->m_wnd->Detach();
- delete s_gs->m_wnd;
- s_gs->m_wnd = NULL;
- }
static int _GSopen(void** dsp, char* title, int renderer, int threads = -1)
before seeing it I already commented out
delete s_gs->m_wnd;
s_gs->m_wnd = NULL;
and it worked fine;p,
the patch helps as well.
Ok commited + bunch of stuff :p

Revision 5674

* don't delete the wnd in GSclose. It can still be used later
* Properly detect the GL_ARB_gpu_shader5 extension for Fxaa
* A couple of fix in Create (GSopen1) of GSWndEGL/GSWndOGL
Rather than disabling FXAA outright, you could probably use GL_ARB_texture_gather for it.
Fxaa is still enabled but it will be less efficient. Current market is 1/3 DX10 GPU and 2/3 DX11 GPU. With new console/new GPU gen (@20nm) and the end of XP, I guess the DX10 market will dive soon below 15-20%. So I prefered spend my free time to fix bug/improve perf rather than improve fxaa ;)

Revision 5675

GSdx: More avx2 code to read/write different block formats, the GSBenchmark
function shows nice improvements, but no games run faster. I just upload the
changes before messing with the drawing part.
Yess Boss !))
I always use Software renderer, due to correct post effects and FXAA gives pretty acceptable image quality :) And it is very good that you keeps optimizing this brilliant plugin )))
(maybe one day you will find the way to even run software renderer on CUDA streams on GFX (*_*) Modern gfx cards is too fast for modern games this day...)
By the way - avx2 is for IvyBridge or SandyBridge too ?
(Oh sorry - I've noticed that it's for Haswell only...)
Avx2 only available in haswell cpu
Gsdx32-r5675(sse2/ssse3/sse41/avx) does not work directly crash
gsdx32-r5674 no problem
my cpu i5-2310
r5675 (sse2) DX10 HW
missig FF X german First Screens (1.White Sqaresoft and 2.Finalfantasy X Project)
Intro only some Fire and Shadows to see...
5674 works
I checked ffx, sse4 or above is ok, below broken. About the crash, no idea yet.
This must have broken the VS2010 project as the buildbot cannot build anymore.
Error compiling in vs2010, error C3861: '_mm_blend_epi32': identifier not found, beleave only vs2012 has this defined from my googling, i know vs2010 has _mm_blend_epi16
_mm_blend_epi32 is avx2 only..., seemed like an innocent little instruction to be added to the vector class. Intel always had many holes in the instructions set, and many overlapping, they just can't plan ahead.
We still need a fix for 2010 :p

Revision 5676

GSdx: sse2/ssse3 missing graphics fix
Are there any games where we will see a noticeable change?

Revision 5677

GSdx: The sw renderer now uses avx2, not much faster though, +10% maybe, if the
game is not EE limited. I'm not sure if haswell has that much better sse
execution (load/store units doubled for example), or the avx2 code is not fully
optimized yet.
The think the biggest problem is the bad design of the vpgather instruction, it is rarely useful in my case. Most of the time it just does not fit, and the reading 8 pixels or texture samples has to be serialized.
Great job !)))
Keep optimizing software renderer :)
By the way - you said about 10% speed gain in avx2, but what is speed gain between usual sse4 plugin and avx1 plugin ?
Gabest, thanks for your hard work. I have one question. When you say "The sw renderer now uses avx2". does that means you droped the AVX1 support for the plugin with this revision? Or does it just stays the same for Sandy/Ivy Bridge users?
Line.Exon: Considering this was an implementation of AVX2, there will be no difference at all tothe sse4 and avx1 versions.
Gabest: This is all very nice, but could you fix some of the bugs with the texture cache or something? The biggest one at the moment is the memory leaks and half screen issues with the snowblind engine, now we've fixed the textures ;p
Im talking about the HW renderer of course.
There is still an AVX build, I didn't remove that. Compared to SSE4, the only advantage is the new VEX instruction encoding. The output can be redirected a third register, so that the one of the inputs do not have to be overwritten. It helps in some cases.
I just run a test on metal gear solid's intro, when two scenes are rendered parallel and blended together (plane and cigar), it is the slowest gs dump I have.
SSE4/AVX: 9, AVX2: 10.68 (extra threads: 0)
SSE4/AVX: 21.30, AVX2: 25.08 (extra threads: 3)
The difference between SSE4 and AVX was so little and fluctuating, that I could not measure it.
The hardware renderer is a mess, I'm afraid to touch it, don't even know about the new hacks :P AMD's next cpu looks promising, I don't know the details, but somehow they share the memory between cpu/gpu, similar to larrabee/knights*/xeonphi. They are both moving away from a discrete gpu, that is hardly usable for any work in the time span of one frame because of the latency, to this new memory model. That's why directx and opengl is not advancing, they are a dead end currently.
Both ps4 and the new xbox will have this new amd cpu inside, it must mean something!
Yeh the new HW renderer is a mess :P We haven't added "that many" new hacks to it, some z depth ones were removed and a couple were put in place to get around bugs, but the texture cache is our biggest nightmare at the moment, especially in cases like the snowblind engine where it just keeps allocating space for textures that already exist, we have to use the SW renderer and the LAA patch on the pcsx2.exe to stop it running out of memory too quickly lol
If you can at least fix the half screen issue id be happy :P
Speaking of hardware renderer - are there any chanses of fixing SH Origins / Shattered Memories flashlight/shadows bug in future?
We're often reviewed the hardware renderer and there's no way to really fix it (without redoing the whole plugin).
Single issues like the half screen one in Snowblind engine games could be fixable though. In the same engine the software renderer also has a serious problem with allocating too much memory. It usually goes over the 2GB addressing limit and crashes.
I hope this dump shows both problems. The memory problem is much worse when the camera moves. It must be something the engine does.
Also: Not bad with the MGS 3 intro. 17% speedup from using the new instructions is seizable!
Too bad this will be a high end feature for quite some time to come.
In ZeroGS video plugin there option "full 16 bit resolution-use when half screen is missing"
May be if we use game input pixel depth just let output use that pixel depth
e.g game x using 16 bit then in gsdx doesn't convert to 32 bit just let it 16 bit.
What do you think? (:
When the sw renderer allocates too much memory, it happens because the same texture is accessed through a sliding window. The top left corner is set to the used block/page, but the size can be up to 1024x1024, even if only 16x16 pixels are needed, the memory is allocated for the whole texture. That's because the texture coordinates are for the whole size, and because the next drawing may not only refer to that tiny top left corner and we have to load the texture data somewhere. On ps2, the cache is just a single page, but it can be switched seamlessly, like it was a virtual memory page.
gsdx doesn't full converting to 32 bit all the time.
So output pixel depth depend on game itself
rama: It's faster even on low-end haswell, the percents should be the same :P
Not sure about newer gpus, they are all built around the features of dx11/opengl, only getting faster. I'm still using my old 460gtx, good enough for games. As I said, the next holy grail is this coherent memory model. Not sure how nvidia can stay in the market without a x86 cpu. Maybe they will just go with arm and portable devices.
Is impossible to use game pixel depth?
Or it has been implement?.
Confused a little in number of software threads - I have Intel i5 CPU, it has 2 cores and by multithreading - system shows 4 cores. What number of software threads is effective to set in this case ? (two or three ?)
gabest11: As Refraction and Rama have stated, if you could fix the half screen problems in the Snowblind games MANY pcsx2 users would be eternally in your debt (myself included). Fixing this issue would not just be fixing one game, rather it would the fixing of many games, since many use this engine.
This bug is one of the last big great bugs in pcsx2 which only you can fix since its a GSDX specific bug.
Line.Exon: 3 is optimal for a quad core CPU.
Does low end Haswell come with the full AVX2 set? I didn't really check out the chip since I already have Ivy. I was mainly interrested in > 5Ghz everyday use overclocking but the chip couldn't deliver (again :/ ).
All Haswell's have AVX2
Can the plugin use something like texture compression to fight the excessive memory use in this case?
Even if not, we don't need a drastic reduction in memory consumption to make these games playable. It seems like right now the engine can cause an allocation up to maybe 2.5GB. If that went down one GB, we could work with that.
If the 2GB alocation is the issue wouldn't it be solved by by a cross compile of 64 bit or are we using addressing/registers/etc in such a specific way that it isn't that easy to convert the plugin to 64-bit?
Expect more great updates. Thank you.
I didn't read into it but I think you need a 64bit host app for 64bit plugins. PCSX2 is decidedly 32bits so yea.
@rama: texture compression can be done ay changing to 16 bit texture (that only my estimation) and gsdx using 32 bit texture to all games
64 bit is too complicated or may be impossible. that the reason why it's left long time ago. You should search on forum before post
It's not that it's complicated Billy it's that it'd require a complete rewrite of the whole program with questionable gain\use. Writing plugins may or may not be as complicated however if they require a 64-bit host obviously it's not going to happen. In the near future if at all.
I am aware why that project was abandoned a few years ago.
On linux, a 32 bits process can get nearly 4GB of memory with a 64bits kernel. 32 bits kernel is the standard 2/2 or 3/1 split.
Seem like we can't mix code into a single process. We could create 2 process and communicate with shared memory (or others IPC). Dunno about the speed impact and the 'usability'.
64-bit is not that much complicated, it is just that all the recompilers are 32-bit, and the calling conventions are different between windows and linux. The code paths would be much more separated, many ifdefs.
Yeah I believe the original reason was not that it was too hard to do 64 -bit but the complexity of maintaining 2 different code branches for not much gain on the 64 bit branch wasn't deeemed worth the hassle. Of course at some point it could be decided everyone has a 64-bit OS anyways so lets kill off the 32-bit version and go 64-bit but then again it still requires a complete rewrite/port of existing code at that point. Though that would be a good point at to which fix things that xould only be fixed by a rewrite as you are doing it at that point anyways.

Revision 5678

GSdx: vs2010 fix and minor changes
Fix is working. I tested the MGS3 scene you mentioned and noticed that I get occasional red triangles flashing in the scene now. This is a new problem, doesn't happen in a GSdx build ~100 revs ago. Do you get this as well if you leave the intro scene run a bit?
Which build and renderer are you using?
Found one already.
Finally, can be downloaded on buildbot...
Many thanks...( ' ',)d

Revision 5679

GSdx: copy-paste mistake, thanks rama :)
Thanks for fixing that. There is a new nug that got introduced prior to these last 2 revs. See here http://forums.pcsx2.net/Thread-Monster-Rancher-4-New-problem-in-SVN
All right, this commit took care of the MGS3 problem :)

Revision 5680

GSdx: Found some 16-bit integer overflow in GSState::VertexKick, some triangles
could have been removed by the scissor test.
error C3861: '_mm_broadcastss_ps': identifier not found
On the pcsx2 buildbot site, next to the download, there should be a link to the build log. That would be very useful.
It fix what?
Ratchet and clank probably, but I noticed this problem in nba 2008.
R&c textures were fine, just needed mipmap support. Unless this was a new problem :p
Btw monster rancher 4 still fubar. Links to the discussion in an earlier rev (2 back I think)
Test on yuyu hakusho dark tournament and guitar hero 2 it fix sudden speed and sudden slow everything better now. Thank's gabest...( ' ^,)d
Sorry, mentioned it on r5679
I have no idea how to play that game. Can't get out of the training area.
You might wanna ask him for a GS State then ;p
Something strange happened in this rev, the color of the car in tokyo xtreme racer zero looks to be fixed.
Wierd but cool :)
@gabest: may be that game using 16 bit texture

Revision 5681

GSdx: obligatory vs2010 compiler fix

Revision 5682

gsdx ogl:
* Separate state and shader compilation into separate function
* replace various hash_map by basic array
* Compact VertexScale and offset into a single vec4
* add the new option "ogl_vertex_subdata": subdata is faster on FGLRX, test are
welcome on Nvidia drivers
0 => use map/unmap
1 => use subdata
replay: add "linux_replay" option and compute some nice stat (mean, standard
cmake: recreate shader header at build time

Revision 5683

clean (some) gdb warning: round 1
* use svnrev.h on linux too
* replace sprintf_s with snprintf (hope it still compile on Windows)
* init integer with 0 instead of NULL
* various int -> u32/uint32/uint on for loop index
* remove a couple of unused variable
* init few variable
* disable unused warning results
No exe on buildbot, smell like I broke MS compilation... Error log are welcome (I miss some much a buildbot log)
vs2012 broke compilation
vs2010 broke compilation
error C3861: "snprintf": identifier not found
ok thanks.
Instead of uint32, you should use size_t, countof macro is sizeof/sizeof.

Revision 5684

plugin: restore sprintf_s on windows and hopefully fix vs201n compilation
i dunno if it was these or not causing it, there is no physical entry for r5683 on the buildbot, even with a "No Build" link, so it might be the buildbot has died.
On the previous commit someone copy/past the log error. I just check the buildbot it seems to be alive :) It works so I can send wave 2.
yeh its woken up now :) good job!
Maybe it doesnt add a no build until a build is successful, would make sense i guess ;p
Hum, I don't find that logical but why not.
well if its a build bot, it uploads when it has a successful build, if the most recent one(s) didn't build, there isn't much point in putting it up, then when it does have one it can build, it will probably want to fill in the gaps.
thats how i see it anyways.
buiild ok

Revision 5685

all: gcc warning clean (round 2)
* reorder static initialization list
* Add missing virtual desctrutor to virtual object
* int -> uint/u32/uint32 cast of for loop index
* add a missing return in pxTrySetFocus
* fix size parameter of memset m_clut
* disable missing-field-initializers warning
* disable unused-local-typedefs warning
Thanks for going over these. I remember the headache we had with memory leaks, leftover pointers and wrong memsets in GSdx ><
Hum, now that I can run Gsdx-ogl with the open source driver. Maybe I can run Valgrind (if it support SSE2). It would spot any memory leak/buffer overflow/wrong memset. Maybe GSdx is free but not my ogl code :p
Anyway, I need some help for those warning: hw_by_page is defined as uint but we assign -1 ! And we test -1 somewhere in the code !
Memory.cpp:108:86: warning: narrowing conversion of ‘-1’ from ‘int’ to ‘vtlbHandler {aka unsigned int}’ inside { } is ill-formed in C++11 [-Wnarrowing]
This revision causes crashes when swapping between software + hardware renderer while using a custom resolution. see the post here (and some of them before it).
I m in the middle of spain without any computer access. Do you know if it an issue with gsdx or pcsx2.
On gsdx, there is only 3 'big' change: the memclut init in GSTextureCache.cpp and the other 2 are virtual destructor declaration on GSThread.h. All others modif are minors and unlikely to have any impact.
The error is to do with virtual function calls so I suspect that is possibly the culprit. I got the guy to test just the GSDX builds, I'm *assuming* he did so ;p
I could add some linux define but I'm not sure code will be correct. Here the warnings generated by GCC.
GSdx/GSThread.h:331:3: warning: deleting object of abstract class type ‘IGSEvent’ which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]
delete m_notempty;
GSdx/GSThread.h:332:3: warning: deleting object of abstract class type ‘IGSEvent’ which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]
delete m_empty;
GSdx/GSThread.h:333:3: warning: deleting object of abstract class type ‘IGSLock’ which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]
delete m_lock;
I will check it for you gregory.
Do you have any specific log/error message?
On linux, I got an abort in __cxa_pure_virtual when I toggle F9 several times.
#4 0xf6f6021f in std::terminate() () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#5 0xf6f60f22 in __cxa_pure_virtual () from /usr/lib/i386-linux-gnu/libstdc++.so.6
#6 0xf0375036 in GSAutoLock (l=0xe53e0738, this=<synthetic pointer>) at plugins/GSdx/GSThread.h:247
#7 GSgetTitleInfo2 (dest=0xffffce60 "\002", length=128) at plugins/GSdx/GS.cpp:833
#8 0x081a2457 in GSFrame::OnUpdateTitle (this=0xa237ff0, evt=...) at pcsx2/gui/FrameForGS.cpp:530
Hum, my line GSThread.h:247 is GSAutoLock(IGSLock* l) {(m_lock = l)->Lock();}
Removing virtual ~IGSLock() {} seems to remove the crash but I can't reproduce it anymore even with with the declaration...
I only have this image for you.
Ok, I got same error message but I'm not sure it is exactly the same error. My crash appears because the function lock is not defined (I guess the object 'l' was already deleted).
Will you be able to compile GSdx manually? If yes, could you try
the line "virtual ~IGSLock() {}" around line 38.
Sry, no vs installed at this moment

Revision 5686

debian: update Control with latest GSdx requirement. Update Readme with latest
openGL extensions

Revision 5687

gsdx: use size_t for loop index when it used countof macro
* fix override_GL_ARB_copy_image typo

Revision 5688

gsdx ogl:
* fix shader compilation on Nvidia (broken on r5682)
* fix various memory leak thanks to Valgrind
Cmake: fix a minor typo

Revision 5689

pcsx2: gcc warning round 3
* various cast was overflowing
- use unsigned integer for SSE mask
- force SINGLE macro to use u32
* disable parenthesis warning, only a matter of coding style
Remains 2 wrong use of unsigned integer:
pcsx2/CDVD/InputIsoFile.cpp:96:21: warning: comparison of unsigned expression <
0 is always false [-Wtype-limits]
pcsx2/Memory.cpp:108:86: warning: narrowing conversion of ‘-1’ from ‘int’ to
‘vtlbHandler {aka unsigned int}’ inside { } is ill-formed in C++11 [-Wnarrowing]
If gcc warning isn't appear, is pcsx2 will faster?
unlikely to be faster, just less runtime errors which in turn means less chances to crash or hang

Revision 5690

gsdx ogl: fix crash when pause/resume with EGL (opensource driver)

Revision 5691

* remove iconvert.cpp not used anymore
* change copyrigh header from GPL to LGPL. Those 2 files are only basic .h. 1
licence by plugin is enough ;)

Revision 5692

Removed ATL/MFC dependencies from every project, the free version of visual
studio does not have those. It compiles with vs2012 express now, will fix others
later, in case they are broken.

Revision 5693

Missing file
Rebuild solution "Release AVX" works with 2010 :)
I found that all my states failed to load after rebuilding pcsx2, It says my files are truncated. Don't know which revision broke them, hope not these last ones.
Creating new states and loading them do work though. Could it be that some structure does not use the same alignment and became a different size? I have no idea :D
Good jobs :-) It was very painful for me to build pcsx2 with VS freeedition

Revision 5694

Fix for the v110_xp toolset in vs2012. Removed winuser.h from afxresmw.h,
nothing seems to be using it, but it breaks something in string.h. I did not
change the projects to use v110_xp by default, to get an xp compatible binary,
you have to call it from command line like this: msbuild pcsx2_suite_2012.sln
/t:Build "/p:Configuration=Release AVX2" /p:PlatformToolset=v110_xp /m. Change
Configuration=... as needed.
Better solution is to require Update 3 for VS2012
The resource compiler cannot compile anything basically. You have to be careful what to include. No fix for vs2012 as they say.
I don't see the link to get the repro from Connect and I'm not too familiar with C++ to try to reproduce this problem myself, but for the past week I've seen a few projects re-enabled builds with VS2012 with Update 3 applied.
On the other hand, I'm all for dropping support for XP, but that's just me.
Yes, this is the xp compatible mode. I just learned that they added this new compiler in update 1, to replace the vs2010 plugin compiler. If you don't use it, not even a simple hello world consol app starts on xp, it just says invalid executable, or something, not a dll dependency thing.

Revision 5695

all: gcc warning clean round 4
* remove unused variable
* move static function from h into cpp
* Initialized hw_by_page to 0xFFFFFFFF instead of -1 (number must be a positive
* Use a s32 fore m_current_lsn instead of u32 (use -1 as error code)
Bonus: a couple of fix for clang compiler (doesn't mean that it fully compile
with clang)
* remove useless __debugbreak on linux
* use short for 16bits atomic function

Revision 5696

* try to setup advance gl context attribute. If driver doesn't support it
fallback to the default.
* use glsl2h to generate an header shader as GSdx. Much easier to install
* Get GSUniformBufferOGL & GSVertexArrayOGL speed improvement from GSdx
* detect current gcc version. Yield a warning if < 4.7 or an error if < 4.5
* support zzogl too
* compute md5sum to avoid useless relink

Revision 5697

gsdx: split shader/program/pipeline object management into a separate class
* remove the possibility to compile shader from file. Some people loads older
The feature might be readded later
Is it mean shader,program,pipeline management being seperated so that it'll easier to diference when it coded?
It means that all codes that handles those objects are separated in a 300 lines file rather than in a middle of 1500 lines file. Aka self contained codes.
It would much easier (from dev PoV) to support different flavor of opengl. It might also ease future improvment.
This is the custom shader thing, right? We're using it on the D3D backend for nice post process shaders :)
Yes it can be used for somethings like that. I'm not sure how it work on D3D. You're loading shader.fx that is in the current dir, right?

Revision 5698

* redo glsl2h.pl script to generate only one big glsl headers.
* fix gcc warning in GSVector.h
* fix memory leak of GSDeviceOGL.m_shader
* clean shader compilation function => split generation header & drop malloc
* only rebuild shader when asked by the use. Avoid perl dependency to build

Revision 5699

gsdx ogl:
* replace vertex interface with block interface. It avoid to depends on the
ARB_sso extension.
* disable geometry shader on Nvidia & Linux. Slower but better than a black
screen !
* default logz to 1, avoid some glitches.

Revision 5700

gsdx ogl:
* uniform was wrongly set before the activation of the program (free driver
* Always use only 1 drawbuffer. Easier besides previous setup was wrong for
GLES trial (v3):
* add the cmake option GLES_API. Note library (libgles) are hardcoded for the
* Disable opengl check
* Disable gl_GetDebugMessageLogARB not supported!
* Emulate gl_DrawElementsBaseVertex, add manually the index offset (surely slow
but work)
* Fix hundred of shader error (no implicit cast of integer to float...)
Unfortunately GLES doesn't support dual blending so no blend in hardware
renderer. Otherwise it is fine

Revision 5701

gsdx ogl: GLes
* use gles header file, disable opengl code (mainly GLX, ARB_sso, geometry
* Define properly the function pointer, GLES use basic linking whereas GL must
get the symbol dynamically
* cmake: properly search and set libglesv2.so
* don't use dual source blending => HW renderer work (only miss unimportant FBA)
Just tested this commit (my last test was r5695) , i'm surprised with improvement ( '0')...games running A LOT faster on opengl render...many thanks. beside, now i can play devil king without issue, thumbs up opengl...b( ^^,)d

Revision 5702

gsdx: forget to regenerate shader in previous commit
Just an update, all i get with OpenGL (hardware) is a black screen. Works with OpenGL (software) just fine. The console outputs the following messages every time though:
3.x GL context successfully created
Supported Opengl version: 3.3.11672 Core Profile/Debug Context on GPU: ATI Radeon HD 4800 Series. Vendor: ATI Technologies Inc.
Buggy driver detected, GL_ARB_separate_shader_objects will be disabled
INFO: GL_ARB_separate_shader_objects is not supported
INFO: GL_ARB_gpu_shader5 is not supported
The driver isn't buggy, but HD4890 has become a part of amd's legacy drivers, so that might explain a few things.
I also did a quick test with Midnight Club 3 DUB Remix. It runs quite well, but crashes always after a while with a stackhash_0a9e error.
Oh, and if you drive through glass, a white foggy layer is stuck on screen, overlaying everything but the car you're driving.
Linux or Winwdows? Amd driver is buggy trust me. What is your driver version? Edit GSdx.ini file and set override_geometry_shader to 0, it will disable geometry shader (it was buggy with previous driver).
Windows 7 SP1 Home Premium x64. Driver 3.3.11672 (think that's for openGL), 8.97.107 (display driver).
Setting the override like you said simply produces an empty white frame in the middle of the screen instead during the load of Crash Nitro Kart (used for testing). Pressing start goes into a loading screen which flashes black rectangles in place of the letters. in the main menu, the cloudbox of the scenery is seen rotating on the top portion of the window, but the rest of the screen is completely black. In the demo screen, the screen is gray, with black rectangles for the DEMO letters again, and some occasional white noise in a single line at the bottom.
Well buggy AMD driver. I try the game on my HD5770 with the opensource driver and I don't get those issue. Better stick with Dx.
I've been playing Dragon Quest 8 recently in Linux, as well as Final Fantasy X-2 and Persona 4 - I must say, good work, they've come from completely unplayable to perfectly playable with minor annoyances, which I presume are also present with the DX9 renderer at least.
Anyways, some things I noticed.
1. F9 does not switch between software/hardware mode
2. Software mode seems to always perform at the speed of 1 thread, no matter how many threads I throw at it (I have a hexacore - I should notice a difference)
3. Sometimes when restarting the renderer, things get drawn "inside out" ( https://dl.dropboxusercontent.com/u/23891252/gsdx_20130718134552.jpg ). Occasionally fixes itself if you reinitialise again.
4. The "Wild-Arms" hack (at least for DQ8) reduces performance to 2 SPF (yes, seconds per frame)
5. Things are generally slower than the DX9 renderer in wine.
And Lastly, it would be great if you could get the Depth Buffer thing sorted.
From what I gather, rendering to a 32bit depth buffers should work just fine if you render to an FBO and blit that to the screen/window. Any other option (as far as I understand) will fall back to 24 bit, Since the GLX Visuals (As listed via glxinfo) only lists formats with 24/16bit depth buffers.
But considering that GSdx understands 'internal resolution,' it's probably already using an FBO...
Also I had to replace the xpad driver with a userspace one (called with --square-axis) to play these games properly. It would be nice if OnePad can take care of this for me so it's just plug and play :)
Anyways, good work, keep it up!

Revision 5703

(Patch by KrossX): Fixed multitap - Part 2 - (e.g. Timesplitters), New: support
raw PSX
memcards (mcd/mcr), Fixed issues with pad 2 (e.g. issue 1326).
These are changes which were left out at r5622, updated to pach v9 by KrossX
from http://forums.pcsx2.net/Thread-Multitap-PCSX2 .
- Please report any issues with memcards corruption/incompatibilities here.
- Please feedback on multitap improvements here.
Thanks, KrossX! :)
I actually loled at this :P
//#define _KELOGS // Krossx's Enhanced LOGS, it has nothing to do with Kellogg's
It'd be nice if the public could test PSX memory card support and Pad changes a bit. If anyone has a PS2 game with PS1 memory card support, please speak up :p
Although I'm not 100% sure, PS2 did not have any games that could save to or read from PSX memory cards. PSX games on the PS2 did require it for saving though and could not use the PS2 memory card. Since PCSX2 does not emulate PS1 games there may be no real way to test this.
I did however test the ability of copying data from a PSX memcard to a PS2 memcard, and then from the PS2 memcard to a blank PSX memcard. I tried 5 different game saves from 5 different games and all seemed to work in the new memcard when loaded in ePSXe. So it would seem its at least reading and writing the data back and forth correctly.
The only game that comes to mind is Suikoden 3. Though I don't think it reads the memcard but instead just expects users to do the transfer through the BIOS. So with transfers working, it would now be supported! =D
PS: I thought I had removed KELOGS. >_<
Krossx, there's a memory cards bug report with r5703 here: http://forums.pcsx2.net/Thread-Memory-Card-problems--37832
Could you please have a look at it?
Roger roger.
I downloaded a dexdrive save for Suikoden 2 from GameFAQ's, converted it to MCR format, loaded it in PCSX2 and copied the save data to a PS2 memory card. Success, Suikoden 3 successfully loads the Suikoden 2 data.
villorih: You probably have the wrong memory cards folder configured. Check what path PCSX2 uses by using the memory card editor.
Thanks for testing guys :)
From another commit:
Comment by sortxl, Today (2 hours ago)
I can no longer save in God Hand (both JP and US version), whenever I save, the game hangs in the save screen. When I go to BIOS screen to view memory card, there is a Broken Data.
Pls fix this. Maybe it has something to do with r5703 memcard update.
New build in the linked thread. Tests will be more than welcomed.
Negative, cuz I messed up Persona 3. And you don't mess up with Persona 3. ò.ó
There's a few new issues under the issues section for mcds, they might be fixed with the new build though.

Revision 5704

gsdx ogl:
* allow to switch renderer with F9
* skip first frame in stat of the replayer
* drop msaa. Fxaa and internal resolution will do the job
* move texture attachment from texture object into device object (allow to keep
sanely the state)
* split the write buffer and attachment setup
* completely split sampler and texture input setup
* redo GSDeviceOGL::CopyOffscreen to avoid an extra copy.
Affect what on games?
Dropping MSAA is a bad decision. FXAA simply cannot cover all that internal resolution does - ESPECIALLY when a large number of games render at a fraction of the native resolution, leading to aliasing which is NOT pixel sized and for the most part will NOT be covered by FXAA. As far as I know, PCSX2 does not offer a workaround to this, and I doubt a workaround is even possible. MSAA does cover such edges, and when combined with transparency antialiasing can do a far better job for FAR less performance than high internal resolution + FXAA.
(And that's not even mentioning how the resizing process PCSX2 uses to downsample the internal resolution to the display resolution often leads to more aliasing overall than FXAA+high IR on games that render at full resolution. But that is another problem.)
Normally it mustn't affect games. It is mostly cleaning to make the code easier (in case of future improvement). If I'm lucky I'm might had fixed a bug or two in my implementations.
You might be right about AA stuff. But reality is opengl implementation are full of bugs, it's even worse on linux. I already struggle to make basic feature work so advance AA is clearly out of the scope. So for the time being, fxaa and internal resolution will be enough.
sirhax0rzero: He dropped MSAA, not the internal resolution. And ONLY on the OpenGL backend. If you want supersampling, just set the internal resolution bigger than the screen.
gregory.hainaut: Perfectly understandable.
gigaherz: Are you sure you read my comment right? I don't "want supersampling". My point was that you shouldn't assume increasing IR to be the best solution. For games like Zone of the Enders and Valkyrie Profile 2 FXAA will not work and the internal resolution will need to be increased to about thrice the display resolution for them to look sharp because they run at a fraction of the IR.
You are right, I didn't read you right: I read "FXAA simply cannot cover all that internal resolution does" as "cover all the cases of", not "mask all the aliasing created by".

Revision 5705

Working on my backlog: GSdx CRC patches.
Takes care of issues 1357 and 1406.
What is it for? Thanks
It fixes issues https://code.google.com/p/pcsx2/issues/detail?id=1357 and https://code.google.com/p/pcsx2/issues/detail?id=1406
I can no longer save in God Hand (both JP and US version), whenever I save, the game hangs in the save screen. When I go to BIOS screen to view memory card, there is a Broken Data.
Pls fix this. Maybe it has something to do with r5703 memcard update.
If it's a problem with r5703, why don't you comment on r5703 instead of here? The one who commited that change may not be reading this commit's comments.

Revision 5706

(Patch by KrossX) - Fix memory card issues from r5703 (should fix Persona 3/4,
possibly MGS3, possibly others).
Please report here if there are still games which suffer from memory card
issues. Thanks to KrossX for the quick fix.
I know this one probably isnt the issue, but Metal Gear Solid 3 (SLES-82042) memcards are not working.
if you have facebook: https://www.facebook.com/photo.php?fbid=609736905727906&set=gm.10151825542449560&type=1&theater
if not, let me know and ill put the pic elsewhere.
The picture shows him using 5706 btw. It just streams a load of unknown commands (out of sync?)
Thanks ref, I'll look into it. *stars to get mails*
I can load games in MGS3 PAL here but I get these logs:
memcardTransfer cmd: ED??
memcardTransfer cmd: C6??
memcardTransfer cmd: EA??
memcardTransfer cmd: ED??
memcardTransfer cmd: C6??
memcardTransfer cmd: EA??
etc etc
@rama: Can you use this build please and send me the logs?
That will help until I can test it myself.
I'm not sure you want these logs, they're huge.
Sure I want, just 7zip them.
It doesn't show any memcardTransfer log. =(
How about this one. It will enable logs only in the cases you posted.
Well, now the log looks just like this regular build (5706) but here you go anyway: http://www.sendspace.com/file/wj5t3m
First loaded a game then saved it, overwriting the old one.
And indeed it should look normal... cuz I put the thing after the break; ... Sorry~ >_<
Okay, this time any memory card checks by the game didnt trigger any logs.
Actually loading a saved game did though:
(Sorry for the late reply, but you can find me on irc :p )
Too late! =P
Try this fix tryout (patch included)
Worked for me. I could save and load fine. Warnings would still show up but I moved them to DevCon.
Okay, will try this. But I could save and load fine with this revision too!
The person that reported a problem may have a different game version or smth.
So basically the unknown variable is that one size parameter?
And these builds fiddle around the issue until all test games work?
This wouldn't be new for PCSX2 but we should document what's going on here :p
Nope, no fiddling around. Problem is garbage, I made a post in here:
Xenosaga I still suffers from problems when attempting to use some save points in the game, while others work fine. When using the affected save points, it takes you to the memory card management screen as if you had reset the system.

Revision 5707

gsdx ogl:
* add a non-working hack: UserHacks_DateGL4, goal was to replace
+ Detection of good/bad samples is based on primitive ID variable. However I'm
not sure
the behavior is always the same between draw call...Anyway let's keep a copy of
the current
* Dump integer texture into text csv
* add gl4.2 ARB_shader_image_load_store extension (needed by UserHacks_DateGL4)

Revision 5708

gsdx ogl: oups forget to disable stencil debug

Revision 5709

miss another debug stuff

Revision 5710

Memcard patch #3 (KrossX): Should help Metal Gear Solid 3.
I noticed that Persona 3 does this when formatting a memory card (64mb):
(FileMcd) Warning: checksum sector overwritten. (0)
It may be expected behabiour and I need to check if other games (or the BIOS) do this as well.
It's expected, specially during format.

Revision 5711

gsdx ogl:
* preliminary work for GL4.4 extensions (ARB_clear_texture & ARB_multi_bind).
Disabled until I got a 4.4 driver
Note: I plan also to use ARB_buffer_storage
* compute texture gl option in the constructor (avoid a couple of swith case)
* redo texture unit management. Unit 0-2 for shaders, Unit 3 for texture
operations. MultiBind will allow to bind
shader input without disturbing texture binding points.

Revision 5712

gsdx ogl: AMD users upgrade to 13.8 now ;)
* clean extension management and fix compilation of previous gl44 code.
* Use pixel buffer object to upload texture data.
=> avoid crash on AMD driver
=> a bit faster and probably got some margins for the future

Revision 5713

gsdx ogl: various minor optimization.
* move most of gl states into a separate namespace. Extend it to
depth/stencil/blend micro state
=> save 10,000 opengl call by frame for colin mcrae 3
* Only setup blend state of first drawbuffer
* Don't request anymore a debug context on dev/release build

Revision 5714

gsdx ogl: remove useless ps.rt
Note: I think we can do the same on DX11
Perf wise: on colin mcrae 3 it reduces shader prog setup from 3005 to 2086 each
frames. It saves 2 ms of CPU processing (27->29fps)
2 frames are always better than 0 frames :)
More speed on ogl, great! (^^ )
I'm probably wrong about this would the unimplemented 24bpp in [code]void GPULocalMemory::SaveBMP(const string& fn, const GSVector4i& r2, int tp, int cx, int cy)[/code] have something to do with the slower gfx on memory hungry games? I was looking in this branch to see if I could find the memory manager, I still haven't learnt gfx based code yet so I was just looking at what I could find
Quick link:
First better look the trunk. SaveBMP is only a debugging stuff that is never called.
What do you search exactly? memory manager doesn't make any sense.
I just browsed the files looking for names that could potentially contain the manager, I didn't know it was debug only I'll try another hunt later, anything I should look out for?
but what is for you the memory manager? Which memory the ps2? Or your gpu memory?
A hint:gpu... file is ps1 and gs... file is ps2:)
I was looking for the gpu one, I wanted to examine the memory manager after locating the 2 functions that load/save textures see if I can find ways to speed it up, it'd be difficult to help with gfx code since I still new to that, memory on the other hand is much simpler in comparison.
The upload is done by "Update" function in GSTexture* files.
GSTextureCache manages textures transfers by far the most complex part of GSdx.
PS2 architecture is small memory (4MB) with a high bandwith link. PC is high memory (+100MB) with a slow bandwith link (and high latency). If you want to upload texture faster.
1/ Use pciev3 (if they didn't increase latency in favor of bandwith otherwise it would be slower). I'm not sure of the result.
2 Use an APU and recode a big chunk of GSdx to avoid any useless copy. The main issue is APU => AMD which got a slower CPU (bad for emulation).
Thanks, when I finish up with what I'm doing I'll download a trunk copy and see what I can do, I'll use "Champions of Norrath" to check the effectiveness of my code. I'll upload a ZIP to my GDrive if I get it faster.
generaly when you make somethings faster for a game, you broke 100 others ;)
Good luck.
Unlikely, it's just memory and I'll test against my other 129 games before uploading the ZIP.
Do you know of the pcsx2dev irc channel? It's better to drop by there and see if we can't help you more directly.
I wouldn't be a regular, I get bored easily so I come back to projects when I'm in the mood for them. Thanks for informing me though, I'll give it some consideration. Right now I'm trying to write a custom framework in c89 so my focus isn't currently on pcsx2, I'll make a note of the revision I download when I do focus on this properly. As it is I'm just dabbling.

Revision 5715

gsdx ogl: Test the ARB_shader_subroutine GL4.0 extension
The idea was to replace shader program swith by pointer function calls inside
shaders. At least parameters that are often changed between draw call. So far
I only ported atst and colclip. Unfortunately code is "slower" (on GSdx
For the moment keep the code but disabled.
If I understand well the validation of program is done in the "driver thread"
but the additional call are done in the overloaded MTGS thread. Apitrace
profiling shows faster GPU draw calls. Another possibility is that the driver
need to validate the draw call because of others state change.
Here some stats on colin3 (90 frames):
without subroutine: UseProgram 125246
with subroutine: UseProgram 2906, subroutine 125945 => 3605 extra calls overhead
all parameters are ported to subroutine)
If you have any of the 3 Xenosaga games, you can try this code on them.
These games produce an enormous draw call overhead and might benefit from this.
Ok. Thanks for the info. I will also test it on the nvidia implementation. It might work better (extension was dev by Nvidia).
Good news, I test(/debug) my code on nvidia and I got a +4fps (42=>46) boost on colin3 (vs -1 on amd!). I'm currently looking xenosaga 1. As colin3, render updates shader every draw call so we might have a similar performance boost but I will need to port others shader parameters to subroutines. However I got an annoying glitch, message doesn't appears in textbox, do you have the same issue on Dx?

Revision 5716

Finishing up widescreen patch support: Add GUI toggle and connect it.
Thanks! :)

Revision 5717

Uploading all patches from the PS2 Widescreen Pack dated 08-11-2013.
Patches contributed by members of the community and assembled by devina40.
Thanks people! :)
It's currently untested if the patches play nicely with regular cheats, will do
that later.
Note: Some patches have an upper case file extension that could cause issues on Linux. Do we have internal handling for that?
simply brilliant!!!
Somehow it should be documented what games have the widescreen patch support.
For example: Someone loads a game on 4:3 but theres a widescreen patch for that game.... perhaps an option in PCSX2 to automatically change aspect ratio 16:9?
It's a freaking mess.
Please try to add subfolder-support so that these pnachs can be put into folders as devina40 has done it in her compilation.
If you do add this support, please make it so that pnachs in folders named "16-10" or "16_10" are ignored (at least for now).
That way pnachs set to 16:10-mode can be added in a subfolder, which would make it easy for people to simply replace the 16:9-pnach with the 16:10-pnach.
It's a freaking bad way to start a support request.
I was hoping to keep this simple with an on/off switch for widescreen patching.
Having more options requires more complexity in code and maintenence.
If this is going to be more complex then we need to do it properly and come up with functional specs and a layout for presentation first.
i'd put them in a wide screen database file not too different from the current GDB

Revision 5718

gsdx ogl: Used a basic flat interpolation for color interpolation (line & tri
Card that support gs:
remain only a gs to generate sprite from a line. Even dummy gs are costly for
the GPU.
Card that don't support gs:
remove useless copy of color for line and triangle primitives
Note for dx: opengl 3.2 (maybe not gles) supports both flat interpolation
be possible to shuffle vertex index to put the last vertex in first position.
- buff[0] = head + 0;
- buff[1] = head + 1;
- buff[2] = head + 2;
+ buff[0] = head + 2;
+ buff[1] = head + 1;
+ buff[2] = head + 0;
I would not touch that last vertex thing, several other things may rely on it already.
Btw gregory: I would've tested this on Linux with my Nvidia card already but the OS is so annoying, I can't stand it.
Nothing really works right. You need to work around bugs in the audio manager because settings don't stick, you need to live with theming not working right under any desktop environment and then the old shutdown bug where the thing just forgets how to unmount / kicks in again.
I really wonder how you can say you don't have any of this, since I get it with all Linux installations..
Sorry for the rant but I already wasted so much time on this, I wish I knew of a *working* Linux distro.
Hum, I think it would be better to fix vsync on gsdx ogl (window) so you can compare dx/ogl. Normally linux only got more bug on the GPU driver ;) Anyway Perf-wise I think I'm slower than Dx because of Vertex upload.
>> You need to work around bugs in the audio manager because settings don't stick
I already got this one few years ago.
Otherwise I never saw the others, I guess I don't do anything fancy with my computer (my DE is kind of win2000 era). Well I surely encounter others bug but generally I find a configuration/workaround that work. My configuration files are 3-6 years old!
Is it normal that the entire DE freezes when you need to force close a program? I just click okay to the "end this application" window (PCSX2 died) and there goes any way to interact with the machine. Thankfully I knew the ctrl+alt+f2 way and could do startx from there.
So yea, I have the PCSX2 ppa working now. On to setting up the build environment! :p
Alright, got everything working and it appears many games are playable in GL hardware :)
Why not give Arch a go? It's the best distro I've used to date, but unfortunately is rather involved in the setup process. I'd advise keeping a second device around to check the wiki, or to do it in a VM first.
https://wiki.archlinux.org/index.php/Beginners%27_Guide (a must if it's your first time)
Just be sure to install KDE, and an AUR helper like yaourt. Just avoid pulling in pulseaudio, and everything should be golden :)
> Is it normal that the entire DE freezes when you need to force close a program?
If it was, they wouldn't offer the functionality to begin with :P
I figure the issue is intrinsic to X and should disappear as wayland gains traction - At least every instance I can remember that involved a complete lockup of my desktop, X was acting up somehow.
Next time I feel like torture, billy65bob :p
For now I'm glad I got everything working on Kubuntu x86.
Even my Recon3D sound card makes sounds, which is just awesome.
That's the problem ramapcsx2, you are using Kubuntu xDDD, It's the worst Linux Distro ever!! xDDD. You can always give it a try to Debian (I'm in Debian Wheezy x64 with no problems at all besides the speed in pcsx2)
I had them all. Debian had some other issues on my machine.
cool :)
Did you test latest svn or only ppa?
I used the svn version :). The last one, which means, this one :P
I ran this one as well, compiled on Kubuntu x86 using the directions given on the wiki for compiling with cmake.
So while many games run without glitches, I noticed severe performance issues still.
FFX for example runs the intro at some 30FPS now (OGL hardware) while on Windows I get 120FPS.
I did install the proprietary Nvidia driver (313).
Yes I know. I don't understand why I'm so slow! However it is strange for FFX, what do you call the intro exactly. The part before you can play, and autograph stuff? I got more than 50fps (EE limited). Could it be a vsync issue.
I think the main culprit are 1/ the upload of the vertex data. Probably got some driver sync that kill the performance. I try unsync access with map/unmap but strangely it is tad slower.
2/ my multithread hack to support GSreadfifo. I detach/reattach the context. It could take 25ms!
There's something really weird going on.
I've done a few runs, I seem to be getting consistently good performance via full boot and consistently bad performance via fast boot, and after reinitialising the renderer.
Win or Linux?
On both OS, I will recommand to force no Vsync in the driver. I would need to fix this stuff too.
Anyway, I will see that after my summer vacation break ;)
Enjoy the break then :)
And yea, turning off vsync should be next.
^ Scene with 30FPS in Linux
Linux of course.
In regards to vsync, I've it turned off more or less universally, and the options are also ticked as off in the PCSX2 settings.
But there are times PCSX2 won't go above 60 FPS for whatever reason, but will happily run at 50FPS for PAL games (and go up to 60 if you enable turbo mode) despite the GS thread reporting lots of free processing power.
But this issue seems unrelated; performance is poor and at 32 FPS and the GS thread is reporting full utilisation.
I dunno, as I said a few hours back, when I was playing around, I got decent performance if I did a full boot, and terrible/lackluster performance if I did a fast boot, or reinitialised the renderer.
I wish I could help more, but there doesn't seem to be much consistency in it.
https://dl.dropboxusercontent.com/u/23891252/ffx1.jpg <-- even when it's performing well, the FPS in that scene for example is fluctuating between 60 and 90.
https://dl.dropboxusercontent.com/u/23891252/ffx.jpg <-- and when it's not doing so well, fluctuating between 28-40
Hum, there is too much copy/sync overhead in my code. Sometimes code just waiting completion of the opengl command that why GS isn't at 100%. Code is still young, more optimization will come later.
The full/fast boot issue is interesting. I remember that zzogl suffer a similar issue (fps much lower than expected). If I can reproduce it maybe I could fix it. Well let's put it on my todo list ;)
It's impressive how well you got it working anyway! :p
Thanks. Biggest challenge was AMD opengl driver quality (crash every 5 seconds, lots of graphical errors). Fortunately they fix a lots of bug in their latest beta, now I can start a game ;)

Revision 5719

Pleasing devina40 ;) ("WideScreen" -> "Widescreen" at the menu)
Oh yea, the big s was silly :p

Revision 5720

gsdx ogl:
* some preliminary work to test/benchmark bindless texture in the future (glsl
was not yet updated)
Bindless texture allow to get a GPU texture pointer and then set it directly
to the shader as a basic uniform.
=> no more texture unit selection/validation
=> no more texture validation neither texture hash lookup
3rdparty: update gl header to the latest gl4.4

Revision 5721

gsdx ogl:
* redo most of the texture upload (PBO): colin3 benchmark: 32 fps now (vs 26 fps
2 weeks ago)
* use the cross vendor vsync extension on linux (previous wasn't supported by
Updates! :p
So I tested FFX on Windows with OGl hardware and it's pretty much in the same broken state as always. I did get the same FPS as with DX though.
3.x GL context successfully created
Failed to find glUniformSubroutinesuiv
Failed to find glCLearTexImage
Failed to find glBindTextures
Failed to find glBufferStorage
Failed to find glGetTextureSamplerHandleARB
Failed to find glMakeTextureHandleResidentARB
Failed to find glMakeTextureHandleNonResidentARB
Failed to find glUniformHandleui64vARB
Failed to find glProgramUniformHandleui64vARB
Supported Opengl version: 3.3.0 on GPU: GeForce GTX 670/PCIe/SSE2. Vendor: NVIDIA Corporation
INFO: GL_ARB_clear_texture is not supported
INFO: GL_ARB_buffer_storage is not supported
INFO: GL_ARB_shader_subroutine is not supported
INFO: GL_ARB_multi_bind is not supported
INFO: GL_ARB_bindless_texture is not supported
What do you mean by broken? Black screen, in this case try to disable geometry shader in GSdx.ini (override_geometry_shader = 0)
> Failed to find glUniformSubroutinesuiv
This error isn't normal (but unused anyway).
The others function are GL4.4.
Hum, it might be possible that a DX option, pollute my code (i.e. forget to implement/debug a stuff). Can you do a diff between GSdx.ini win vs linux.
override_geometry_shader = 0 did the trick!
Looks impressive now and is fast.
A really quick FPS test suggests it's maybe 30% slower than DX on Windows.
Both renderers now look the same in the games I tried, just perfect.
Cool. Some Nvidia linux users got the same issue with geomtry_shader. I would need to debug it. I think I will wait an implementation of the free driver to find which implementation is wrong AMD or Nvidia.
Installing latest beta drivers now. "Supports OpenGL 4.3 for GeForce 400-series and later GPUs."
Well, no change in the logs. Still says "Supported Opengl version: 3.3.0".
I think Nvidia got another branch for openGL 4.4. Anyway code is not yet finished in GSdx to support future extension properly (and I'm not sure they will improve the final speed).
Alright. Just tried Valkyrie Profile 2 which has a couple D3D problems and OGl looks and plays just the same in this game. This is still impressive as the engine is pretty demanding and uses lots of effects.
Opengl and DX got mostly same limitation, so I might be close to be bug compatible with DX :p
I think I can fix DATE but I'm nearly sure my driver is broken...
For blend, Nvidia add lots of equation recently: http://www.opengl.org/registry/specs/NV/blend_equation_advanced.txt
Let's hope we can fix a couple of blend limitation.
>>> Well, no change in the logs. Still says "Supported Opengl version: 3.3.0".
I miss this one ;) Actually I request a 3.3 context so you get max 3.3, but don't worry I can still used advance gl4 features.
Pseudonym created the current blend table (with lots of swearing :p), he can prolly help decide if the new blend modes will be useful.
good job ;-)
continue PCsx2 is the Best Emu PS2
test in GT4 Pal French
good Frame
Real nice, I got great speed in Hardware mode now, thanks :D
This isn't 100% to do with this branch but I've noticed that the half-screen issue on hardware mode seems to have something to do with the re/draw routine, it may be that the RECT is not being invalidated before drawing begins, I only noticed because I was playing Champions of Norrath and saw that whenever the scene changed it had partial success on the first draw of that half of the screen/window, it was only after moving that it blurred completely.
TOA is almost good (still weird errors in graphics xD)in hardware mode, the speed is awesome, it's faster than in software mode :D, nice!!!
I'm going to bed but could someone point me in the right direction for finding the code that renders each RECT or whatever you've been using, I finally got round to downloading the source and am trying to fix this half screen issue (probably in vain though). I'll check back in the morning.
GSdx is hard to to work with, not many can anwser your question gb2985.
You need to know a little on how the GS works, then try to debug the drawing
sequence this game does. The error is most likely in the "back end" caching or the cache lookup, meaning it's the emulation part (and not the rendering stage).
Fair enough, I've trying since about 7 this morning to fix it, no luck so far but I'll keep trying.
I checked it and the gl renderer has the same problem. It's definitely a back end texture cache issue then.
Check everything around GSTextureCache::Target::Update().
Had a tiny bit of success, instead of the usual blured side when playing I managed to get it to occasionally draw the screen correctly (before freezing that side again):
I modified GSTextureChache::SourceMap::Add to look like this:
//m_map[TEX0.TBP0 >> 5].push_front(s);
const GSLocalMemory::psm_t& psm = GSLocalMemory::m_psm[TEX0.PSM];
GSVector2i bs = (TEX0.TBP0 & 31) == 0 ? psm.pgs : psm.bs;
int tw = 1 << TEX0.TW;
int th = 1 << TEX0.TH;
for(int y = 0; y < th; y += bs.y)
uint32 base = o->block.row[y >> 3];
for(int x = 0; x < tw; x += bs.x)
uint32 page = (base + o->block.col[x >> 3]) >> 5;
if(page < MAX_PAGES)
m_pages[page >> 5] |= 1 << (page & 31);
for(size_t i = 0; i < countof(m_pages); i++)
if(uint32 p = m_pages[i])
m_pages[i] = 0;
list<Source*>* m = &m_map[i << 5];
unsigned long j;
while(_BitScanForward(&j, p))
p ^= 1 << j;
}[/code] The above screenshot was the result.
Since I don't know how the RenderTarget mode is supposed to work I haven't tried adding anything to it's handling, on the other hand I have noticed that at the moments when I can see the other half of the screen the special effects are missing from it, any ideas where I should look for that? It might be part of the problem.
Scratch that I think it may be the Z pos that is causing the missing effects, gonna look around for handlers of that.
Sorry I'm not technical but is there any purpose in me switching to OGL from DX11 or is the main benefit for non-Windows users? Thanks
Not until the developers consider it ready, OGL as an API is faster than DX but that speed needs to be taken advantage of the right way otherwise it can be slower than DX.
Pretty exciting you got somewhere, gb2985. I've only managed to move the split in the image a couple pixels to the right with my hacking attempts. That never lead anywhere though.
Could you share your future work with regular patches please? It's far easier to compare the differences then. (Tortuise SVN menu > Check for modifications > rightclick changed files > Create Patch)
I don't get any different results with your changes though. What game are you using to test?
Im guessing champions of norrath
Been at work, so far that was as far as I got and yes CoN was the game I tested on, figured I'd test it on other games once I kill the black half during boot, as for the patch thing I didn't realize I could do that, thought only dev team could do that, I'll do that in a minute after double checking my results. I notice however there are a lot of FIXMEs, since I haven't got any true idea of what was happening in that code I just left it alone but someone who does should really get round to cleaning them up (along with filling the empty TODOs if they can)
Ah now I understand the patch system better, here it is:
Still haven't tested it on any other games but it is some progress.
You'll find some NOTEs are now there, I was trying to fiddle around with the Z-order and so other things were modified just because the warnings were annoying me.
Should've also mentioned that I moved a function into it's own file to make it easier for me to find, you're welcome to put it back if you want.
What are all these random changes there?
memset(dimx, 0, sizeof(GSVector4i) * 8); << Huh?
Anyway, you can select just a single file for a patch. This way I can see only the relevant changes :)
m_map[m_current_pbo] == NULL; << nice find there, thanks :p
Unfortunately I only get garbage with the patch applied.
Some of those changes I don't even recognize which makes me wonder how they got there, no matter if they of help then all the better. Still trying to to get to the root of the problem myself though, but maybe I'll stumble across something like I did with the Add() function
ah now I remember, I changed memset(dimx, 0, sizeof(GSVector4i) * 8); because from what I know sizeof only gets the sizeof the variable not arrays or objects/integers so it made more sense to grab the size of the class and multiply it by the number of elements.
Had to look at the patch before I remembered how I caught the equal thing, the compiler complained, simple as that.
gone to bed
I've no more ideas for now, be quite a while b4 I manage to provide another patch no doubt.
> What do you mean by broken? Black screen, in this case try to disable geometry shader in GSdx.ini (override_geometry_shader = 0)
If that's commonly needed on windows, can this somehow be 0 by default?
Hum for the moment I only got issue with (some) nvidia card/driver. AMD is fine. Initially I force it at 0 on linux but since r5724 I force it also on window (not tested). It must print "Buggy driver detected. Geometry shaders will be disabled\n" on stderr

Revision 5722

CDVD/BIOS/NVM: When creating a blank NVM file, write a dummy value to the ILink
area. This is read by Age of Empires 2 and fails to load if it doesn't exist.
This should work with all BIOS versions, please make sure you delete your NVM
first then run the emulator to generate it. Of course if you have an NVM file
from your PS2, you shouldn't need this :)
Oh, this is something new :p
Think any other games run into this issue?
I believe many people have dummy nvm files..
Its possible :p
I had this error never before because I use only a real nvm file from my ps2.
Then this will never concern you :)

Revision 5723

Just fixing this oversight. Thanks, gb2985.
ur welcome
What other games were there that had the half screen issue (aside from BG:DA), if I have them I can see whether my changes had any effect on them too.
any running the snowblind engine. Bards Tale i think is another one
Fallout: Brotherhood of Steel is another
Justice League Heroes
Well I have bards tale so I'll try that.
From what I can see there seems to be some sort of memory corruption, without modifications it just displays some garbled purple stuff, with modifications it becomes a less garbled green mess instead. Not sure what to make of this. I'm gonna have to hit the sack now since I got work at 6 in the morning so I won't be responding until about 2 onwards.
yes cool
now my games : Tokyo Xtreme Racer - Zero (USA) WORK !!!
GOOD Job GUYS !! ;-)
There was no change here, Christophe.Philippi.
Unless you manually applied the patch and recompiled GSdx, there was no fix in this revision.

Revision 5724

onepad: fix a bug to handle multiple button (fix #1271)
zzogl: fix memory leak (fix #1431, #1432)
GSdx ogl: disable geometry shader on Nvidia/Windows (I will wait a 3rd
implementation to find which one is correct)

Revision 5725

gsdx ogl: the proof of concept commit
* GL_ARB_shader_subroutine for perf
fix for nvidia => add missing shader declaration. Nvidia got +4fps on colin3 :)
For the moment only 2 PS parameters are supported. Code need to be extended to
support others games that often
switch shader program (like xenosaga).
require GL4 class hardware and the option override_GL_ARB_shader_subroutine = 1
Note: strangely on AMD linux it is slower!
* GL_ARB_shader_image_load_store for accuraccy (Date)
Use a signed integer texture and reenable color buffer writing
Current status: Amagami_transparency.gs & P3_battle_shadows.gs are now working
on Nvidia with a small perf impact.
Current implementation detail:
1/ setup the standard stencil as before
2/ on remaining pixel, draw once to compute first primitive that will write a
fail alpha value.
3/ final draw based on primitive id of step 2
Note: I think we would get a bad behavior if depth test&mask are enabled on step
Note2: on my limited testcase the perf impact was on CPU. It would be possible
to merge step1&2 to nullifying it (could
even be faster actually), however it would require more GPU power.
Again require GL4 class hardware. And the option UserHacks_DateGL4 = 1
Once again done a good job gregory, but no change to the GSdx/GSThread.h this time?
not yet because I don t understand yet what is going on. c++ requires the base class got a destructor so my change is normally correct. It would be helpful to get a windows backtrace. By the way did you get the crash every times you switch the renderer?
Yes every time after you have changed three times between hardware and software mode.
every game? can you post uour gsdx.ini
No only Gran Turismo 3 - A-Spec perhaps God of War 2 is also affected, but without an error message.
GSdx settings Gran Turismo 3 - A-Spec
Ok thanks. Hum maybe I need to increase the number of thread on my side. Did you test opengl :p I think I have the game :)
Yes I have tested OpenGL, but I only get 40 FPS in Gran Turismo 3 - A-Spec.
Well my question was did you get same issue with the opengl rendere switch (that being said not sure I implement it on MS)
OpenGL runs without problem.
tfx.glsl (entry vs_main, prog 54) :
#define VS_BPPZ 1
#define VS_LOGZ 1
#define VS_TME 1
#define VS_FST 1
0(112) : error C1101: ambiguous overloaded function reference "exp2(int)"
(0) : lowp float exp2(lowp float)
(0) : mediump float exp2(mediump float)
(0) : float exp2(float)
tfx.glsl (entry vs_main, prog 55) :
#define VS_BPPZ 2
#define VS_LOGZ 1
#define VS_TME 1
#define VS_FST 1
0(112) : error C1101: ambiguous overloaded function reference "exp2(int)"
(0) : lowp float exp2(lowp float)
(0) : mediump float exp2(mediump float)
(0) : float exp2(float)
tfx.glsl (entry vs_main, prog 56) :
#define VS_BPPZ 3
#define VS_L Loading GS
#define VS_TME 1
#define VS_FST 1
0(112) : error C1101: ambiguous overloaded function reference "exp2(int)"
(0) : lowp float exp2(lowp float)
(0) : mediump float exp2(mediump float)
(0) : float exp2(float)
Suspending single plugin: GS
Saving GS
Closing GS
Recovering single plugin: GS
Opening GS
Forced software switch enabled.
Loading GS
override_GL_ARB_shader_subroutine = 1 produce 2D (OSD, health bars, menu buttons etc.) blinking in Onimusha Warlords, also alpha test (?) issue is here for about 1000 revision, OpenGL is affected too.
AMD hardware here (Supported Opengl version: 3.3.12441 Core Profile/Debug Context on GPU: AMD Radeon HD 6800 Series. Vendor: ATI Technologies Inc.)
Thanks for the info, I will test the game.
By the way, will you be able to find which revision introduce the alpha issue. I miss some text on xenosaga but it could be a gsdx frontend bug.
This is very old issue (see Issue 951), it affect all hardware backends, software are bug free.
I have tested extensively in the last days God of War 2 and can tell you that the error in God of War 2 is not caused by the GS plugin.
The oldest version I tested with God of War 2 is the PCSX2.exe R.5384, the game runs without crashing when switching between hardware and software mode.
What about newest that doesn't crash? That would be much more helpful.
I suspect its happened in the last 200 revs
Sry, I just wanted to help.
You still can help, but we need to know when it broke, knowing it used to work ages ago doesnt really help us progress.
A backtrace would be very helpful.
@ gregory, I have sent you an email.
Thanks but that not a backtrace (or stacktrace). Unfortunately no clue how to get it on windows!
You will need to run pcsx2 in VS (I don't know if you can attach to the process)
Thanks for the info, but I can not install Visual Studio on my Windows 7 because it affects other programs.
And below W2K8/R2 i can not run PCSX2 in Hyper-V, because I do not have direct access to my video card and sound card in the virtual machine.
Is it possible to do that?
1/ install
2/ get the stacktrace
3/ uninstall
It sounds a lot like a typical crash from reinitializing GSdx while the emu runs. Neither PCSX2 nor GSdx were designed for this. The crashes like to appear randomly on unrelated code / compiler / weather of the day changes, too.
I doubt a stacktrace can tell us any more than the usual "it's memory corruption somewhere".
Well, I wanted to know if it the same issue as linux (so easier for me to debug).
Anyway, I decide to open the memory corruption chase :p
I found an ugly thing. The following function which try to compute the size of an array based on last element.
static int _calcEnumLength( const wxChar* const* enumArray )
while( *enumArray != NULL )
Called with this kind of array for example:
static const wxChar* DocsFolderModeNames[] =
# Error not NULL terminated.
Not sure if the array must be updated or the function removed.
Huh. Yeah, that function's not appropriate for that type of array. Because of how it's used, the right answer is just to NULL terminate the array.
On Windows it seems this isn't working at all. Also I'm not sure if this is new but I think there is a regression where some screens don't draw anymore.
I gave my SSD with Linux on it away, so can't check that right now :p
> On Windows it seems this isn't working at all
What does not work?
The regression is possible, I miss some stuff in xenosaga. I change lots of code recently.
The DATE fix that would make the Persona 3 shadows work properly doesn't work on Windows :p
I need to double check it. Note did you disable Pseudo's hack (UserHacks_AlphaStencil)?
Yea I didn't have any user hacks enabled. Do I need to to make your fix work? (Didn't read the changeset :p )
Hum, you did enable UserHacks_DateGL4 !

Revision 5726

pcsx2: fix 4 arrays out of bond
Gsdx: fix a memcpy src/dst overlap + a clang compilation fix
Awesome :)
That was easy. Gcc got an adress checker tool :p Unfortunately I got some bug on the tool otherwise I would had find much more memory overflow/corruption.
Are you sure that there was an overlap in that memcpy? Was it detected at runtime that an actual overlap existed? Or can you read the code and deduce that an overlap may exist under some conditions?
>> Or can you read the code and deduce that an overlap may exist under some conditions?
Didn't tell you that I wasn't human :p
Address sanitizer got a memcpy interceptor that check the memcpy parameter at runtime. Now if you look carefully the code, the memcpy emulate a shift register array. It remove the first n element and copy the remaining N-n element at the beginning. So overlap will exist if N-n > n. At runtime I got N = 3 and n = 1.
> So overlap will exist if N-n > n
Yeah, I got to that point as well, but didn't go further back to understand if this is a valid case. From your description of N/n = 3/1 it seems it can happen.
However, Looking at this function in general, it asks to flush count items, and this copy happens afterwords. I wouldn't be surprised if it's just some filler where these extra items are never actually used.
Also, depending on compiler implementation, a compiler may decide to use memmove for memcpy, and IIRC VS even does that. In practice, it may involve only a single extra instruction (test required direction), though I don't know if backward propagation is slower than forward one.
Overall, while memmove is better than memcpy in most cases, we don't know if this memcpy resulted in an actual bug. If it did, then changing to memmove could have fixed it, or at least changed the behavior. If that was the case, it would be interesting to know what was affected (i.e. how would some games have less/different visual bugs or less crashes etc).
Also, let's assume the worse just for the sake of this argument, if this is super-hot code (i.e. happens a lot during runtime), and the values copied in that memcpy are not actually used, and if memcpy is faster than memmove, it could have a measurable performance regression.
I'd guess the above doesn't happen, but it could. Bottom line, it would be really nice to understand how this change affects the micro/macro, if at all.
Actually it is not the "compiler" choice, it depends on the libc (or c++) implementation. Several years ago some app devs asks the gnu libc dev to replace memcpy by memmove (better security but slower). His answer was no. The maintainer was replaced but I don't know if they change memcpy implementation.
Anyway, if speed matter, we could do the 'N>2n' check and select either memcpy/memmove. If speed really matter, maybe improve the algorith :) However relying on an undefined behavior is a no-go for me (MS vs Linux vs MAC vs others system). One day it would break for sure. However improvement is always welcome.
My point was that while this could be a great change (in general and/or specifically) and maybe it even fix some real bugs, it's really bad that we don't know how this change affects GSdx and if real bugs are indeed fixed :)
Why not just toggle it and throw the setting in the speedhacks?
If its really something that should be done, and the other way is slightly faster then why not.
Unless by adding 2 diff code paths slows it down..
Otherwise I'm for the fix, as long as it has an actual effect of some sort.
It's common that we don't really know if a theoretical fix is actually affecting GSdx or not. Unless profiling says we're loosing speed here this is a welcome fix.
My commit replaced undefined behavior by the expected deterministic behavior.
Undefined is really undefined, it could work on some computers, it could crash, it could depends on the current weather. It could even work but not as expected, in this (unlikely) case my fix would introduce a bug (but a deterministic one, ie a bug that can be analyzed&corrected).
Automatic tools like the one you used here are awesome. Do tell if you get to fix the bug you mentioned earlier :)
it would be handy running that on pcsx2 as well, to make sure we haven't made any sillies there, then again we rarely use memcpy like that ;p
Rama, you mean the bug when toggling between renderer, right?
Unfortunately the situation is not perfect. PCSX2 is very unfriendly with any useful tool :p Long story short:
1/ I got a strange segmentation fault with it in the middle of the recompiler (function recRecompile). It could be related to the way we manage the (virtual) memory. I know more recent version support user sigsegv handler. Unfortunately it is only integrated to llvm/clang compiler (which is not capable to compile PCSX2....) not yet gcc.
2/ the tool only support stack aligned on 8 bytes. No opt gcc build sometimes uses a 4 bytes aligned stack, WTF ! It really doesn't help me for the previous issue ;)
There might be some alignment options in the code specifically made for Linux. Maybe you can find what you need for the 2nd problem there. Look for Linux #ifdef's.
Ok, need to check it.
Anyway, I have found the root cause of the segmentation fault. The tool uses a shadow memory that store the state of the memory pool. Shadow memory are computed with this formulae s = (m >> 3) = 0x20000000. That mean 0x20000000 to 0x3fffffff are not usable by the application.
PCSX2 normally mmap (HostMemoryMap) 0x20000000 to 0x3fffffff for the various component (EE,VU,ROM...).
The memory was already allocated so os/gcc? move those blocks into another range (for example eeMem = 0xe0d7c000). However "negative" address are considered invalid by PCSX2 so I got a null instead of the content of the data.
I think I will add a 0x20000000 offset on the various HostMemoryMap address to test PCSX2 but I'm afraid of the impact.
Found other bad memory stuff. Here an example of the report generated by the tool. It is even better because you can set a break point on the tool report error, so you can see inside the debugger the wrong value in the code.
Here: we try to access sio_buffer[-1] in pcsx2/HwWrite.cpp:234
INFO: AddressSanitizer ignores mlock/mlockall/munlock/munlockall
==15188== ERROR: AddressSanitizer: global-buffer-overflow on address 0x08abb29f at pc 0x80fa490 bp 0xe1f7bc68 sp 0xe1f7bc5c
READ of size 1 at 0x08abb29f thread T4 (EE Core)
#0 0x80fa48f in void _hwWrite8<15u>(unsigned int, unsigned char) pcsx2/HwWrite.cpp:234
#1 0x500022f5 in
0x08abb29f is located 62 bytes to the right of global variable '__ioinit (pcsx2/HwWrite.cpp)' (0x8abb260) of size 1
'__ioinit (pcsx2/HwWrite.cpp)' is ascii string ''
Shadow bytes around the buggy address:
0x21157600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21157610: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 01 f9 f9 f9
0x21157620: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
0x21157630: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
0x21157640: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
=>0x21157650: f9 f9 f9[f9]00 00 00 00 00 00 00 00 00 00 00 00
0x21157660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21157670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21157680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x21157690: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x211576a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
Thread T4 (EE Core) created by T1 (SysExecutor) here:
#0 0xf60e7130 in __interceptor_pthread_create _asan_rtl_
#1 0x877f688 in Threading::pxThread::Start() common/src/Utilities/ThreadTools.cpp:261
#2 0x858a2f1 in SysThreadBase::Start() pcsx2/System/SysThreadBase.cpp:38
#3 0x858b1e5 in SysThreadBase::Resume() pcsx2/System/SysThreadBase.cpp:184
#4 0x83d2fe3 in AppCoreThread::Resume() pcsx2/gui/AppCoreThread.cpp:156
#5 0x8473053 in SysExecEvent::_DoInvokeEvent() pcsx2/gui/ExecutorThread.cpp:122
#6 0x8475f1a in pxEvtQueue::ProcessEvents(std::list<SysExecEvent*, std::allocator<SysExecEvent*> >&, bool) pcsx2/gui/ExecutorThread.cpp:218
#7 0x84768cb in pxEvtQueue::ProcessPendingEvents() pcsx2/gui/ExecutorThread.cpp:248
#8 0x877e7dd in Threading::pxThread::_try_virtual_invoke(void (Threading::pxThread::*)()) common/src/Utilities/ThreadTools.cpp:545 (discriminator 3)
#9 0x8780b42 in Threading::pxThread::_internal_execute() common/src/Utilities/ThreadTools.cpp:644
#10 0x87810d6 in Threading::pxThread::_internal_callback(void*) common/src/Utilities/ThreadTools.cpp:684
#11 0xf60f7946 in __asan::AsanThread::ThreadStart() _asan_rtl_
#12 0xf4f2eecd in clone /build/eglibc-A3YCC4/eglibc-2.17/misc/../sysdeps/unix/sysv/linux/i386/clone.S:131
Thread T1 (SysExecutor) created by T0 here:
#0 0xf60e7130 in __interceptor_pthread_create _asan_rtl_
#1 0x877f688 in Threading::pxThread::Start() common/src/Utilities/ThreadTools.cpp:261
#2 0x83fa202 in Pcsx2App::OnInit() pcsx2/gui/AppInit.cpp:448
#3 0xf6010b27 in wxEntry(int&, wchar_t**) ??:?
#4 0xf4e6e584 in __libc_start_main /build/eglibc-A3YCC4/eglibc-2.17/csu/libc-start.c:260
==15188== ABORTING
That's very helpful indeed. Now gotta find how it got there :p
See next commit ;) Improvements are welcomes.
However bad luck the virtual function abort is still here and it isn't a memory corruption (at least not one comming from PCSX2/GSdx). There is a thread sanitizer tool but it only work with 64 bits (not enough virtual memory otherwise)!

Revision 5727

spu2x: array out of bond (-1)
Performance note, it might be faster to replace the MODULO with an AND. Not sure
on the impact
for the new time stretcher algo.
GSdx: fixed use-after-free (linux)
* add a define to support address sanitizer (both rely on 0x20000000-0x3fffffff
memory ranges..)
* sio_buffer out of bond (-1). Maybe we can move the flush in the 2 if previous
branch. It would
avoid the extra test.
* wxGetEnv (linux) generates double free (maybe not thread safe). Cache the
result so it doesn't crash
anymore when switching renderer
Comment/Review/Improvement are welcome :)
ill correct you now cos i keep seeing you do it, thought it was a typo before :P
Its "out of bounds" not "out of bond", it doesn't run out of 007 xD
Lol ref :D
Okay the timestretcher thing is very nice. It might explain the rare cases when it totally bugs out :)
> it doesn't run out of 007 xD
This one might :p
not a typo but a neuron out of bounds access :p Thanks.
On the virtual access bug. I don't understand what going on.
Strangely when I print the s_gs pointer. GDB tell me that it got a GSstate object instead of a GSRenderSW/OGL object. It is the same for s_gs->m_pGSsetTitle_Crit, I got GSLock instead of GSCritSec. Maybe the vtable pointer are wrong but don't know why.
Eh regarding % vs &, if the value is clearly a power of 2, the compiler should be smart enough to do it for you, otherwise, it may be best ot leave the %. It may be interesting to get the assembler listing and see if it does.
yep. Looking the code I mix MAX_STRETCH_AVERAGE_LEN and STRETCH_AVERAGE_LEN... The module is on STRETCH_AVERAGE_LEN not MAX_STRETCH_AVERAGE_LEN. Increasing the value will change the filter, so it probably not a good solution.
Don't know if the loop was any impact on speed.
Why not keep the intermediate sum value (before the division by STRETCH_AVERAGE_LEN). And just do somethings like that
# remove the oldest value (not sure on the index)
sum_intermediate -= avg_fullness[nextAvgPos]
# add the new value
sum_intermediate += val
I'll need to dive back into the code (iirc it's mine). There shouldn't be any trickery though, at most somewhat unreadable ;)
@giga, an interesting post of an interested guy :p
So nextAvgPos=(nextAvgPos+1)%STRETCH_AVERAGE_LEN;
would be better replaced by nextAvgPos = (nextAvgPos++) >= STRETCH_AVERAGE_LEN : 0;
> Why not keep the intermediate sum value (before the division by STRETCH_AVERAGE_LEN). And just do somethings like that .. [O(1) running average example]
As I wrote at the comment, running average can be done in O(1), but for the sake of simplicity I didn't implement that.
IIRC, the main reason that I kept it simple is that if NEWSTRETCHER_USE_DYNAMIC_TUNING is enabled, then STRETCH_AVERAGE_LEN changes in real time, and while it's not impossible to still maintain the running average in O(1), it makes it more error prone.
NEWSTRETCHER_USE_DYNAMIC_TUNING is not enabled and is commented out and so STRETCH_AVERAGE_LEN is fixed now, but it's required if the sound system behaves differently on different systems. Currently that's not the case, but we might still need it at some point.
Also, while there's indeed some gain to be had from such optimizations, this it not hot, and as such, I usually prefer to keep the unoptimized version, unless it becomes clear that optimizing it would have some measurable speedup, which I think isn't the case here.
But I might have gotten it all wrong, and maybe calculating this average in O(1) instead of in O(N) will speedup PCSX2 by 30%, so if that's the case, please, make it O(1) ;)
Also, thanks for the fix there. This is a nasty bug, and while we only read from that location, it still messes (maybe even a lot) with the running average. Makes me wonder how this code even works..
I guess the answer is that the array[-1] value is only calculated as part of the average once in 100 iteration (when it's the first item), and maybe luckily it happens to not bias the result too much.
Anyway, I actually expect this change to improve the behavior of the stretcher :)
Thanks for the info. Yep code is probably not hot. I was trying to understand all those modulos.
I would say that we get a bad value every STRETCH_AVERAGE_LEN. However the value get a weight of 1/STRETCH_AVERAGE_LEN.
If I'm correct those 2 codes are equivalents? We get STRETCH_AVERAGE_LEN consecutive integer that are between 0 and STRETCH_AVERAGE_LEN (because of the modulo). That mean [0:STRETCH_AVERAGE_LEN[
for(int c=0; c<STRETCH_AVERAGE_LEN; c++)
If you get a dynamic STRETCH_AVERAGE_LEN, you will get issue when you reduce STRETCH_AVERAGE_LEN. Let's take an example
STRETCH_AVERAGE_LEN 5, add the value 4. With this buffer
#(1 2 3 4 5)
Update the average length, nextposition was already computed with previous STRETCH_AVERAGE_LEN.
STRETCH_AVERAGE_LEN 2, add the value 7.
#(1 2 3 4 7)
We expect to do the average on (4 7). Instead we will do the average on (1 2).
You are correct, these two examples are equivalent, but only because of another bug:
should actually be:
And if we used the "fixed" code, then the examples would not be equivalent.
So the system was supposed to fill a cyclic buffer of size MAX_STRETCH_AVERAGE_LEN, and when averaging, take the last STRETCH_AVERAGE_LEN inserted items (which is usually smaller than the MAX size). So it starts with the last item (nextAvgPos-1) and then go backwards STRETCH_AVERAGE_LEN items.
So it was supposed to keep a correct running average even if STRETCH_AVERAGE_LEN changes in real time. But this doesn't happen right now because NEWSTRETCHER_USE_DYNAMIC_TUNING is not enabled, so the bug doesn't actually manifest.
Also, it's very possible that this bug made dynamic tuning much less efficient, which could have been the reason I decided to not enable it by default for now.
Maybe if it actually worked correctly (without this bug) then we could keep dynamic tuning enabled without harming the rest of the algorithm.
Need to reread carefully the code, but that mean all modulo must be MAX_STRETCH_AVERAGE_LEN instead of STRETCH_AVERAGE_LEN (and we need to add also MAX_STRETCH_AVERAGE_LEN for the negative case)?
Possibly, as you said, need to reread carefully. Luckily, it's only few lines of code with a pretty clear function: provide an average of the last N inserted items, where N might change in real time between 1 and MAX.
So at the worse case just rewrite. There shouldn't be any tricks to it.
I'd say I managed to pack a record breaking number of bugs into very few lines of code, but unfortunately, I actually seen much worse... (but at least not mine...).
Ok. I updated the modulo parameter. I let you test the NEWSTRETCHER_USE_DYNAMIC_TUNING :)

Revision 5728

spu2x: correct the modulo parameter of the Timestretcher. Use a size of 128 so
the compiler can optimize the code a bit.
Just noting that it has no functional effect. The neutral review is because I wanted to push some code and now I can't. Meh.
> I wanted to push some code and now I can't. Meh.
:p Sorry.
Was just kidding with the neutral. But it still had no effect and still requires me few seconds of work to decide how to overwrite your changes which code I already have. :)
The stretcher works well with 80ms latency, just as it did for me before.
I wonder if those printf realtime stats are still in there? :p
The stats are there, and you'll see them when enabling overrun messages at spu2x debug ui. I have a modification to the stretcher which, on my system, can sustain 30ms without dropping from 1:1 quite nicely, and seems fully reliable at 50ms, even while going from 300fps to 10fps (turbo -> slowmo) without getting stuck at infinite underrun loops.

Revision 5729

SPU2-X: Stretcher: Better behavior - can now maintain stable 1:1 with 30ms
latency on my system if the game is light enough, and much better resilience to
infinite underruns (e.g. when going from turbo to 60fps, or from turbo to 10fps,
even with under 50ms latency): 1. Improved averaging on init (and after reset)
2. Added reset after few underruns. 3. automatically slightly increase target
latency when pcsx2 runs slow. 4. un-staled dynamic tuning (still disabled by
default, but now can be enabled and works reasonably well). 5. Lowered minimum
latency from 50ms to 30ms.
Next commit will include some cleanups, and I'll probably also remove the
dynamic-tunning and related support code (not a lot of code though, but.. it's
currently unused). I'm also considering completely removing the old stretcher
from the code, such that both dynamic-tunning and the old stretcher will only
live in SVN history.
Meanwhile, you can test this patch and report back here if you notice a
difference. BTW, on my system I use the portaudio output since IIRC it offers
the lowest latency.
As before, to display stretcher messages at the console, enable underrun/overrun
messages at the SPU2X debug UI (which is also available on normal builds).
Question @avihal, this stretcher function only works in conjunction with the portaudio output?
Those numbers are impressive. Is it actually working *that* well?
If so (I will test it!) then congrats :)
@colepcsx2, no, it works with all of them, I was just stating the output device I got these numbers with.
Also, this patch shouldn't regress stability (as can sometimes happen when the algorithm becomes more agile). The main gains are due to resets on underruns, and slightly increased target latency when the speed drops down.
@avihal, Thanks for the quick reply.
I have now tested it with Star Trek Shattered Universe, which runs properly on PCSX2 only in software mode, in the past there were many dropouts but are now gone.
nice work avihal :D

Revision 5730

Silence a mVU bad opcode error log that would spam in Shadow Hearts 1 battles
and likely in Dawn of Mana 2nd level, too.
Also renamed a widescreen string and added a compiler warning fix.
Intresting! I wonder what bit made it start doing that.. I'd be more curious to know why it thinks it's a bad op rather than just silencing it
We had a regular mVU warning log message before r5586 that only came up once.
After r5586 that changed to a spamming "microVU1 Warning: Exiting... Block contains an illegal opcode."
I didn't want to investigate further because it appears to be just a different handling of warnings and well, because mVU ;)
oh it came up before to? nevermind then ;p though im still somewhat curious to what the bad op is (or what it thinks it is :P)
Uh actually no. Before I got this once:
microVU1 Warning: Exiting... Block contains an illegal opcode. [1f30]
Now instead I was getting flooded with this:
microVU1: Unknown Micro VU opcode called (8000033c) [1f30]
They look similar but it was not the same log message :P
oh okay so it is a fraudulent error ;p hmm we put some code in place to stop that happening, sudo helped code it lol, weird..
I think it was something along the lines of a forgotten op that doesn't harm anything. It happens in Mana as well and is not affecting anything on the PS2.
It's still illegal, thus mVU at least complaining (once!) :p
Yeah the bios fills the vu memory with nop and move v0, v0 but the wrong way round lol. Not sure why it gets it wrong mind but it doesnt seem to cause any harm.

Revision 5731

spu2x (linux): allow to use sdl as audio backend instead of portaudio
(recommended for pulseaudio user). Close i1413
Thanks to Matt Scheirer for his patch
Nice. How does it work with the stretcher? Specifically, when you enable stretcher messages (enable overrun messages at SPU2X debug UI), please post few log lines at 100% speed, and also in slower/higher speeds. Like this:
buffers: 52 ms ( 87%), tempo: 1.025615, comp: 1.000, iters: 745, (N-IPS:750 -> avg:50, minokc:750, div:100)
Also please try different latency values and let me know which what's the minimum with which there are few/no breakouts.
>> Also please try different latency values and let me know which what's the minimum with which there are few/no breakouts.
Could you explain it a bit more?
Full speed
Latency I got 300
Sequence length 30
Seek window size 20
Overlap 10
* SPU2 > Underrun compensation (9 packets buffered)
m�buffers: 526 ms (176%), tempo: 10.000000, comp: 0.152, iters: 748, (N-IPS:750 -> avg:50, minokc:50, div:100)
[0muffers: 405 ms (135%), tempo: 0.784486, comp: 1.517, iters: 642, (N-IPS:750 -> avg:50, minokc:50, div:100)
* SPU2-X: Core 0 AutoDMAControl set to 0 (at cycle 128376)
* SPU2-X: Core 1 AutoDMAControl set to 0 (at cycle 128376)
* SPU2-X: Play Mode Set to PCM Clone (1).
* SPU2-X: ATTR bit 0 set to 1
======> stretch: None (1:1)
~~~~~~> stretch: Dynamic
buffers: 262 ms ( 88%), tempo: 0.816876, comp: 1.067, iters: 750, (N-IPS:750 -> avg:50, minokc:50, div:100)
0m�[======> stretch: None (1:1)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
~~~~~~> stretch: Dynamic
buffers: 300 ms (100%), tempo: 1.180098, comp: 0.841, iters: 759, (N-IPS:750 -> avg:50, minokc:50, div:100)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
======> stretch: None (1:1)
buffers: 297 ms ( 99%), tempo: 1.000000, comp: 1.000, iters: 750, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 273 ms ( 91%), tempo: 1.000000, comp: 1.000, iters: 753, (N-IPS:750 -> avg:50, minokc:50, div:100)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
buffers: 290 ms ( 97%), tempo: 1.000000, comp: 1.000, iters: 752, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 309 ms (103%), tempo: 1.000000, comp: 1.000, iters: 752, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 306 ms (102%), tempo: 1.000000, comp: 1.000, iters: 751, (N-IPS:750 -> avg:50, minokc:50, div:100)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
* SPU2-X: Play Mode Set to Normal (0).
* SPU2-X: Core 0 AutoDMAControl set to 0 (at cycle 445914)
* SPU2-X: Core 1 AutoDMAControl set to 0 (at cycle 445914)
* SPU2-X: ATTR bit 0 set to 0
* SPU2-X: Play Mode Set to PCM Clone (1).
* SPU2-X: ATTR bit 0 set to 1
* SPU2-X: Core 0 AutoDMAControl set to 1 (at cycle 455171)
By the way do I need to get your previous patch?
Slow part with 100 ms latency
7m * SPU2 > Underrun compensation (3 packets buffered)
* SPU2 > Underrun compensation (3 packets buffered)
* SPU2: Pitch setting too big: 0x5761
* SPU2: Pitch setting too big: 0x5761
* SPU2: Pitch setting too big: 0x5761
* SPU2 > Underrun compensation (3 packets buffered)
* SPU2 > Underrun compensation (3 packets buffered)
buffers: 113 ms (113%), tempo: 0.267911, comp: 2.310, iters: 60, (N-IPS:750 -> avg:50, minokc:50, div:100)
* SPU2 > Underrun compensation (3 packets buffered)
* SPU2 > Underrun compensation (3 packets buffered)
* SPU2 > Underrun compensation (3 packets buffered)
* SPU2 > Underrun compensation (3 packets buffered)
buffers: 25 ms ( 25%), tempo: 0.158297, comp: 3.710, iters: 178, (N-IPS:750 -> avg:50, minokc:50, div:100)
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
* SPU2: Pitch setting too big: 0x5761
buffers: 124 ms (124%), tempo: 0.274211, comp: 4.030, iters: 185, (N-IPS:750 -> avg:50, minokc:50, div:100)
* SPU2 > Underrun compensation (3 packets buffered)
buffers: 50 ms ( 51%), tempo: 0.202803, comp: 4.393, iters: 154, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 44 ms ( 44%), tempo: 0.235730, comp: 4.390, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 37 ms ( 37%), tempo: 0.209203, comp: 4.450, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 50 ms ( 51%), tempo: 0.227913, comp: 4.464, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 44 ms ( 44%), tempo: 0.208156, comp: 4.380, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 56 ms ( 56%), tempo: 0.221794, comp: 4.505, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
buffers: 48 ms ( 48%), tempo: 0.218642, comp: 4.542, iters: 180, (N-IPS:750 -> avg:50, minokc:50, div:100)
> By the way do I need to get your previous patch?
You don't _need_ it, but it improves response especially on slow downs.
> Could you explain it a bit more?
I tried to document the behavior in the big comment before the code. Read it first, and if you have further questions, I'll answer them.
Btw, why "instead of" portautio? is portaudio broken in recent linux distros? how about adding SDL as just another output option instead of SDL replacing portaudio?
Portaudio is still here (actually it is even the default). I wrote 'instead' because you couldn't use both backend in the same time :p
On linux I get 3 possibilities:
1/ portaudio->alsa->pulseaudio->driver
2/ portaudio->alsa->driver
3/ sdl->pulseaudio->driver
It seems there are some bugs in alsa->pulseaudio interface which lead to higher latency (but I need to profile that). Nowadays pulseaudio is nearly mandatory.
Well, thanks for integrating this then.
I'll admit I don't know why but it appears SDL is generally
unliked. If it fixes problems people have then it's okay though :p
I have nothing against sdl. Its probably slow and limited, but what it does, it does well.
This fixes a bad sound clicking issue in persona 4, btw. So great job.
sdl used to be a pain in the arse, but the sdl 2.0 cleanup has come a long way, its even used in steam now.
I'm not sure steam is the reference. Anyway I personally like SDL, API is easy. I don't think SDL is slow, it just a thin layer around native technology anyway. However PCSX2 is a monstrous beast which always lead to a corner case :p
Anyway SDL2 transition will be painful because of its inter-dependency with wxwidget in some distributions.

Revision 5732

gsdx ogl: in case of EGL_BAD_MATCH try to create the context with different
option (hope to fix intel mesa)
cmake: add sdl as a dependency requirement of spu2x
Note: SDL-spu2x is only for linux

Revision 5733

Compilation fix for SPU2-X non-release targets on VS2010.

Revision 5734

R5900: Developer log for possibly (but not necessarily, the asm has to be
checked manually) incorrect recompilation of COP2 code. The patch is
disgusting, please don't look.
Attractive ;p I'm presuming this is working towards sorting out the Ace Combat games, so I approve of this mess :)
Thanks :)
Well we'll have to see about ace combat. Now that it's getting pointed out for me I see that it's worse than I thought. Some parts of it seem intentional, some accidental and I'm cursing them for trying to code for COP2 by hand.

Revision 5735

R5900: I forgot a bunch of stuff in the last commit.

Revision 5736

We can reject sequences with 4 intervening cop2 operations because the one cycle
stall when coissuing with a cop2 move brings it up to 5 cycles. Not sure about
4 cop2 moves, I think that's okay but I'm not confident.

Revision 5737

Database: First patch for ace combat 5 (US). I have doubts about some other
blocks, such as the code leading up the CFC2 at 1D0D98 and another at 1CF7C0 but
this code clearly needs a patch.
Also 3 patches for ace combat 4 (US). As I'm not aware of any physics problems
I'm a bit confused about what this might fixed but the code is executed so it
should fix something.
Holy cow !!)
Does it fixes Ace Combat 5 collision bug ?
Thats the idea I believe!
It's likely that many of the remaining core issues are similar to this one.
Analyzing the games with the new debug logs should give us new clues.
Great job sudo :)
AC5 ground crash physics confirmed working btw :)
it's good finally see updates that arent related to linux, good work sudonim.
Um well I'm not inclined to believe that there are many issues like this one, but the point of the log is to find them (and lots of false positives that'll annoy me) if there are.
With this patch active and using software rendering for the mipmapping textures, the game should be fully playable.
your cpu is far too weak for sw on many games + its limited to sse2 only cant even use ssse3 which has a speedup, or sse4.1 which is another speedup then avx which is another(they are small but add up)..even overclocked it wont change 35fps into 60.
my previous cpu i7 920(sse4.1) @ 4ghz has 8 threads & runs circles around a phenom II x4 in everything especially emulation, my current i7 3770k(avx) sees over 10fps increase on most games with sw mode, most actually i think every single one i have except one is constantly maxed at 60fps in sw mode everywhere in game now.
Running on Core i7 2600, 8GB RAM and GeForce 260 Ti, software rendering with 6 threads (6 somehow faster than 4) = FULLSPEED and FULLY PLAYABLE !!)))
Thank you guys ! I waited for this moment more than 4 years and now this AC5 finally playable ! (^_^)
- -
i have PAL version (and the fix is not working here)
could i help somehow?
really thanks for your work btw
Yes, I should be able to make a patch for any version with an emulog.txt
from a current pcsx2 devel (release will not work) build.
that means the latest one from svn build bot right?
(i dont have pal i have ntsc & yet to try it but its said ntsc is fixed)
I don't think the build bot builds the devel target, so no. I might be
corrected on this though.
I dont think it does. In fact I assumed it doesnt as I went through the effort of building it to get the console logs :p
unfortunately i don't have access to a linux system right now
however, i managed to get this log from the latest SVN with ALL the dev log option enabled
is this enough? or should i start to download arch to compile the dev build?
That doesn't contain the debug output we need. You need to use a version of PCSX2 compiled yourself with the "devel" profile. SVN builds do not contain the information required.
Also all you will need is Dev/Verbose.
i was able to get a dev build
i uploaded the emulog here
if you feel the file is too big, don't hesitate to tell me which checkboxes are necessary and which not
hold crap thats huge!!
yeh you don't need to tick any checkboxes, it just appears in the console window
just run the game normally with the dev build, no logging options (just the dev/verbose ticked on the console window) until youve fired off a few missiles and things and tried to crash in to the ground, then upload that emulog.
here you are!
it was literally submerged of
"RegisterIntrHandler: intr INT_RTC4, handler 89a8"
and i had to merge and cut 5 log to get it
I passed the log over, but we need a new one. Can you please build a newer version of at least r5743
Thanks :)
Sorry about asking for a new log. While I could write a patch based on
that log and it'd probably be fine, I'd rather be sure that the patch is
Can someone do the same to Ace Combat Zero? They share the same engine and issues.
as soon as i rebuild my dev environment (i deleted it yesterday -.-) i will compile a new devel version
and after the emulog for the AC5 pal version, i could provide the belkan war one too
estimated ETA for the first thing 2-3 hours
that's all for today!
i think tomorrow i could have the time to test belkan war ;)
Okay, patched that. Also for the record I'm now sure that only that one
block needed patching, I'm more used to reading the asm for this now.
well, i tested only the first part of the arcade mode
i think i could provide other log too in the following weeks
however, logging could be much easier without that persistent and irritant "RegisterIntrHandler: intr INT_RTC4, handler 89a8" error
Eh, it doesn't spam half as much as some messages do.
ok sorry for that
where could i look to extend the logging buffer?
belkan war log here btw
Buffer? We do write the log to disk as emulog.txt, there's no need to rely
on the portion that's buffered in memory.
...my fault sorry
by the way - i could be wrong- but could be possible that NPC aircraft still pass through the terrain without problems?
i was playing here and there, and i think that 2-3 times i saw an enemy glitching in a hill
could be a perspective illusion too
if i can do something more, tell me
If i'm not mistaken, they do that in the ps2 too.
ahah, lol then

Revision 5738

Database: Patch for Run Like Hell (EUR), fixes "spasms" I'm told? I only saw the
code, I guess if you have the game you know what was wrong with it.
Really old game but maybe it has some fans :)
Played this one many years ago. Not bad game.
Unfortunately, it didn't fix the problem. If you want, I can upload a video of the problem onto my youtube channel for you to see what is happening.
It fixes it for me so you need to check if the patch is even getting applied on your end.
If it is then maybe you mean a different problem.
The movement physics were really obviously broken before this patch.
Well, two things.
1. When I download the SVN and launch it, I notice it doesn't say, 5738, it says 5736. Don't know if that's the problem or not.
2. I also notice in the description that he says it's for the (EUR) version. Could the US version not be affected?
1. Not a problem at all, yhat was the last core program update.
2. It will only affect the version the patch was made for, a log from the europd version will be required to patch that one.
sorry if this sounds stupid, cause I'm not to familiar with a lot of the stuff that goes on with this emulator. So what you're saying is I need to get a European release of this game? Or do I just need to hold out for a patch that fixes the US version?
Yes, I have the same problem with the US version of RLH - Run Like Hell.
You need to either buy the version that has been patched, wait for a patch for your region, or help us make a patch by getting somebody to make a dev build for you (svn build wont do) and run the game, once you've played ingame a bit, upload your emulog.txt to pastebin or somewhere.
@refraction, Can you set a dev build in the next svn?
Yeah, I'd be willing to help with that if I can get my hands on a dev build.
@refraction, I'm New to this but is this Dev log sufficient to fix NTSC ver. http://pastebin.com/VSzErGsJ if not pls tell me how to make it so. Peace Out.

Revision 5739

GameDB: Ghost in the Shell USA version patch. After sudo added the new COP2
logging stuff, i pondered if this might be a culprit and it was. You can now "X"
on the first level door and go through.
All "macflag" reads are patched to ensure there's no other issues. I might have
a go at the EU one soon (unless somebody can get me a dev build log of it all
the way up to the first gate)
You could have used pastebin instead of raping this commit comments -_-
not at all useful, your log doesn't seem to contain anything i need. You must be using an SVN build rather than a devel build (you have to build it yourself).
It's ok i'm sure my brother in law has it.
I expect there'll be a couple more games that we can fix now :)
Well i guess any games which exhibit invisible walls, things that dont trigger, falling through objects (possible, could be normal VU's) or general crazyness could be COP2 problems.

Revision 5740

GameDB: COP2 Patch for European version of Ghost in a Shell for the door problem

Revision 5741

GameDB updates from pgert.

Revision 5742

EE: made the developer log for COP2 a bit more verbose and useful.

Revision 5743

EE: I'm forgetful, this was meant to be part of the log change.

Revision 5744

Database: COP2 patch for The Mark of Kri (NTSC-U). Not sure what defect it
fixes, but this patch should be necessary.
Do you think the weird issue with the character jumping on top of the map in Rogue Galaxy might be related to all this?
You can test this by changing the round and clamp modes. If the game reacts to that, then it's rather unlikely that flag issues (this) are the problem.

Revision 5745

VIF: Fix for Warship Gunner 2 Issue 1079 . On VU executes immediately followed
by an unpack we will execute it immediately. I didn't look too deeply in to this
but the game doesn't like the delays. Baldurs Gate still happy though.
Software mode only for Baldurs Gate I'm assuming?
yes. This was an internal change, gsdx is still faulty on baldurs gate.
I agree. It is fixed.
it's good to see someone FINALLY taking care of the old issues, i hope it keeps like this. :)
It takes time but we get around to them ;p
nice one ref :)
what ref means to say is,
he can't afford his wow subscription atm, so he had nothing better to do :D

Revision 5746

Database: COP2 patch for Ace Combat: Squadron Leader (PAL-E).

Revision 5747

GameDB: COP2 patch for Ace Combat - The Belkan War (PAL-E)
Can anyone compile a devel version for windows? I can provide Belkan War NTSC logs
i already did that
check http://forums.pcsx2.net/Thread-Official-Comment-Thread-Pcsx2-svn-snapshots-and-user-compiled-svn-revs?pid=323518#pid323518
Awesome, i'll get some logs in 30 minutes
Logs here:

Revision 5748

GameDB: COP2 patch for Ace Combat Zero - The Belkan War (NTSC-U)

Revision 5749

microVU: Fix for Conditional branches on E-Bit. One less bug on DT Racers with
...whew. Sorry.
DT Racer is just my favorite PS2 game. Of all time.

Revision 5750

Left some logging in, nothing to see here.

Revision 5751

VIF: Fix up handling of indeterminate data with different alignment. Not sure if
this will affect anything, but test results now match the PS2.
checks author
author = refractioin
wonders what broke.
Nothing yet that I tested here, but it makes True Crime LA work a tiny bit better. Also it makes some hardware tests we did correct now :)
The True Crime thing might have been to do with r5749 more than this tbh.

Revision 5752

gsdx ogl: Flush various pending work
* try to use more subroutine on VS&PS, unfortunately hit a driver crash!
* Call Attach/DetachContext through GSDevice so I can unmap currently mapped
* Implement glsl part of GL_ARB_bindless texture, again hit another driver
* various fix of GL_ARB_buffer_storage. Basic benchmark show only improvement on
'cold' case, I guess it will improve smoothness
* try to fix GL_clear_texture, no success so far. It seem the extension is
limited to basic texture (aka no depth/stencil)

Revision 5753

GameDB: COP2 patch for SPS issues on Siren 2 (J) SCPS-15106.
Nice easy one to fix. Will need logs from recent SVN ( r5743 or higher) dev
builds, not SVN builds in order to fix other versions.
Give me a couple of hours, and I can get you a log from the US version.
Excellent thanks :)
US version of Siren 2 does not exist...
Thats a fair point. It was only released in japan, europe and australia
Whelp. I misread then! I thought it was Siren 1. Sorry bout that.
Well siren 1 is probably very similar issues, so it wouldn't hurt to check :)
Forbidden Siren 2 PAL (SCES-53851): http://vpaste.net/bRId4
PS: I do not see any COP2 warnings in Siren 1 USA (SCUS-97355)
PS: You need to update Windows detection code, Windows 8.1 lies about it version ... please read Remarks section here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724833%28v=vs.85%29.aspx
So, I've only got a dev build for 5736. If I copy the Dev exe and .dll over to a new svn, would that work?
Nope, r5743 or newer. Here: http://www.virusdev.zz.mu/virusdev/PS2/5754dev_vs2013.7z
Alright, I got a log for Siren. Now I'm not 100% sure that I did that right, so for the logging, I just checked everything except SIF(EE <-> IOP). Anyways, if you want me to log it a specific way, just let me know what to check.
By the way, the game only ran at about 5 FPS while logging, but as soon as I went into the inventory screen, it was 60 FPS.
I was tested this game too, see my second comment. No COP2 in log file for this game, also it was running fine at almost constant 60FPS.
Siren 1 doesn't have any COP problems as far as i know. If there's nothing wrong with it, there's no point looking for problems ;p

Revision 5754

VS2012: Force it not to use SSE optimizations to avoid FPU using SSE instead of
x87 - Consistancy and stability change.
I should have mentioned this only affects the interpreter side of things as the recompiler we tell it what to use.
However it is possible elsewhere used SSE instead of FPU so i guess it would help there.
what does this resolve?
Nothing totally in your face, but running SSE on interpreted code when recompilers are running can cause crashes.

Revision 5755

GameDB: Patch for Forbidden Siren 2 Europe
Thanks !

Revision 5756

* new option SDL2_API
* drop GLSL_SHADER_DIR. Useless, shaders are embedded in .h file
* use some hardening flags (for the moment only basic one)
* port the code to SDL2 (Note only SDL1 is supported for the moment)
* improve detection of button vs axis (long-standing issue)
* avoid potential overflow on mouse mouvement detection
I see you're planning to use the SDL Game controller API.
It's really just a wrapped around the joystick API, it expects an xbox 360 style controller and doesn't have the concept of a "hat"
Also just wondering, are you going to make use of the SDL_JOYDEVICEADDED/SDL_JOYDEVICEREMOVED (and SDL_CONTROLLERDEVICE variants) events that were added in SDL2?
Actually I rewrite the code 3 times in order to find a solution of button/axis detection. Game controller is only a left over. As far as I understand game controller map button/axis to logical name. In the application you can use directly the logical name. The main advantage is that you can provide a default configuration but few controller are supported (1/3 on my side). So maybe on the future, let's wait future release of sdl.
So far, onepad doesn't use any event. We got a wx event loop for the gui, it eats most events. On the past I extended the plugin api to transfer keyboard/mouse event from PCSX2 to the pad plugin. Besides, I don't think it is useful to support hotplug of controller.
Hey, bug in /trunk/plugins/spu2-x/src/CMakeLists.txt
1 line-by-line comment
line 119:
119: endif()
The 'add_definitions' are inverted. if SDL2_API, then use "SPU2X_SDL2". Otherwise, compilation will fail without 'sdl2' package when '-DSDL2_API' was not specified.
ps.: Just noticed that it was also reported in here https://code.google.com/p/pcsx2/issues/detail?id=1448
Thanks :p

Revision 5757

GameDB: Patch for Run Like Hell (US), same as EUR.
Running Like Hell and no problems 10x to sudonim1 ! Nice work in there ;)
Quick Question: Is COP problem looking like this
Possible old value used in COP2 code
3C0240A0 00267854: lui v0, 0x40A0
3C043F80 00267858: lui a0, 0x3F80
AFA20074 0026785C: sw v0, 0x0074(sp)
27A30060 00267860: addiu v1, sp, 0x0060
AFA00070 00267864: sw zero, 0x0070(sp)
27A20070 00267868: addiu v0, sp, 0x0070
AFA00078 0026786C: sw zero, 0x0078(sp)
AFA4007C 00267870: sw a0, 0x007C(sp)
DA2200F0 00267874: lqc2 vf02, 0x00F0(s1)
D8430000 00267878: lqc2 vf03, 0x0000(v0)
*4BC310A8 0026787C: vadd.xyz vf02, vf02, vf03
F8620000 00267880: sqc2 vf02, 0x0000(v1)
27A60080 00267884: addiu a2, sp, 0x0080
AFA4008C 00267888: sw a0, 0x008C(sp)
AFA00080 0026788C: sw zero, 0x0080(sp)
AFA00084 00267890: sw zero, 0x0084(sp)
AFA00088 00267894: sw zero, 0x0088(sp)
F8C20000 00267898: sqc2 vf02, 0x0000(a2)
3C020001 0026789C: lui v0, 0x0001
=3444870E 002678A0: ori a0, v0, 0x870E
0C0C5B68 002678A4: jal 0x00316DA0
0000282D 002678A8: daddu a1, zero, zero
If "Yes" i have some game logs with something fammilier afther testing last night ready just in case.
What? That shouldn't even have been logged, that must be a bug in my
logging code.
Run like a dream! Thank you so much sudonim1! I've been wanting to do an LP of this for a long time now, and thanks to you, now I can!

Revision 5758

EE: Whoops! Fairly major oversight in the COP2 flag delay logging code causing
false positives.
Using the r5758 plugin folder for the 5754 dev; The Game TЯAPT still give me COP2 log http://pastebin.com/ULD6fPyq Previously mentioned in r5757 comments.
Have not played the game intensly to tell if it had problems earlier or not.
PS: 7 Tested Games till now give the same COP2 log FYI.
Gungrave NTSC - http://pastebin.com/DPqUpWgZ
Robotech NTSC - http://pastebin.com/TC5PSJn5
Destroy all Humans! 2 NTSC - http://pastebin.com/087nVAyh
Destroy all Humans! - Had cop2 log but my iso is damaged to test further till i make new one.
The Dog Island PAL - http://pastebin.com/1aTgmx8W
Shadow Hearts 2 Covenant NTSC - http://pastebin.com/N8VWEDTq
Virtua Quest NTSC - http://pastebin.com/WgGJvJX4
Dose every flag have to be fixed in the game or one fix make the COP2 problem go away further in the game? Cuz some games have more than one patch applyed in the game as i saw in GameIndex.dbf
Changing your plugins is not going to eliminate the erroneous logs.
Gungrave is fine, robotech is a log because of the bug fixed in this rev,
shadow hearts 2 is fine and virtua quest is another buggy log.
Destroy all humans 2 and the dog island might be problematic but I'm
definitely not modifying code that might be working without known issues in
the games that could plausibly be caused by this.
Each individual "patch" is changing a single instruction. Multiple
instructions need to be changed to make a block of code pcsx2 compatible.
Even without the logging bug fixed in this revision, most logs are false
positives. The bottom line is we're only interested in logs from known
buggy games.
Sorry then, just trying to help by testing but if the log by itself is not 100% accurate then there is no point. If things change or you just need a tester know that I am willing if provided with the propper dev revision to do so.
If the log could be 100% accurate there would be no need to log it, we'd be
able to emulate the behaviour correctly.
Sorry to ask this but the dev revisions are not openly distributed right?
Cuz can't find one on something like Orphis' build bot or serch engine.
If so then they are used only by project participants and the open public can't test, help or else. The question is driven by my inability to test the revision changes in the mentioned games.
PS: If I'm to nosy and outside help is unneeded feel free to tell.
you can download the code yourself and compile a developers build, then you can use the logging.

Revision 5759

Path3 Masking: Fixed up some issues causing Gunfighter 2 not to work. Closes
Issue 1445
Fast Fix. Nice work there!
good to see another old one gone, keep them coming and congrats. ;)

Revision 5760

Always the same isn't it? you always see a blinding cock up you made after you
commit it.
The game is fixed. Your work is appriciated. That's + for PCSX2 Emulation overall in my book ;)
That's true, always the same :D

Revision 5761

cmake: fix sdl switch typo (close #1448)

Revision 5762

Added another version of Crash Bandicoot Wrath of Cortex to the CRC hack list.
Not sure what region it is, possibly japan.
(Did this through the google code file editing so if it's broken i apologise :P
Looks like it did it right, that's quite handy! lol

Revision 5763

Created vs2013 files based on the vs2012 code, and fixed a small incompatibility
between vs2013 and pthreads.
Removed some missing headers from the vs2010 and vs2012 project files that were
causing vs to always claim the projects were out of date.
Also removed some other entries for c/cpp files that were disabled but also
missing (I did not search exhaustively).
I expect a few people thinking "Oh shit, one more project system to manage..."
- -
Braver man than I :p

Revision 5764

Because vs2012==vs11 and vs2013==vs12, which is extremely confusing, I renamed
the project files to use the full year as the name.
Also fixed some project references to the right filenames.
vc11/vc12, it is the compiler version that lags behind.
Commenting while I can, without G+!
Technically, the compiler is at 18.0...

Revision 5765

Missed this file.
Helps :P
Built right away, good job! :)
Ah, one issue came up with vs2010, SSSPSX pad plugin now fails to build with LINK : fatal error LNK1104: cannot open file 'dxguid.lib'.
really? I do not recall changing anything related to that...
Okay, so far it's just me with the linker problem. Anyone else?
thats cos you don't have directx set up properly in vs2013. I bodged it in old skool style in 2012.
Ref: But then GSdx should fail to build as well, I'd think.

Revision 5766

Gif/Path3 Masking: Fixed a bug introduced in r5759 stopping SSX On Tour from

Revision 5767

Region now know n for Crash Bandicoot CRC added in r5762
Using the online editor again? :)
Yep, bloody handy that! :P
Providing I don't cock anything up that is.. :P

Revision 5768

* refresh all strings with latest update
* Update it_IT and sv_SE
+#, fuzzy
+msgid "Enable Widescreen Patches"
should be deleted #, fuzzy or can not display the contents of the translation
Hum that because the strings was updated so the tool mark it as fuzzy. I could safely remove it but so much file... I need to look at sed option ;)
"Enable Widescreen Patches" works fine with sv_SE.
The string was (as I recall) added in PCSX2 1.1.0.xxxx,
so some (if not most) translations consequently doesn't support it.
If you are going to remove the string,
please only do so for unsupportive translations.
I didn't remove the strings. I just mark them as correct.
If "Enable WideScreen Patches" was properly translated so the translation of "Enable Widescreen Patches" is correct.

Revision 5769

i18n: unfuzzy one string (only a case update on the English string)
Translations are such a joy.
Thanks for updating everything here, very much appreciated :)
Hey Greg.
I know it's irrelevant to this commit, but I just played around with override_geometry_shader = 1 with the nvidia 331.20 driver.
Either I didn't force enable it properly, or the bug was on nvidia's side and got fixed, everything appears to be rendering properly.
I also had a quick play around with some of the other overrides too, I enabled buffer_storage, clear_texture, multi_bind, and shader_subroutine.
I didn't notice any visual oddities, but clear_texture really, really kills performance in Wizardry: The Forsaken Lands during certain scenes, like fighting the ninjas on B3, without it, I get ~20 FPS, with it, 2 FPS.
https://dl.dropboxusercontent.com/u/23891252/dump.7z <-- a GS dump of said scene
Anyhoo, Keep up the good work!
Rama your welcome. Fortunately for me it is mostly automatic :)
I will wait more to enable geometry shader. You only test one gpu with one driver version with one OS :p
Clear_texture is not fully implemented anyway. I'm not sure the extension allow to clear either the Depth or the Stencil of a depth_stencil texture. I will give it a look at your dump but drivers are quite young (with various bugs).

Revision 5770

Added a simple scanlines filter (2nd one activated by F7). No tweaking done yet.
It shows how to get scanlines that aren't affected by input resolution or
A good next step would be determining the exact number of dark lines to show :)
great work! pcsx2 still alive a question because the state now slow project thanks greetings :D
Can you restore/add the grainier filter that was replaced?
Yea, can do that :p

Revision 5771

COP2/GameDB: COP2 patch for Syphon Filter - Omega Strain USA

Revision 5772

zzogl: fix compilation issue with mesa10

Revision 5773

fix zzogl-cg too
I just noticed that the plugins do not have revision numbers, could someone check this again?
how did you build the plugin?
I have not compiled myself, I always use the Orphis' build bot svn release.

Revision 5774

SIO: Latest changes from KrossX which solves problems with Metal Gear Solid 3
and Shining Force EXA.
You might need to make a new memory card for those games if you had a problem.
Sounds like it breaks stuff...
Sounds like it. I've reported it to KrossX
Shadow of the Colossus is also broken. Black screen after circle icon rotation at startup.

Revision 5775

Just revert the last commit until the bug is fixed. Prevents people from messing
up their memory cards.

Revision 5776

Minor additions.

Revision 5777

Added a check box and config code for the fxaa shader.
It's not currently hooked up since the shader setup might get replaced in a day
or two.
Eagerly awaits permanent F7 filter toggle :)

Revision 5778

Latest stable wide screen patches.
Many thanks to devina40 and all the community for creating and collecting them!
A lot of work went into these.
I see Futurama here, but not PAL version.
ELF (cdrom0:\SLES_515.07;1) Game CRC = 0xEB25115F, EntryPoint = 0x00100008
(SYSTEM.CNF) Detected PS2 Disc = cdrom0:\SLES_515.07;1
It probably hasn't been ported yet, so it's not available.
Ported? I thought NTSC and PAL versions are usually same with some exceptions.

Revision 5779

This patch came out weird.

Revision 5780

Last patch also had a weird encoding, confusing the googlecode diff display at

Revision 5781

SIO: KrossX new changes for Memcards, seems ok on a test of random 10-15 random
games, please report if any errors appear!
Seems to work for me as well :)
Also tested multitap and PSX memory cards, both looking fine.

Revision 5782

Left this in by accident.

Revision 5783

gsdx linux:
* allow to control the gl dectection from the gui (+1 for the user-friendliness
;) )
* disable geometry shader by default on Intel driver
- -GLLoader.obj : error LNK2001: unresolved external symbol "bool GLLoader::intel_buggy_driver" ([email protected]@@3_NA)
vs2010/vs2012/vs2013 gsdx build failed
Thanks I forget a refresh of my patch. It must work now.

Revision 5784

... forget to refresh my patch ...
oh well with override_geometry_shader=0 not working anyway on Intel HD 4000 but now massive speed up to 300fps blacks scren/White screen testing on BIOS.
ERROR: 0:12: '' : syntax error: incorrect preprocessor directive
ERROR: 0:31: '' : syntax error: incorrect preprocessor directive
ERROR: 1:58: 'VSout' : undeclared identifier
ERROR: 1:58: 'p' : vector field selection out of range
ERROR: 1:58: 'POSITION' : undeclared identifier
ERROR: 1:59: 't' : vector field selection out of range
ERROR: 1:59: 'TEXCOORD0' : undeclared identifier
ERROR: 1:60: 'assign' : cannot convert from 'float' to 'Position 4-component vector of float'
WARNING: 0:132: Only GLSL version > 110 allows postfix "F" or "f" for float
ERROR: 1:223: 'SV_Target0' : undeclared identifier
ERROR: 1:223: 'assign' : cannot convert from '4-component vector of float' to 'float'
ERROR: 1:66: 'TextureSampler' : undeclared identifier
ERROR: 1:66: 'PSin' : undeclared identifier
ERROR: 1:66: 't' : vector field selection out of range
ERROR: 1:66: 'texture' : no matching overloaded function found (using implicit conversion)
That annoying, you have mesa 10?
Can you try this small patch? It forces intel driver to fallback to GLSL 310 instead of 330!
--- GLLoader.cpp (revision 5784)
+++ GLLoader.cpp (working copy)
@@ -205,7 +205,7 @@
found_geometry_shader = !!theApp.GetConfig("override_geometry_shader", -1);
fprintf(stderr, "Override geometry shaders detection\n");
- if ( (major_gl == 3) && minor_gl < 3) {
+ if ( ((major_gl == 3) && (minor_gl < 3)) || intel_buggy_driver) {
// Opensource driver spotted
found_only_gl30 = true;
By the way, if you still got some error. Be sure debug_ogl_shader is 1. And repost anythings around the error message.
Hum I think I got one big error that could explain others. Let's me fix it first.
Could you test r5785 please.
I'm using Windows with last driver version (latest public for Windows) Maybe outdate compared with mesa on Linux i think .
Later i try on Linux and Windows with these changes.
Ok. Can you still give a try on next version.
Note forget the previous patches.

Revision 5785

gsdx ogl: Intel driver keep the GL_ES macro undefined...

Revision 5786

Install Script: Add Widescreen patches to installer

Revision 5787

Install Script: additional changes.

Revision 5788

The zlib project is not using mfc, and vs2013 didn't like that it was MFC and
non-unicode, so I removed the MFC flag (from all the projects).

Revision 5789

Whoops, I also changed these.
I wish we were using Git, so I could have used "ammend last commit", and then no one would have ever known ;P
Well, we don't yet :p

Revision 5790

Installer: More fixes.
I'm glad linux installer is much easier ;)
By the way, could you give a quick look at the German translation? There are a couple of strings that would need a refresh.
Oh, just saw this. I guess I can take a quick look ><

Revision 5791

* update fr_FR/it_IT/es_ES/pt_BR
* refresh others for free ;)
The french translation still lacks support for "Enable Widescreen Patches".
Is it "goldeng" or "PlaysGames11" who is behind it now?
I updated ko_KR about "enable widescreen patches" and some correction.

Revision 5792

i18n: new language croatian
+ fix a french string (thanks pgert for the info)

Revision 5793

- FXAA shader replaced by Asmodeans shader suite 'PCSX2 Fx 2.00 Revised'.
This is an entire enhancement suite with many configurable options like FXAA,
texture sharpening
or lighting tweaks. Some of the effects are pretty advanced so kudos to him
allowing it to be integrated with GSdx! :)
Note that there's no interface for the tweaks yet. Until those are done, the
defaults will be used.
Release thread here: http://forums.pcsx2.net/Thread-Custom-Shaders-for-
- Disabled an option from the widescreen patches for SH:Shattered Memories.
Hum, I would need to port it to ogl or disable FXAA
Needs checking that everything is okay, someone's having issues.
Okay yea, a problem with OGl and DX9. I should've tested those ><
People are advised to wait for a fix if using ancient hardware :p
i'll stick with SMAA v2

Revision 5794

Installer: VS 2013 Redist detects if it's properly now under 64bit systems. Also
fixed some problems causing the web installer not to compile correctly.
Great :)

Revision 5795

Whoops, made a mistake there :P
Haha,don't leave AVG out ;)
cant do that! :P It was my bad, i misslabeled the variable :p

Revision 5796

GSDX: Fix/Hack for NVIDIA stretch issue on drivers > 320.18 with DirectX 11 when
using a custom resolution. You can enable it in the HW Hacks section, let me
know if there is a game it doesn't fix.
Slight adjustments to positions in the GUI also (OCD'd the spacing a little :P)
could whoever debugged this submit their findings/dumps/logs etc to devtalk.nvidia.com
Is this hack still necessary?
I'm a beta tester for nvidia and I could share some information with them is necessary.
hi Wagnard,
Yeah this hack is still needed, it seems like a bug has cropped up in coords/vertice handling, this also affects some pc games.

Revision 5797

Update German translation
Thanks I will regenerate the mo.
It is not my business, but here is my 2 cents: Some header fields could be filled in these files, like Project-Id-Version, Last-Translator, Credits in the first lines of the PO file (AUTHOR NAME <EMAIL>, YEAR)... It is good for give credit credit to the translator as well as it is good for everyone (even PCSX2 Dev Team) take record of who contributed at some point..
p.s.: Poedit can be configured with these settings.

Revision 5798

GSdx: Fix for the DX9 crashing issue, many thanks to Asmodean again! :)
(Also sets new defaults with only minor processing, mainly FXAA now)

Revision 5799

GSDX: New shader is quite slow to compile, so lets not compile it unless the
user is using it :)
-switching between sw/hw modes, resuming emulation speed back to normal.
Oh, I wondered if that was my imagination or not :p
We should profile the startup / shutdown sequence some time and eliminate other time consumers.
Ehr yea, from the code I can see this will break toggling the shader when it was disabled while initializing the plugin.
Is it possible to compile the shader on the fly with the plugin open?
Otherwise we need a different workaround for the slowness.
it doesn't break it actually, i tested that.
at least it slows down like its compiling it ;p
If you want to be sure, you can move the check in to thw create device, just above the shader compile if you want to be sure
Sure about what?
The shader doesn't work if you had it disabled in GSdx on game start but then hit pg down.
It looks like it has to be compiled on init, at least with our methods.
Any compilation at run time will certainly require a different d3d method (or method call).
It depends if it reinits the d3d device or not, ill test later :p
Yea, right, it doesn't :p
It's just a hotswitch to turn route the output through the shader or not (and it has to be compiled for that :p )
Then we can call the compile on the page up switch probably :p

Revision 5800

* update korean translation
* generate german binary mo file
Translation status:
locales/ar/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/cs_CZ/pcsx2_Main.po - 564/ 2/565 ( 99%) -1
locales/fi_FI/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/hu_HU/pcsx2_Main.po - 525/ 8/565 ( 92%) -40
locales/id_ID/pcsx2_Iconized.po - 49/ 48/74 ( 66%) -25
locales/id_ID/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/ja_JP/pcsx2_Main.po - 563/ 4/565 ( 99%) -2
locales/ms_MY/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/nb_NO/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/pl_PL/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/ru_RU/pcsx2_Main.po - 557/ 8/565 ( 98%) -8
locales/th_TH/pcsx2_Iconized.po - 72/ 3/74 ( 97%) -2
locales/th_TH/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/tr_TR/pcsx2_Main.po - 564/ 2/565 ( 99%) -1
locales/zh_CN/pcsx2_Main.po - 564/ 2/565 ( 99%) -1
locales/zh_TW/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
Thank you for fast update.
Very, very good. The new ones are bad, too slow...

Revision 5801

GSDX: Modified the FXAA shader loading so Page Up works again. Now loads the
shader just in time.
Works great :)
Good :)
no works for me .
nvidia drivers : 332.21
pcsx2 work but game don't load . error inside new video plugin ??
error when you check the box: FXAA
the emu crash ;-) too bad
check the box when? It doesn't crash here. If you're doing it during a video, it would crash on an old version too.
FXAA box is checked and close, running the emulator and then I raise it crash
test in direct3d11 mode
run me through your exact procedure from starting the emu and gsdx settings cos i can't make it crash
Run in win8.1
you're gonna have to give me a lot more detail than that...
Ému work but if fxaa valid
ISO game load and crash this ému révision plugin
GSdx: Post-processing shader is now enabled.
(149,48): error X3089: 'PS_VERSION': invalid shader target/usage
(149,48): error X3089: 'PS_VERSION': invalid shader target/usage
spam it..
Game - Wild Arms 4
PCSX2 1.1.0.r0 - compiled on Jan 8 2014
Savestate version: 0x9a0a0000
Host Machine Init:
Operating System = Microsoft Windows 7 Ultimate Edition Service Pack 1 (build 7601), 64-bit
Physical RAM = 12284 MB
CPU name = AMD Phenom(tm) II X6 1055T Processor
Vendor/Model = AuthenticAMD (stepping 00)
CPU speed = 3.499 ghz (6 logical threads)
x86PType = Standard OEM
x86Flags = 178bfbff 00802009
x86EFlags = efd3fbff
x86 Features Detected:
MMX2 .. 3DNOW .. 3DNOW2.. SSE4a
tell me what you're doing step by step.
for example
open the emu
go in to gs settings
tick x boxes
ok it
run iso
press a button
Also can you confirm it worked fine in r5798?
Not getting any problems either (testing with Wild Arms 4).
Everything works as it should.
ha, now you got me to write a comment...(btw great work on pcsx2, getiing better every day). i had just marvelled about the greatness of the fxaa shader in 5792 when i saw the updates
Got the crash as well.
confirming working fine with 5798 and 5800
i5 3570
32gb ram
gtx650ti on 372.23
game cd ffx-2 pal
open it up and boot cd full:
fxaa enabled immediate crash when bios should display. log is pretty silent, last message was a fps switch 60 to 50. disabling limiter produces same result.
just tick fxaa disabled and try again: works
d3d11 hw, 4xnative, aggressive crc, fxaa. rest default
mvu enabled fyi, but no-speedhacks also crashes
tried svx and sse4 version to be sure.. same results
wtf.. it still works here >.<
I might have to just make it enable it as soon as the emulation starts then if you have the box ticked and people will just have to suffer with the pause, i can't recreate the crash here at all :(
someone hit me with a pan.. it's too late to type straight over here
327.23 of course and avx
well probably doesn't matter anyways..
scratch that, the buildbot must be doing something funny with it, because that version crashes for me, but the local one doesnt.
I bet its a bloody VS2010 thing doing it wrong >.<
*loads up vs2010*
Confirmed - VS 2010 doesn't like it, but VS2013 is fine. Great..
should be fine in r5802 when the bot builds it
Just chiming in to say for the record that I've tried to debug this and have no idea. If CompileShader uses a return value instead of exceptions to signify failure the code works but I can't find an actual reason for whatever corruption is happening.
check all your ints.
VS2010 can 'optimise' stuff wrong if you don't cast Consts in some cases when Whole Program Optimisation is defined.

Revision 5802

GSDX: As the Optimization option in VS2010 causes GSDX to crash now, i've
disabled it. Whole program optimization is still on and the release will use
both (compiled with vs2013). So the SVN can like it or lump it ;p
Well, that is weird.
I know right?
(149,48): error X3089: 'PS_VERSION': invalid shader target/usage
on AMD 4850 videocard..
any ideas?
override_geometry_shader = 0
Your graphics card is too old for it i suspect, or the dx9 version of fxaa isn't right. This version of the SVN works fine for me now.
dx9 work fine, dx10 - spam
Its possible the new fxaa shader doesnt support directx 10. Officially we only have 9 and 11 now
mb disable support fxaa when choose dx10?
or disable in shader "not working" function?
disable fxaa if you use dx10
this revision work now with fxaa in hardware mode d3d11 AVX plugin,
but now this emu are very too slow
why ?
confirmed working now
quick bench of the same ffx2 scene max fps went down from 168 in 5792 to 158 in 5800 and 108 in 5801
quite some effect from -O
expected a drop by 25 only
oh well reason to grab me a vs2013 copy one day
glanced over the gsdev11 file, got no clue what's wrong..
best i could come up with is either some mscompiler hiccup with the commented part which still got some pp stuff or the pointer to .ps being beaten to a bulb before entering dofxaa
maybe move the loading in a seperate function and let the cc decide to inline when needed. seen the weirdest things in our c99 corp. linux soft.. pitty /me compiling it on linux wouldnt help you out here. maybe its some odd rearranging stuff with -O enabled that trashes the proper continuity..:shrug:
well svn isn't about getting an optimal build, so it happens, but as i say, the release will have all optimizations.
Disabling settings to work around magic code issues is so Dolphin-emu
lets find the issue instead.
you know you can disable optimisation per source file to isolate the source at fault right?

Revision 5803

GSDX: (FXAA) Treat shader model 4.1 as 4.0 and future shader models as 5 rather
than failing to compile.
more slow emu , i don't love this revision and other fxaa
to slow to slow
why ???
stop spamming the commit log with your question, its slower, get over it.
Well no, turning off optimisation is pretty bad. We might as well not have
a release target for VS2010 if we're going to do that.
Unfortunately the bug is elusive.
#elif (SHADER_MODEL >= 0x400)
this fix fxaa on amd4850 videocard spam, thx :)

Revision 5804

GSDX: Nonsense workaround for VS2010 crash issue. We suspect that memory is
getting corrupted but we've failed to find the code responsible. Many different
changes result in code that doesn't crash for no obvious reason, this one at
least looks vaguely like sane code though.
Reverted optimisation flag for VS2010 release target.
And no, we don't consider this the final word on the issue, we just need something to make it work now. Nobody's happy that we have corruption again.
I had problems with memory corruption in Supertuxkart using VC2010. Though it worked fine in VC2013 and gcc. Then I did stupid workaround - simply moved the variable declaration from private to public.
IIRC, the C++ standard defines the order in which the variables are placed in a class, so changing a variable from private to public will change the order of the variables in memory.
The C++ standard defines no such thing, but the compiler very likely did
change that. Like us, you had and still have a bug.
wtf, it actually worked..
For the record, I actually suspect the 2010 mscompiler to be rather edgy. Seen those workarounds appear like spawning mushrooms in 3rd party commercial soft we had to port to linux. Maybe somethings not quite right with tree analysis? (blaming the compiler shortens the QA phase ;) )
When -O actually works as intended the initfxaa would be inlined anyways. I kind of like this split from a SE point of view. Makes it easier to dissect the inner workings of functions, especially since this code was already moved once.
Alright works again, I'm out. Great work gentlemen.
I really doubt this is the compiler's fault (and I did step through the
generated asm, it looked fine to me). Issues like this have normally
turned out to be our fault, but finding the real bug is hard.
If any compiler is at fault its VS2013 for compiling magic code that works.
So i've been fluffin about with buildbot and compiles of my own, and i can't for the life of me cause a crash using the SSE binaries
is this only happening on AVX builds?
im building from 5801 ftr.
Bad news guys
Its not just D3D11 thats affected.
On my system its actually D3D9 thats crashing with FXAA, while D3D11 does not. :|
And debugging points to a similar block of code in the GSDevice9.cpp that you changed in the GSDevice11.cpp
Not entirely surprising. Unfortunately that doesn't help us find the bug,
it needs a fresh pair of eyes.
MTGS is hindering my effort to analyze the memory, can't get the GS plugin to start up due to the Dr.Memory analyzer slowing enumeration of the GS core down.

Revision 5805

Dev9ghzdrk: Take the first 3 bytes of the host MAC for the virtual one, should
make it unique for people using xlink or multiple people playing the same game.
Hopefully this works anyway ;)
only 5 years late, right?

Revision 5806

zzogl: fix wrong type access
cmake: don't strip by default the binary in release mode
gsdx: disable the regeneration of ogl shader

Revision 5807

gsdx ogl linux: use OGL renderer by default otherwise it fallback to unsupported
GSDeviceNull which badly crash
yeah nice speed , emu are good now
fxaa are not tested.
fsp old revision 19fps , now 50fps in sly racoon test game

Revision 5808

gsdx ogl: don't rely on GL_ES builtin (3 differents implementations...).
Hopefully fix Linux Intel GPU.

Revision 5809

Finish up my scanlines attempt. Now the 2 old shaders are back in and all 3
cycle on F7.
Can you make them stick (even when first turning the emu back on)? When using Software FMV hack, you have to keep pressing F7 to turn them back on.
F7 can be like fxaa the same regardless of software or hardware mode mode has been turned on, and that nice
Could do that, yea. But before that I'd rather tweak the GSdx settings dialog a bit, just to accommodate all these options.

Revision 5810

gsdx ogl: do the same as previous commit but for ogl ;)
* fix the missing auto interlace opt when cycling with hotkey on linux
And it's a lot cleaner, too! :)

Revision 5811

the regular copy/past mistake

Revision 5812

Add another scanline algorithm, made by pseudonym. This one is pretty fancy,
using a cosinus function for generating the dark lines.
It only works on unscaled output, so use software rendering or native resolution
for hardware.
It's an effect that works best on 240p converted games (like the SNES titles in
Mega Man Collection).
Comparison pics: https://imgur.com/a/KC4Ij#0
Why are you using a cosine function for a discrete dataset? Doesn't that expand into taylor-series? That's whould create less accuracy and lower speed...
Why don't you use something like:
switch(4*((input.t.y * texdim.y) % 1))
case 0: output.c = 0; break;
case 1: case 3: output.c = 0.5*[...]; break;
case 2: output.c = 1*[...]; beak;
return output;
this should be faster
i'm stupid... why not
output.c = (2*((input.t.y * texdim.y) % 1)*[...];
Isn't the output a little dark?
Texture.GetDimensions(texdim.x, texdim.y);
GetDimensions requires shader model 4 or higher, doesn't it?
Might need to remove it from the d3d9 section, and use inverse texdim instead.
Looks nice though :)
I could've sworn I tested dx9! Damn :p

Revision 5813

GSdx: Quick workaround for DX9 until the shader is adapted.

Revision 5814

GSdx: Newest scanlines shader looks much nicer this way :)
looking nice :)
I don't get it... Why do you implement these scanline shaders at all?.. It makes image worse, like an ancient TV screen...
and THAT is the point.
Mega Man X has never looked so gorgious! Nice. I'm a fan of scanlines on the older games - it just seems to mask their imperfections a bit and give it the old school look. Two thumbs up for this work!
Look at the power bar on the left and compare the 2 screenshots.
One is blurry, the other sharp. That is part of the effect.
The other important part is the illusion of additional detail, especially
noticeable in backgrounds. Without scanlines they have the typical "emulator look": flat, simple, uniform surfaces.
With scanlines they appear much more detailed and lively.
If you don't see it, never mind. But some people do and they want nice scanline filters :)
Great, the brightness is perfect now!

Revision 5815

GameDB: COP2 patch for Kessen 2 US version - Fixes Graphics. Will patch the EU
version when i can get a dev build run on it.

Revision 5816

GameDB: Kessen 2 patch for EU version SLES 50578
was it fine with r57xx releases? because i don't believe that. Can you find out the exact revision it broke on from the builds on the buildbot and then make an issue for it, rather than replying to random commits.
The EU version works fine here. Not tried the US version yet.
US version works fine too. I suggest you check your settings.

Revision 5817

Last patch regarding FXAA and external shader loading, I hope :)
Changes are here: http://forums.pcsx2.net/Thread-Custom-Shaders-for-
I've included bin\shader.fx and the settings file bin\GSdx_FX_Settings.ini.
The build bot version of this stops responding in d3d9 when you try load an external shader.fx that doesn't work/fails to load, on dx9 (This doesn't happen if you compile the source yourself). It should be falling back to ps_recover (like dx11, which does). Perhaps There should be init functions added to dx9 also.
This only happens in dx9, and its the only problem I've been able to find.
Once again the curious issue of the vs2010 crash moves again >.<
Ikr >.<
Not really specific to this commit, but: The build bot seems to be dishing out either the wrong pcsx2 binary versions now, or simply putting the wrong svn numbers on the builds. As reported here: http://forums.pcsx2.net/Thread-Custom-Shaders-for-GSdx?pid=343819#pid343819
Yeah its been doing it for a while, orphis is going to update the bot to vs 2013 and sort that out at the same time.
Ah, nice one. That'll be handy for sure.
external shaders not working for me [dx11 win8.1], just nothing happened
internal was working ~`5793-5816` revs
in win7 with same inis, on same harwdare, external shaders works

Revision 5818

gsdx ogl:
* restore the old fxaa (Asmodeam will be integrated when I got time)
* port the recently added new scanline algo

Revision 5819

HTB123 on our forums came up with a hack that removes the broken main character
shadow in hardware rendering
in SMT Nocturne.
This should work for all GSdx recognized versions / regions of the game (tested
EU and NTSC-U).
Nice one ^.^
I think I was doing something like this, in memory with a patch at one stage. I must take a look at the WS patches for this, and ensure it's removed.
Oh yea, it could be I already removed such a patch earlier. There were some like this that modified the game further than a ws patch should.
Unfortunately the shadow's is broken in the OGL renderer.
This revision makes it completely invisible, where as in r5818 it had a sort of "opposite" effect in which it removed environment shadows.
Ask him if he can fix Castlevania shadows too.

Revision 5820

GameDB: Added some missing games. Thanks for GeoMan and shinra358 on the forums
That was fast xD

Revision 5821

The preferred audio output module is PortAudio, so making it the default under
Windows now (it is already on Linux).
It will use wasapi mode with the default sound device by default, both are
configurable though.
This setup gives us better latency and a higher time stretch polling frequency,
resulting in better quality overall.
With this we can also lower the main latency default from 150ms to now 100ms.
There is no error checking for the wasapi mode selection yet, as I don't know
how this should be done.
Help would be appreciated (gigaherz!) :p
I'm getting much worse audio-video desync while recording with the new output module (or lower latency, not sure which or both). Would be nice if someone checked that too :P
That shouldn't happen.
IIrc the recording stream never goes through the regular output modules, it's directly dumped to disk instead.
With this plugin I can't hear any audio (Windows XP - Soundblaster XFii Gamer)
then upgrade to windows 7, windows xp is completely outdated.
or select another backend.
Use xaudio if you are on xp. Though you really should get a new operating system.
Precompiled up to date portaudio builds should be provided with the pcsx2 windows builds if portaudio is now the preferred plugin, as these precompiled builds seem to be outdated: https://github.com/adfernandes/precompiled-portaudio-windows
Portaudio windows audio quality is really good, but Xaudio 2 still sounds a little better and allows lower latency to be set on my system (in async audio mode because I think time stretched audio always sounds stretched and ugly).
In both plugins however, Dragon Quest 8 audio effects during battles are missing every 3rd or so time the emulator is started, so there seems to be some audio initialization timing related bug. Two times (rough estimate) it works and the next time the effects are missing.
Ok, one problem at a time:
- Audio missing would be entirely an emulation bug, not related to this commit.
- Sound quality is totally unaffected by this change.
- Latency is better with Wasapi (Portaudio is just the mediator) for me and one other dev (we both use Win7 x64). It could be different on other Windows versions, but except WinXP, I doubt it.
- Thanks for the Portaudio build suggestion. I'll have to see if it applies to anything we use. SPU2-X as of this commit works just fine with PA built-in though.
Hopefully other backends are available via Portaudio on your XP.
The default (Wasapi) isn't supported anymore though.
@scientificraver: We build our own portaudio, as a static library, which gets liked into spu2-x. It has no external depencendies.

Revision 5822

Change the vs2012 project files to use the v110_xp platform toolset, and the
vs2013 project files to use the v120_xp platform toolset, so that the resulting
executables can be run in Windows XP/2003.
Thanks :)

Revision 5823

WinXP should be exempted from Portaudio as the default for now.
It has a large latency with DirectSound compared to direct use and XA2 isn't
available at all.

Revision 5824

pcsx2: Used correct path for cheats/cheats_ws (thanks avih)

Revision 5825

i18n: update sv_SE/tr_TR/ko_KR + refresh others
Not finished translation status
postats locales/*/*.po | G "100%"
locales/ar/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/cs_CZ/pcsx2_Main.po - 564/ 2/565 ( 99%) -1
locales/fi_FI/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/hu_HU/pcsx2_Main.po - 525/ 8/565 ( 92%) -40
locales/id_ID/pcsx2_Iconized.po - 49/ 48/74 ( 66%) -25
locales/id_ID/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/ja_JP/pcsx2_Main.po - 563/ 4/565 ( 99%) -2
locales/ms_MY/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/nb_NO/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/pl_PL/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/ru_RU/pcsx2_Main.po - 557/ 8/565 ( 98%) -8
locales/th_TH/pcsx2_Iconized.po - 72/ 3/74 ( 97%) -2
locales/th_TH/pcsx2_Main.po - 563/ 2/565 ( 99%) -2
locales/zh_CN/pcsx2_Main.po - 564/ 2/565 ( 99%) -1
locales/zh_TW/pcsx2_Main.po - 563/ 2/565 ( 99%) -2

Revision 5826

redo commit r5824 with the eye open this time...
works :)

Revision 5827

Support single widescreen dbf file. Also includes a batch file to create a
cheats_ws.dbf file from individual pnach files, and also includes the
cheats_ws.dbf file which was generated from the current individual ws cheat
pnach files.
Still needs: 1. remove all single ws pnach files from the repository. 2. Update
the installer/uninstaller accordingly.
Note that reading individual ws pnach files from the cheats_ws folder is still supported.
In fact, if cheats are found and loaded from the cheats_ws folder, then they override the ws cheats at the cheats_ws.dbf file. This way people can still trade individual ws patches and they'll override whatever is at the dbf file.
The installer, however, will now only include a single cheats_ws.dbf file instead the thousands of individual ws cheat files.
Add fastCDVD and MTVU function GameDB, these two functions are not all games support
This is a patch:
Index: AppCoreThread.cpp
--- AppCoreThread.cpp (Version 5829)
+++ AppCoreThread.cpp (Working Copy)
@@ -256,6 +256,20 @@
+ if (game.keyExists("fastCDVD")) {
+ bool fastCDVD = game.getInt("fastCDVD") ? 1 : 0;
+ if(verbose) Console.WriteLn("(GameDB) Changing fastCDVD [mode=%d]", fastCDVD);
+ dest.Speedhacks.fastCDVD = fastCDVD;
+ gf++;
+ }
+ if (game.keyExists("MTVU")) {
+ bool vuThread = game.getInt("MTVU") ? 1 : 0;
+ if(verbose) Console.WriteLn("(GameDB) Changing MTVU [mode=%d]", vuThread);
+ dest.Speedhacks.vuThread = vuThread;
+ gf++;
+ }
for( GamefixId id=GamefixId_FIRST; id<pxEnumEnd; ++id )
wxString key( EnumToString(id) );
It goes too far, yxmline. We don't want to have every tiny detail in the database, as each detail requires re-checking once in a while.
Who can say how mtvu will behave in a year, for over 9000 games.
I understand

Revision 5828

Wide screen hacks db: fix boot to bios (was trying to load all patches, now only
the patches for CRC 00000000)

Revision 5829

Installer: Update to include new cheats_ws.dbf file

Revision 5830

Small round of patches for various issues.
Hung should be Hang :P
Nope, it's simple past for hang = hung.
Never mind the other typos though :p

Revision 5831

Small round of patches for various issues, #2.
This one stops an oversized stack warning and adds the NULL check to the GS version of GrowVertexBuffer().

Revision 5832

GSDX: Fixed the allocation checks in the previous couple of revs.

Revision 5833

GSDX: Forgot to remove a bit of cruft in the last rev.

Revision 5834

This fixes the crashes on F9 for me. We don't want to call GSgetTitleInfo2()
when GSOpen() isn't finished yet.
After all it wasn't me that introduce this bug :) However not sure we want to keep the printf for the release.

Revision 5835

Refinement of the last patch.

Revision 5836

Widescreen hacks db: change from dbf to normal zip (also replaced the dbf with a
zip of current ws hacks).
Logic stays the same as before: If no ws hack is loaded from the normal
cheats_ws folder, they try finding ws hacks at the zip.
src/pcsx2/pcsx2/Patch.cpp: In function ‘int LoadCheatsFromZip(wxString, const wxString&)’:
src/pcsx2/pcsx2/Patch.cpp:229:88: error: cannot pass objects of non-trivially-copyable type ‘const class wxCharBuffer’ through ‘...’
entry->GetName().To8BitData(), cheatsArchiveFilename.To8BitData());
src/pcsx2/pcsx2/Patch.cpp:229:88: error: cannot pass objects of non-trivially-copyable type ‘const class wxCharBuffer’ through ‘...’
A comment would have been enough.

Revision 5837

ws_cheats folder goes back to documents (following r5640, r5824 and r5826). This
way the installer only installs the cheats_ws,zip file at the installation dir,
while users could put their own ws cheat files at cheats_ws folder under
documents. Portable mode is unaffected.

Revision 5838

Just a couple of small fixes picked up by the compiler, no change to emulation.

Revision 5839

Another small thing picked up by VS Analyzer. Again probably no actual change in

Revision 5840

GSDX: Clear up all compiler warnings. No changes to emulation.
If you want, I have a tons of warning with GCC (and surely 2 tons with llvm in the future :) )
It's okay thank you, ill let you handle those xD

Revision 5841

Installer: use cheats_ws.zip instead of dbf

Revision 5842

pcsx2: restore linux compilation (remove the bad line as a temporary solution)
all: correct various printf format warning
Here a nice overview of default gcc warning (minus all warning disabled)
Total: 257
$VAR1 = {
'spu2-x' => {
'unused-variable' => 1,
'sign-compare' => 1
'GSnull' => {
'unused-variable' => 2
'CDVDlinuz' => {
'pointer-sign' => 12,
'unused-but-set-variable' => 1
'zzogl-pg-cg' => {
'reorder' => 6,
'sign-compare' => 36,
'unused-but-set-variable' => 18,
'unused-variable' => 4
'GSdx' => {
'unused-variable' => 20,
'unknown-pragmas' => 8,
'unused-but-set-variable' => 3,
'sign-compare' => 4
'pcsx2' => {
'ignored-qualifiers' => 45,
'sign-compare' => 72,
'extra' => 2
'zzogl-pg' => {
'unused-variable' => 2,
'sign-compare' => 18,
'unused-but-set-variable' => 4
'CDVDiso' => {
'sign-compare' => 18
Hum, with all warnings
Total: 683
$VAR1 = {
'CDVDlinuz' => {
'unused-but-set-variable' => 1,
'pointer-sign' => 12
'spu2-x' => {
'sign-compare' => 1,
'unused-function' => 1,
'unused-variable' => 1
'pcsx2' => {
'missing-field-initializers' => 108,
'extra' => 2,
'sign-compare' => 72,
'write-strings' => 1,
'ignored-qualifiers' => 45
'CDVDiso' => {
'write-strings' => 8,
'sign-compare' => 18
'zzogl-pg-cg' => {
'sign-compare' => 36,
'unused-value' => 22,
'write-strings' => 40,
'unused-variable' => 4,
'unused-but-set-variable' => 18,
'parentheses' => 2,
'reorder' => 6
'zzogl-pg' => {
'unused-function' => 65,
'write-strings' => 40,
'unused-value' => 22,
'sign-compare' => 18,
'parentheses' => 2,
'unused-variable' => 2,
'unused-but-set-variable' => 4
'SPU2null' => {
'write-strings' => 11
'GSnull' => {
'write-strings' => 3,
'unused-variable' => 2
'GSdx' => {
'write-strings' => 17,
'parentheses' => 69,
'unused-but-set-variable' => 3,
'unknown-pragmas' => 8,
'unused-function' => 1,
'unused-value' => 31,
'sign-compare' => 4,
'unused-variable' => 20

Revision 5843

VIF: Placed a flag set in the correct place on VIF stalls. Gets rid of the error
on Yakuza (and hopefully solves the hangs)

Revision 5844

Better fix for linux compilation: r5836 broke compile on linux, r5842 ifdef'ed
it out, this should be better.
Thanks :)

Revision 5845

Copy the individual widescreen patches to a separate branch, for reference.

Revision 5846

Delete the cheats_ws folder, now that we have the Zip file and also a copy.
Note, there's now a branch cheats_ws which only contains the ws hacks.
Ideally, whenever we have an updated set of ws hacks, we update the cheats_ws branch, then zip the files to cheats_ws.zip, then copy the zip over to the main archive.

Revision 5847

Installer: Removed /Cheats_ws folder creation and file copy as it's no longer
needed. Added as a "User Files" so the directory can be deleted if the user so

Revision 5848

GUI: Create cheats_ws folder in My Docs for user custom widescreen patches.
Me no like things that go into mydocs :P
Does the portable.ini affect this?
Why not have 2 folders in the emu folder in which 1 has the default patches and the other contains the user created patches and the user created patches have more priority over the default one (user created loads first and omits duplicate in default folder) instead of mydocs?
yes, if you have the portable.ini, it will assume everything goes in your pcsx2 directory rather than My Documents :)
Oh ok, whew

Revision 5849

Further normalization of the cheats_ws folder.

Revision 5850

* use same path as game index db for cheats and cheats_ws
* install the new cheat zip file on cmake and debian installer
I think it would be nicer without all the ifdef for linux folders. If the folder structure is very different on linux, we could still change it only "deep" at the API such that the rest of the code which uses the API gets the correct folder regardless of OS.
AppRoot() seems to be working on linux, we could probably use that, can't we?

Revision 5851

pcsx2: Create GetProgramDataDir (for cheats_ws and game db)
This causes an assert error, however if you ignore it, it will still work.
Try to revert AppGameDatabase.h

Revision 5852

Silencing assert for the moment as it seems to work regardless. (assert
triggered since r5851)

Revision 5853

Installer: Removed SDL.dll as it is no longer required by any plugins.

Revision 5854

Updated Widescreen hacks. Removed hacks where different regions (PAL/NTSC) share
CRC as this will cause problems. KH2 PAL fixed thanks to devina40 :)
So I guess we're not doing the "first update the cheats_ws branch, then update the zip at the main repo" procedure? :)
We're losing the ws hacks history this way...
meh ill do it later ;p
I see how it'll never happen ;)
Not blaming you. Working with two branches whenever we want to update the ws patches is really not fun.
Is there any point in keeping wide screen hacks history? Aren't newer ones always improved / bug fixed?
The hacks are cared for by the community and we're making it extra hard on ourselves when we try to keep track of changes.
In this case I'm for updating the branch with new versions every so often, but not trying to keep every single patch revision up to date.

Revision 5855

Cheats_ws archive: Update existing cheats and add new ones

Revision 5856

* add a PERL script to ensure translation quality (ie check c-string format)
* Fix c-format error as best as can! It will hopefully fix various potential

Revision 5857

i18n: refresh all languages with previous fix incorporated

Revision 5858

Small round of patches for various issues, #3.
Fixed a bad string in the German translation, added GSdx-avx2 to the installer,
silenced a debug print and shortened the app name in release builds.

Revision 5859

Fix for intention change in last commit, was an oversight :p

Revision 5860

gsdx ogl: correct most of Z-depth issue
Best setting if you driver support GL_NV_depth_buffer_float => GL_NV_Depth = 1 &
logz = 0
Otherwise => GL_NV_Depth = 0 & logz = 1
Explanation of the bug:
Dx z position ranges from 0.0f to 1.0f (FS ranges 0.0f to 1.0f)
GL z Position ranges from -1.0f to 1.0f (FS ranges 0.0f to 1.0f)
Why it sucks:
GS small depth value will be "mapped" to -1.0f. In others all small values will
be 1.0f! Terrible lost
of accuraccy.
The GL_NV_depth_buffer_float extension allow to set the near plane as -1.0f.
"GL z Position ranges from -1.0f to 1.0f (FS ranges 0.0f to 1.0f)"
will become
"GL z Position ranges from -1.0f to 1.0f (FS ranges -1.0f to 1.0f)"
and therefore
"z posision [0.0f;1.0f] will map to FS [0.0f;1.0f]" as DX
Yes we just get back all precision lost previously :)
However you need hardware (intel?) and driver support (free driver?/gles?) :(
It really is a shame they don't let you use a significantly larger floating point range...
Persona 4 looks great.
SMT:Nocturne does too, though the protagonist has completely lost his shadow recently, whereas it was buggy several revisions back, could you maybe have a look at it?
I also can't help but notice that somewhere between August and December last year, fog stopped working, gives you a rather steep advantage in wizardry: Forsaken Lands :)
Could you provide me some gs dump? Hit ctrl shift F8, keep shift (or what is it ctrl) a bit so it can dump several frame. Gs file will be located in your snap directory.
Besides if you know the exact revison that broke the game it would help me. It took me more than a week to fix this depth issue!
I fix the fog in next commit :)
Tell me if shadows are still broken.

Revision 5861

gsdx ogl: Fog hide this typo :p
The GS dump for Nocturne: https://dl.dropboxusercontent.com/u/23891252/gsdx_20140201183122.7z
r5819 removed the broken/buggy shadow, where as in r5818 and prior it kind of scissored with environment shadows to remove them.
Thanks for the dump. I can reproduce the issue on my side. I hope those hack are compatible with my GL backend. Anyway I maybe add a regression when I try to add advance GL4 for date (destination alpha testing often used for shadow)

Revision 5862

gsdx ogl:
* gui refresh
+ Use some tab to reduce heigth for small screen
+ Add logz option
+ remove broken/experimental keyword. GSdx ogl is not too bad ;)
* autodetect GL_NV_depth_buffer_float
Linux tester you are welcome!

Revision 5863

i18n: refresh all translations

Revision 5864

gsdx ogl: Only enable advance DATE when user request it

Revision 5865

New pdfs for 1.2

Revision 5866

Release version numbers.

Revision 5867

And the .docs

Revision 5868

Tag release

Revision 5869

Would it be possible to have a tar.gz source of the tag v1.2 available for Download? Currently, the Downloads page has only v1.0.0 and v1.1.0...
Yes, get it from the Github mirror: https://github.com/PCSX2/pcsx2/releases
Google is phasing out the downloads system of googlecode, so we can't upload new files anymore.

Revision 5870

Regular version numbering for SVN again. We're at 1.3 now :)

Revision 5871

House-cleaning: remove some obsolete branches.

Revision 5872

GSdx: Just some small post processing cleanup changes, should lower the FXAA
compiling time on pause/resumes.
welcome Asmodean, may your road be full of nice bugfixes. :)
also, there are some issues on issues section that could get your attention. ;)

Revision 5873

VIF MFIFO: Missed the MFIFO when i did my VIF change in r5843 which would have
stopped some games working.
Well, happens :p

Revision 5874

GSdx: Store the user selected F7 shader to the ini, as TVShader.
As before: use the hotkey(f7) to switch between them. It will now save the
chosen scanline effect, instead of always defaulting to disabled, on load.
woo hoo
You're allowed to update linux code 10 lines below :p

Revision 5875

GSDX: Just correcting some typo's

Revision 5876

Created wiki page through web user interface.

Revision 5877

Edited wiki page DownloadsNotice through web user interface.

Revision 5878

GSdx: Anisotropic Filtering.
Adds anisotropic texture filtering (1x-16x) to the hardware settings. Enhances
the visual quality of textures that are at oblique viewing angles.
Anisotropic filtering is automatically disabled if: 8-bit textures are enabled.
Nice! AF makes everything look better.
Nice :)
Asmodean, fix the damn shadows in Castlevania games too? :3

Revision 5879

GSdx: Anisotropic Filtering.
Fixes a small oversight on my part. Which was setting the maximum anisotropy to
(0,1,2,3,4) respectively, instead of (1,2,4,8,16). So when you selected x16 for
example, you were actually only getting x4 >.>
Corrected now, and you will be getting the full x16 when selected :)

Revision 5880

Games db: normalize (4 missing games name, few places where compat appeared
after the hacks section, removed 2 almost duplicate entries (-T at the serial).
Good job :)
right :p

Revision 5881

GSdx: Just tidying up a few last things, to wrap up the AF changes.
Also disabled the gsdx AF options for the OGL renderer (because it's not
implemented for that yet).
Extra rendering threads text doesn't fit on the config window anymore.
Don't know how I missed that. Thanks.

Revision 5882

GSdx: Dialog label fix.
Extra rendering threads label text was getting cut off early.

Revision 5883

Tag the 1.2.1 release at r5875

Revision 5884

GSDX: Fix up the GUI that displays during the First Run Wizard

Revision 5885

rename Arabic folder, one user suggested it fixed some problem causing PCSX2 to
boot. Makes it more uniform so it can't hurt i guess.
No it is wrong (at least on linux). The local ar_AR doesn't exists. Not uniform but ar is correct.

Revision 5886

It might be a good idea to notify the emulator that the disc changed on a disc
Might be :p
It might help that monster breeding game as well, the one that requires disk changes to create new monsters.
Didn't help Samurai Warriors 2 XL import, still says wrong disc. Will try Dynasty Warriors 4
Same for DW4, but I guess this was not the point of this revision :P So yeah, changing disc and saving/loading state now correctly loads/saves a state for the new discs CRC/ELF

Revision 5887

Create a 1.2 branch from the 1.2.1 tags

Revision 5888

gsdx ogl:
* properly detect gl nv depth extension
* Always show the hack on the gui. Add a new hack option for DATE (gl4.2) only
* Save the scan mode on linux too (f7)
* hopefully fix some crash on some drivers... (ensure aligment 256 bits
alignment, and if not use std memcpy)

Revision 5889

Langs: Change the Arabic name properly, update relevant files (thanks for the
heads up Gregory :) )

Revision 5890

gsdx ogl: Enable by default advance DATE effect on nvidia (GL4 GPU)
Note: DATE is used for shadows (persona 3) and others effect
You can disable it when you disable gl image extension
(override_GL_ARB_shader_image_load_store = 0)
You can also enable it on AMD too (set it to 1 this time) but no guarantee.
If you feel the extension is too slow, you can try disable some gl barrier (aka
"damn the torpedo full steam ahead!").
It can be done with the option UserHacks_DateGL4 = 1. Otherwise just disable the
Note: don't enable UserHacks_AlphaStencil in the same time.
GL_ARB_shader_image_load_store is an alternative implementation.
Enabling both in the same time will lead to undefined (well surely wrong)

Revision 5891

the "don't let users shoot themself in the foot" commit
UserHacks_AlphaStencil will take precedence on

Revision 5892

GameGB: Syphon Filter - Omega Strain Europe patch for Flashlight. Removed an
incorrect/pointless patch on the US version.
Pal version works perfect.
Great job!!. :D

Revision 5893

SPU2-X: Just fixing up a small error i came across while looking into something
else. Nothing to see here.

Revision 5894

GSdx: A few small post-processing changes, to accommodate future updates.
Also removed the fallback recovery ps, and replaced the compile fail catch to a
simple console print. Which I think is safer, and faster.
Is that comment really necessary? I haven't looked at it, but it's probably just due to MS Notepad only supporting CR/LF line endings. Then again, who uses MS Notepad for any sort of development?
Also, that link you put into the comment links to a specific version of Notepad++, which I highly doubt was the best idea. Just my two cents.
>>Then again, who uses MS Notepad for any sort of development?
All users of this shaders should be able to edit the settings. Therefor the ini is made​​.
Against the recommendation of a better editor than MSNotepad nothing to say.
The referring to this particular version, is probably due to the circumstance that NPP uses this address for its current download page.
Those who have nothing else to contribute constructive, just bitching about Peanuts ...
keep your 2 cents back ...
Good work :) Asmodean
If that's true then why doesn't Asmodean just change the line endings so that it's compatible with MS Notepad? FWIW, when I download it through Google code it has CR/LF line endings and displays properly through MS Notepad on Windows 7 although Google code could be changing the line endings. I'm not familiar with SVN, but it could also be converting the lines to LF during checkout.
Again, you really should avoid linking to a specific version of software unless there's compatibility issues with newer versions. Asmodean could have simply linked to Notepad++'s homepage.
Instead of attacking my comment, how about trying to understand why I asked if those comments are really necessary and my concern with linking to a specific version of software?
In the case you're unable to comprehend why I asked:
1) The author doesn't appear to understand why it may not display correctly in certain text editors
2) It appears that instead of trying to understand why it may not display correctly in MS Notepad and correct the file the author added those comments
3) The author linked to a specific version of software
It just appeared a bit hackish to me. I apologize to the author if I came off sounding harsh. This clearly isn't something that really matters and I was simply pointing it out and presenting my opinion. However, I do not apologize to Erze whom failed to understand why I asked and attacked my comment.
Also, why are there C++ style comments in an INI file? Or is it even an INI file?
Again, small things and simply my opinion. I apologize if I offended the author.
afaik SVN controls the line ending style which is set to "Native", so it may vary from what normal Notepad uses, but wordpad or Notepad++ or Ultraedit, even Textpad will work fine.
>> So, why are there C style comments in INI file to? Or is it even to INI file?
I recognize that you have not really understood how it works. Shaders can't autonomously perform any file queries. The ini is a part of the shaderscode and is included when compiling the shader code.
Line 17 of GSDXFX aka shader.fx:
# include "GSdx_FX_Settings.ini"
The whole thing is a bit tricky. The separation of code and the particular normal users variable makes the whole very clear...
... and it probably makes it later possible to fixed integrate the code portion a plugin ...or something
I have no idea what is planned, but the whole makes sense ...
The introduction of a notation such as:
"# define variable value / / [Possible Settings] other comments...."
...facilitates later writing a GUI. This notation makes the parsing very easy.This is exemplary well resolved
only think ahead a little
>>3) The author linked to a specific version of software
Look @ my last post...
May i suggest adding The FX Settings to the GSdx Plugin window to avoid the confusion of editing the INI file .
It's easy to me but it's going to be a pain to the normal user regardless of the Editor used.
Yes. I wrote this to (eventually) be parsed and integrated into a GUI. Hence the guideline value min-max ranges.
Comments are typically added as a means to convey information. Which is what I'm doing. Why so upset by the addition of some comments?. What about the other 80+ comments used for descriptive purposes?
1: I do indeed understand why the file is not being displayed correctly in certain text editors, and it's not because of line endings. I'd already tried this - it's because of tabbing/spatial differences. I wouldn't consider this particularly high priority. It's only a bit messy for now, if viewed in the more simple of text editors. It will need to be manually reformatted to sort this for all editors.
2: I think you presume to know a bit too much here.
3: That is the url NP++ host provides. Go to the notepad++ site, and click downloads, then view the url. This is only temporary. Do you think I don't plan on any more updates to this?
If those who disliked the messy text just took my advice for now, instead of fighting it. This would look fine for the moment. As demonstrated here: http://forums.pcsx2.net/Thread-Custom-Shaders-for-GSdx?pid=350613#pid350613
Hard as it may be to believe, I do have other things I'm working on for this currently, besides formatting of text.
I hope this explains, and answer some of the questions here. If not, ask away.
Even if that's what the host provides, it's still linking to a specific version. Mentioning Notepad++ or linking to the homepage instead would have sufficed.
IMO, for something that's still a WIP it would probably be better to maintain a separate branch instead of commiting to the master and just cherry-pick your changes from the branch when you think they're ready.
For the tab/spacing, couldn't you just remove the art and put the comments on newlines if MS Notepad users are important to you?
Again, small things, personal opinions, I apologize if I offended the author. I'm a bit nitpicky sometimes.
Yes, G4Oblivionyt, you are wasting people's time here and I'd like you to stop it.

Revision 5895

1.2.x: keep a trace of ppa package update for 1.2 release

Revision 5896

1.2.x: cherry pick r5888 from trunk

Revision 5897

GSdx: Just some cleaning.
Reformatted fx files that were causing issues on certain text editors. They
should now display correctly in those editors.
you can see the beauty right in googlecode!
respect, I am way too lazy to do extensive formatting in my code
Lol ikr. Well, It was annoying me as well, and people kept asking why it looks like shit. Might as well just fix it ;p
I like to mark a text block and do ctrl+k, then ctrl+f on it in Visual Studio.
That's the auto formatter and it looks okay :p
please move GSdx_FX_Settings.ini into the /inis/ subfolder, remembering to account for portable mode.

Revision 5898

Just a bit of GSdx debugging.

Revision 5899

These might be needed, dunno.
Good job! :P
Tends to be needed yes xD
Buildbot still doesn't have it compiled though..
It has now

Revision 5900

Counters/Vsync: Adjusted VSync according to an older test we had. Fixes Legendz
Gekitou! Saga Battle. Also adjusted the number of scanlines depending on if
the game is using interlacing or not.

Revision 5901

create a 1.2.2 tag from the 1.2.x branch

Revision 5902

Remove vs2008 project files, since they have become outdated, and complicated to
OMG, it about time :) (yes it was a nightmare when I added files in GSdx)
I also proposed removing vs2012 files, and leaving only vs2010 for XP users and people who can't upgrade to 2013, and vs2013 for everyone else. But we decided to leave vs2012 for a while longer.
gigaherz - good idea.

Revision 5903

Vsync: Put it back to half slices, there seems to be games which don't like the
vsync timing more accurate either way. Until i can work out why we will go back
to the old half n half timing which all known games seem happy with.

Revision 5904

If you're gonna do a revert, you might as well do it properly :P If you don't
want it doing properly, give it to me.

Revision 5905

Initial debugger work by Kingcom. Features:
- Advanced disassembly view for R5900 and R3000
- Register list with change highlight
- Editable memory view
- Conditional execute breakpoints (r5900 only)
- Step over
- Scan for functions (incomplete), show macros
- Enable C++11 for debug tools.
- Expression parser
- Disasm updates for thread safety
Squashed from: https://github.com/PCSX2/pcsx2/pull/1
Thanks to Kingcom for coding it all and mziab for Linux patches
Lots of this started on PPSSPP, so a big thanks to everyone in that team as well.
We were missing a debugger for quite some time now :p
Command list here:
disassembly view:
ctrg+g goto
ctrl+e edit breakpoint
ctrl+d enable/disable breakpoint
ctrl+b add breakpoint
right follow branch/position memory view to accessed address
left go back one branch level/goto pc
up move cursor up one line
down move cursor down one line
page up move visible area up one page
page down move visible area down one page
f10 step over
tab toggle display symbols
left click select line/toggle breakpoint if line is already highlighted
right click open context menu
memory view:
ctrg+g goto
ctrl+b add breakpoint
left move cursor back one byte/nibble
right move cursor ahead one byte/nibble
up move cursor up one line
down move cursor down one line
page up move cursor up one page
page down move cursor down one page
0-9,A-F overwrite hex nibble
any overwrite ansi byte
left click select byte/nibble
right click open context menu
This is great work!

Revision 5906

Missed these files while juggling with git<->svn

Revision 5907

Really, svn? those files clearly were in the patch I gave you, you created them
on disk, how did you forget to add them to the commit?!
Maybe SVN replies one day :p
yes i'll try to compile it and fails now compiles XD
anisotropic filtering is a great addition guys, a greeting and thx from morocco guys.
Great. Step forward for pcsx2
Another great step would be to ditch that POS that GC and SVN are and move to github.
Some people are not convinced yet ;P

Revision 5908

Added insane EE cycle rate multipliers because they get requested so much.
Requires editing the pcsx2_vm.ini directly. Set EECycleRate = whatever (between
3 and 99).
But for what i use that?
If your pc is too slow to get full speed even with regular speedhacks, you can use this to get your fps even higher. It will pretty much break the game but some people prefer this state, as the audio might work better.
Is it mean we can overclock and underclock EE via pcsx2_vm.ini?

Revision 5909

Kingcom fixed a small annoyance where the savestate hotkeys would defocus the GS
window, causing them to not work after one use.

Revision 5910

gsdx ogl: new option for free driver
reduce_gl_requirement_for_free_driver => set it to 1 to only required a 3.0
context (you still required the good extensions)

Revision 5911

pcsx2: on going work to better support tlb miss
Currenty code isn't activated because it will crash any game that do a tlb miss
(with the recompiler)
However if you activate the code with the interpreter, the exception will be
fired and new tlb setting
will be loaded => got nice picture with "Bouken Jidai Katsugeki"
did you mean to put
if (bd) Console.Warning("branch delay!!")
inside the #ifdef? That's unrelated and useful for finding games that do it (like WRC)
if you want to enable the exception handling you need to toggle the #if 0 in vtlb.cpp:338.
the warning is useless ;) It would be printed in the main exception function
By the way is there a way to check that we are in the interpreter?
you could check if the Cpu pointer is pointing to recCpu or not, i guess that would work.
Thanks for the tip.

Revision 5912

Crashfix for a weird GIF_FLG_IMAGE2 situation in Wallace and Gromit Project Zoo.
Needs further investigation.
It's entirely possible that I'm wrong about that.

Revision 5913

linux compilation fix:
* use c++11 for pcsx2
* rename __rdtsc so I won't conflict with gnu version
* add a bunch of .data() method to get string data
MSVC 2010/2011/2013 build broken
error C3861: “__pcsx2__rdtsc”: Identifier not found
Thanks. Hoppefully next commit restore the correct behavior.

Revision 5914

pcsx2: fix window compilation + a couple of extra ;)
* Fix some issue with the new debugger on linux
* Enable the previous tlb miss fix on the interpreter
* disable the building of po by default. It pollute too much my env.
MSVC 2010/2011/2013 build ok

Revision 5915

-Implemented GIF_MODE Masking fixed the All Star Pro Wrestling series
-Standardize the IPU and SIF dma's to use the standard chain handling in hw.c,
fixed up some DMA resuming stuff in the forementioned units, VIF, GIF and SPR.
-Added some warnings for DMA stall control which isn't implemented, hopefully
somebody will find a game that does it so we can add/test it :)
Closes Issue 1435
FFXII PAL-FR Version broken in this revision (DMA problems)
Yep can confirm this on the NTSC Version as well:
*PCSX2*: DMA error: 10004000
Ok thanks guys, ill look in to it :)
fixed in r5917
A lot to test :p
And I think the Growlanser games (2 and 3) have their occasional intro freezes fixed! They work without the gamefix as well now. Still got one game to freeze in-game, another old bug that could be related to this.
Well thats something!

Revision 5916

[15:33] (Kingcom): it seems inline breaks gcc, as it can't extern a function
declared with inline
[15:34] (Kingcom): other functions in other units use it, and get linker errors
like this
:3 web editing :3
Web editing ftw :p gcc sux :p
Wouldn't calling an external inlined function be nonsensical anyway? Inline kinda suggests "private" to me.
It's okay if it's inlined but declared in a header file. That means anyone who uses it will get its own copy, and everyone else will ignore it.
Did you try the __fi, __ri macro.

Revision 5917

DMA: Fix for FFXII in r5915. Apparently it tries to use an invalid DMA mode, so
we shall assume they meant "chain" mode.

Revision 5918

These logs never helped solve issues and they tend to spam in some games.
Removing them.
They can cause problems though so it might be worth having a DMA_LOG or something for it

Revision 5919

Path3 Masking: Lower the Intermediate mode threshold for smaller packets, fixes
some small texture glitches on Path3 masking games such as Wallace & Gromit
This revision broke "Tomb Raider - Angel of Darkness".
The game jams after the intro-cinematic before the game-menu is displayed.
damnit, okay ill look in to it at some point, strange that it should kill it though, it's not doing anything scary
Cinematics-problem fixed in "1.2.1-567-g270fc13".

Revision 5920

Don't know how/why these changed in the DMA commit, but reverting to what it
should be.
(seriously, i don't remember changing this!)
And it's so random, too. :p
I know right? I know it was in the commit, but i don't physically remember making the changes to the cycle BIAS, but it was there, so i must have lol

Revision 5921

Initial work on getting further with PSX mode. Because the PSX rules!
All work done by Refraction, I'm just the commit guy for this.
Note: Missing Visual Studio 2012 / 2010 project files and Linux makefile
Note2: PSX games don't work yet :p
Oh and I know about 2003's disc recorder thing called 'PSX'.
Renaming consoles is invalid though, PS1 had the PSX name first! :p
Also to note all you'll get is the ps1 bios sound and that's your lot :p
Super! i was waiting for that!
What would this be used for? I'm not that familiar with the PS2.
Playing Playstation 1 games with the PS2's built in Playstation Emulator.
We will call it Emuception!
It was emulator? wasn't R3000 present inside ps2 and used directly to run something? or the game run on EE + software emulation?
the R3000 handles most of it, but the EE handles the GPU emulation
You could say it's 70% hardware, 30% software :)
I can't wait. What it would be :)
Are there any benefits over just running the games on a PS1 emu?
yes, PS1 emu's run games :P
I don t expect internal resolution enachment as on ps1 emu. See them running would be anyway a great achivement!
It probably will enhance the resolution just like PS1 emus do, but it will probably run slower as it's emulating the PS2 emulating the PS1, not direct emulation
Awesome Idea!
This emulator is so much better than the popular PSX emulators
ePSXe and PCSX-R doesn't allow changing any settings during gameplay and most graphics plugins are outdated and are super glitchy
pcsx2 getting PSX support is wonderful to me

Revision 5922

These files go with last commit.

Revision 5923

linux fix:
rename Gte.c into Gte.cpp need to be done on windows too
rename a duplicated function. Until we get a nice name for it.

Revision 5924

mirror, mirror

Revision 5925

Gte.cpp fix for VS2013.

Revision 5926

VS2010 project file changes.

Revision 5927

VS2012 project file changes. Took a bit of trickery since I don't have 2012
installed but I hope it works.

Revision 5928

linux: fix compilation issue with recent Mesa (gentoo)

Revision 5929

GSdx-ogl: GL4.1 program shader is optional

Revision 5930

gsdx-ogl: forget a pointer

Revision 5931

gsdx-ogl: one more
yes cool , but nvidia driver a detected buggy v335.23
And so what? You don't expect me to fix the nvidia driver, do you ;) That being said, maybe the nvidia bug is fixed but it impossible for me to test all GPU generations on 2 differents OS with various drivers version. So I just disabled geometry shader (GS) on nvidia. GS will be reenabled when code is more mature on GSdx.
You can probably safely enable the geometry shader on anything as new as 331.40. As I mentioned in r5769, nvidia appears to have fixed the bug on their end.
I'm not sure it is safe :P but I will try. Do you have any number of fps improvement? Because I'm not sure it is faster with it. GS is very costly on the GPU.
I'm in no position to do proper benchmarks at the moment.
Just quickly going through my savestates, DQ8 seems marginally slower, whilst everything is marginally faster.

Revision 5932

gsdx-ogl: sigh.. this one was hidden :p

Revision 5933

Created wiki page through web user interface.
That's cool, much easier to grab the src code, perfect timing too, setting up a sandboxed vc2010 ultimate sp1 right now.
However, how are we supposed to look at the latest list of changes like we do here?
Here on google code it lists each commit 1 by 1, were peeps can comment on them like I'm doing now.
If you guys move to git, how are we supposed to know what was changed and why?
I can see for example, this was changed 5hrs ago, but that doesn't help when I have to look through each folder for changes and all that...
I think it's great because I don't have to find a dl'er for the src code like I do for google code.
But otherwise I think it sucks because I can't keep track of the updates.
I like to check it once in a while, it's like checking the news or something.
On the github site, if you click on "##### commits" you get the commit log.
It points to: https://github.com/PCSX2/pcsx2/commits/master
Oh cool, that's exactly what I was looking for :D.
Cool beans.
Nice choice. I prefer Git as well.
Question: Does it mean we shouldn't watch anymore the logs here at all? Will at some point SVN repo be removed in favor of the Git repo?

Revision 5934

Created wiki page through web user interface.
Is there any transition plan for old bug reports here in code.google.com ? (e.g. reopen)
See this: https://github.com/PCSX2/pcsx2/issues/6

Revision 5935

Created wiki page through web user interface.

Revision 5936

Deleted wiki page PageName through web user interface.

Revision 5937

Created wiki page through web user interface.

Revision 5938

Testing OpenCL

Revision 5939

The opencl renderer is still missing a few features (texture cache, mipmapping,
aa1) and have visible bugs here and there, but it is mostly working now.
Probably the last commit here before moving to github.