PCSX2 Documentation/Google Code svn repository comments archive 4000 to 4499

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 4000

GregMiscellaneous: zzogl-pg: Windows compilation fixes.
Ha was right :p. 4000th by arcum.
congratulations on r4000...
r1 Florin May 10, 2006
r1000 refraction Apr 17, 2009
r1337 Jake.Stine Jun 06, 2009
r2000 Jake.Stine Oct 12, 2009
r3000 pcsx2guide in Mai 13, 2010
r4000 Arcum in Nov 06, 2010 (1000 commits in 177 days, ~5.60 commits/day... WOW!!!!)
Happy 4000 revisions!
Hopefully by the time you reach 6000 the emulator will become next to perfect.
Wjat.joi - if you look at the time between r1000 and r2000, you will have a very similar result for comits per day as with r3000 and r4000. Yes, on average the number of comits dayly is high, and it realy shows the dev's hard work and dedication to this project.
Thank you everyone!
Btw - what happened to cottonvibes,refraction, feal, gabest???
Looking forward to those guys making a big comeback, we hope.
Actually, I'm not sure there are real gains to inline the function. Because it is often use, keep it small to reduce cache pressure is maybe not wrong.
The one that can be inline is the draw function (only call once). Maybe a static declaration of the draw function would avoid linker issue.

Revision 4001

GregMiscellaneous: zzogl-pg: Have the Windows version use the Utilities version
of memcpy_amd like the Linux version does, and get rid of the redundant file...
Good! I think my modified one is faster anyway :p
Yeah, it probably is. I switched Linux to use it quite a while ago, and then ran into trouble when trying to switch it on the Windows side, and never quite got back to it until now. ^_^
Of course, I ran into no problems at all doing it this time, but I've de-tangled the headers somewhat since then, so that probably helped...

Revision 4002

GregMiscellaneous: zzogl-pg: Fix up NewRegs.cpp so it compiles again.

Revision 4003

newHostVM: Made use of the new SpatialArrayReserve for the EE/R5900 recompiler.
Reduces the recompiler's lookup tables from ~40mb to a mere 1-3mb.
I still need to fix up the reserved area for PS2 main memory; and after that this branch should be ready for re-integration. :)
I could also apply these techniques to the IOP recompiler; though its overall ram usage is already much less since it only has 2MB of main memory -- so instead of using ~80megs like the EErec did, it uses only about 7 megs. Not sure how little it would use with the SpatialArrayReserve - probably not less than 2MB still.
Memory usage is awesome :p
States are broken though. They give me a
"(pxActionEvent) VirtualProtect failed @ 0x10640000 -> 0x10714000 (mode=NoAccess)"
In other news, this branch fixes my machine's slowness issue when loading PCSX2 database. It loads in 200-300ms now instead of 1800ms. So whatever PCSX2 was doing before was causing my Win7 to have severe memory fragmentation issues. Odd.
Loading the database has been around 200ms for me for a while now and I'm using windows 7 64 bit. Lol just thought I'd add that :P
Comment by invisghost, Today (15 hours ago)
>> Loading the database has been around 200ms for me for a while now and I'm using windows 7 64 bit. Lol just thought I'd add that :P
Yes, I know. It loaded in 450ms on my ancient P4/1.7ghz laptop with 512mb of ram. It loaded in 190ms on my Linux Virtual Machine (the same machine that takes 1800ms to load it under native windows 7 x64!), and under 300ms on my old XP x32 install on the same machine.
The problem was specific to my machine only, and I had already determined it to be related to some sort of bottleneck in the memory allocation (malloc). It's happened ever since I first clean-installed Win7/x64 -- when all I had was Visual Studio and video drivers installed -- so its not even related to anything I've installed.
(I know all of this because cotton's original version of the game database took over 6 seconds to load on my machine, which rapidly drove me insane and forced me to spend several days troubleshooting, benchmarking, and writing replacement code until I at least got it down to a tolerable 2 seconds).
Lol well who knows, others might have had this and you fixed it for them. And as far as the revision is conserned, 40mb to 1-3mb is worth a pat on the back :) +1

Revision 4004

newHostVM: Fix for savestates!
so is the newhostvm done or you got more work to do on it?
Not done yet, but getting close though.

Revision 4005

GregMiscellaneous: zzogl-pg: Start gathering the hack code in one place.

Revision 4006

GregMiscellaneous: zzogl-pg: Use some of the routines in the Utilities library
instead of the copies in ZZOgl. (Which were basically older versions of the same
Note that Utilities is dependent on wxWidgets, and the header I pulled in pulls in wxWidgets headers now.
Also note that we now have _aligned_realloc, since we're using the aligned alloc routines from Utilities now...
And this broke the Windows side, which isn't too surprising. I'm fixing it up...

Revision 4007

GregMiscellaneous: zzogl-pg: Fix Windows compilation issues.

Revision 4008

GregMiscellaneous: zzogl-pg:
* Clean the mem swizzle interface
Great work Gregory, you, and the other pcsx2 members have done a heck of a job, keep up the great work.
@wtonberrios, I understand your enthusiasm towards pcsx2, dolphin, and other projects, however could you please stop blindly marking positive on every commit? It is truly annoying (at least to me), as it lowers the overall usefulness, and spirit of the rating feature.
Thanks again.
Is not a bot ?
I'm not too sure. The activities on other projects, like dolphin are not 100% of commits (at least not yet), so I think it is a real person.. at least I hope.
Yeah, his +1 patterns are erratic.
"Great work Gregory, you, and the other pcsx2 members have done a heck of a job, keep up the great work.
@wtonberrios, I understand your enthusiasm towards pcsx2, dolphin, and other projects, however could you please stop blindly marking positive on every commit? It is truly annoying (at least to me), as it lowers the overall usefulness, and spirit of the rating feature.
Thanks again."
Gracias pico554, pero como no hablo ingles, mi única forma de dar las gracias a este gran trabajo es dándole puntos positivos (para motivar el proyecto xD), y no soy un bot xD, sobre los votos, bueno, si es así, entonces no daré voto positivo hasta no encontrarle al trabajo realizado alguna utilidad, gracias por el comentario.
PD: alguien que sepa ingles, por favor , podría traducirlo para que los demás lo entiendan bien, muchas gracias (no lo traduzco por Google traductor, porque la ultima vez se entendió muy mal un comentario que di, y me querían golpear por eso xD... muchas gracias.)
wtonberrios, giving a positive to every revision is NOT motivating and NOT helping.
Sometimes bugs in a revision cannot be known right away because you always give everything a positive without knowing if a revision breaks something or not.
When that happens, you might make pcsx2's progress SLOWER because of your positives.
As pico554 have said, I also can appreciate your enthusiasm but it's NOT constructive.
I've investigated the odd slowness with ZZogl / windows issue a bit more.
Using the Destruction Derby naming screen (bunch of letters uploaded to the GS, I guess), I can see exactly 28FPS when starting the game for the first time.
When I restart emulation now, I get 90! FPS.
Now this time I also checked out the Linux side.
Here I don't get different FPS but instead I always get a solid 48FPS.
Since I doubt that the Windows version is 100% faster, I'm pretty sure now that Linux *always* has the (threading?) problem.
"wtonberrios, giving a positive to every revision is NOT motivating and NOT helping.
Sometimes bugs in a revision cannot be known right away because you always give everything a positive without knowing if a revision breaks something or not.
When that happens, you might make pcsx2's progress SLOWER because of your positives.
As pico554 have said, I also can appreciate your enthusiasm but it's NOT constructive."
OK, ok, ya entiendo, no lo volveré a hacer, lamento el problema.
@rama: That is strange behavior. We obviously want it running with 90 FPS all the time. ^_^
Tracking that down is going to be tricky. The initialization code's kind of a mess anyways. I should probably go back to trying to straighten out the code in GLWin32.cpp & GLWinX11.cpp and the code calling it again...
Of course, we should probably try to get this branch merged back into trunk again soon, too. We're back to the point where enough changes have been made here that I don't really feel like working on ZZOgl in trunk as opposed to here...
Yeah, agreed.
It's a bit pointless to hunt for 2-3% as well, when there's the potential
to fix a bug that kills 50% :p
Hum, yes the branch need to be merge first. There is already a lots of change. Moreover I do not have any time at the moment to code.
* maybe a global variable that is not properly set.
* On the past, I got a strange behavior on God of wars. The frame dropped to 30 fps instead of +60. The _resolve function was call a lots but with the size was 'flipping' something like that 516x448, 518x448, 516x448.... I do not remember if it was the height or the weight that was constant... The issue seem to have dissapear some revisions later. Anyway, I will not be surprised if it is texture caching related.
* If the testcase is short, maybe print all new created texture in CMemoryTargetMngr::GetMemoryTarget.

Revision 4009

GregMiscellaneous: zzogl-pg: Get rid of an extraneous function or two,
straighten up some includes, and move some things around to appropriate places.
Note that
a) Linux may or may not work on this commit. I'll straighten that up shortly.
b) ZZKeyboard.cpp is now a misnomer, since the actual keyboard handling code isn't in it any more. It is now pretty much just functions called by pushing function keys. I'll work out what to do about that later.
Putting the event handling code in with the window handling code is a better place for it, though.
Ok, looks like Linux still compiles. I thought it would, but any time I commit changes blind, there's always a chance, and I was doing this one in Windows.

Revision 4010

Bugfix for CDVDiso memory corruption, which caused random problems when loading
specific types of iso images (most commonly MDF types, but could have been a
problem on others as well).
Evil bug :p
good to see something not zzogl again. :)
Yeah, ZZOgl is spaming changelogs lately indeed...
I hope this change fixes strange bugs in double-layered ISOs... I mean GoW...
How cool. Great jorb, Jake. While I'm not in a position to check at the moment, I'm crossing fingers that this commit will (finally, at long last!) get GTA: Vice City working, and clear issue 564 once and for all.
Update: apparently this commit doesn't fix the Vice City bug. A shame since it's the only GTA game that still doesn't work. Ah well.
Nice work anyway, Jake - thanks for all you do.

Revision 4011

GregMiscellaneous: zzogl-pg: Rework CreateFillExtensionsMap to be less
depreciated (and so it writes the extension list to the log, but doesn't print
it except in debug mode). Fix a few minor potential bugs. Other minor changes.
I happened to notice that glGetString(GL_EXTENSIONS) is depreciated in OpenGL 3.1 or later. This is cleaner anyways.

Revision 4012

Fix/Bodge for Clock Tower 3 black screens. GT4 now boots again. Explanation for
bodge in the edit :) I am still alive here, just :P
Thank you, it does indeed fix gran turismo games and some others that weren't passing intros. There's still some other issues from the r3916 commit tho, killzone is a mess ingame, haven't really check many other games with new builds :p
GT4... that reminds me where's ferrarinews or what's his face?
Good work with the fixes, just tested ct3 and its working good so far^^
After all the constant and misplaced nagging from "ferrarinews" in the past - it would sure feel ironic if he actually doesn't take the chance of making an "on topic/revision" comment ;)
+1 for the fixes in any case Ref.
Refraction still with us !!!:) Yahoo !!! =D
(playing GT4 right now:)
Fix always +1. Good refraction!!!!
Shadowlady: Ill look in to killzone later :)
i suspect this is the issue.
if (!ret && vif1.irqoffset)
if vif1.irqoffset is 4 or 5, it means its done the tag, and that will screw things up if it tries running it again. so we need a condition in there like we use to have, probably vif1.irqoffset < 4 (going off the change involved)
Ugh, yeah. That code's a problem either way, iirc. (irqoffset==4) should probably be handled elsewhere, during the VIF tag processing loop, maybe. It really shouldn't be allowed to have any value other than 0,1,2, and 3. Any other value in that variable doesn't make sense, since it would mean that the QWC in question was finished anyway.
it's because it clears the "in process" tag, if that is clear it presumes it should be reading a tag, however sometimes they put an interrupt on the end of the tag to make it wait before the data, in our current scenario it will read the next tag and skip chunks of data or just bugger up royally, so we need to address that and ignore the break if it has finished, which will set it in "transfer the data" mode :P its a pain i know. i might have a think about it, but its tough as the tag doesnt always proceed the data (such as REF/END modes) so we cant just point the madr to the tag and let it run through :(
for now i think we should just stick in the vif1.irqoffset < 4 just to fix it for the moment. obv same in vif0.
oh gah i see what you mean, brain didnt compute the modal. ill look in to it, i have killzone so i can check it, theoretically, offset == 4 should never happen, maybe it is something else.. ill looksie :)
My theory on the 128 bit TTE should be wrong too. Harry Potter in particular seems to have some funky expectations on TTE, and I haven't had a chance yet to investigate further what its doing and what it expects to happen in return.
Specifically, we need to see if HP actually relies on the TTE being exactly 2 nops instead of the 4 nops that get sent with a 128-bit tag. Nothing else seems to depend on that -- but doesn't mean HP and Killzone aren't the exceptions that break the rule. >_<
Err, "should be wrong" is supposed to be "could be wrong" .. lol
im starting to doubt myself at this point :P i think my assumption was completely wrong, gonna have a look in to the changes anyway and see if i can narrow it down! i think you are correct with the TTE, being 2 words or 4 words shouldnt matter.
Think i may have just sussed it..
bool VIF0transfer(u32 *data, int size, bool TTE) {
VIF0dma hasnt been changed, so even on a tag TTE is 0 (false) so it modifies the madr/qwc, that could have quite a nasty impact. Ill implement your changes on that tonight :)
ok this made menu from medal of honor frontline graphic errors disappear and also clock tower 3 work
there you are ref, great comeback :)
Keep em comin!
wb refraction.
@Ref: I only applied the 4-word TTE to VIF1. All of the old 64-bit TTE code for VIF0 should be intact and unmodified. Feel free to implement though, if you want :)
I need to stop trying to work stuff out at work!

Revision 4013

-Fix for killzone.
-Did same code for VIF0 just to standardize things a little.
If this breaks anything let me know, and make sure it is this revision please.
Hmmm... fixed Killzone and Tekken 5 but broke Wild ARMs Alter Code F, keeps spamming this on boot:
sceGsSyncPath: DMA Ch.1 does not terminate
yay balls!! ill look in to that later if i can find a dump :S
I love Killzone ! This shooter has the best weapon animatin ever !=) And war atmosphere too :)
Just marking this with a minus so people know it broke stuff from looking at the list :P

Revision 4014

NewDMAC: Added a Fix for Dark Cloud 2 Text problems. Attached Fixme note.
Good start. This is indeed fixing DC2.
There's prolly a better fix though, the game shouldn't really send rubbish :p
Many games have rubish in the GIF TTE, as with my recent fix for GT4, if a transfer is in progress and it starts a new DMA packet with TTE enabled, 1QW of data which shouldnt have been there gets transferred. As GIF has no real commands, TTE shouldn't be usable on this channel, OR the GS should know to skip this data. on the VIF side, the only solution is to skip the first 64bits (vif is 32bit aligned anyway) and that fixes them problems
Okay, this also fixed a homebrew that used to crash before (GS mode selector).
Nice info, too :)
I had wondered, honestly, if GIF, etc all just ignored the TTE data and if VIF were the only interface to actually do any TTE handling at all. This because TTE really doesn't make any sense when applied to SPR or GIF or IPU.
This seems to be evidence that TTE should only be applied to VIF, and apparently only for 64 bits of the VIF at that -- that all other interfaces should just discard the TTE qwc.
Well SPR uses TTE, usually when grabbing the data in, it copies the whole tag in to the Scratchpad memory, then modifies the tag and throws it out to the MFIFO, i cant remember what games used it (i think tekken 4 was one of them) so it's needed there too. I've never seen IPU even try to use it i think.. but VIF and SPR definately do.
elaborating on the SPR thing, the tag it recieves is made up as follows
|....spr tag....|....vif tag...|
@ref: you mean SPR copies the whole 128 bit tag, right? Or just the 64 bits that are the tag itself (and not the upper 64 bits)?
the whole tag, it then modifies the spr tag in scratchpad memory to be usable for vif i believe. check the live trunk, hopefully that should show how it currently works with mfifo :)
Wow even i didn't make sense to me lol. check the code, all will become clear :)

Revision 4015

NewDMAC: Document some VIF related findings. Feel free to fix ;)
aimed at anyone in particular? :P
btw, any chance you could give some hints of games that hit your test code.
I should list some stuff I know is broken real quick:
* GIF logic is broken -- I have a partial fix coded but not ready for commit yet. Signal and Finish aren't handled properly and the GIF can get stuck in bad states (waiting for a PATH to finish when there's nothing there).
* FIFO handling is iffy. Doing a comprehensive FIFO check is cumbersome and slow, and I'm pretty sure we can get away with just flushing the FIOFs prior to several key events (reads/writes to certain regs, like GIF/VIF STAT and CTRL regs, etc). I should implement a comprehensive FIFO flush in the EE EventHandler though, for testing purposes, and then use the selective flush system as a default-enabled speedhack.
* TTE handling needs redone, since apparently its pretty dependent on each peripheral as to how the TTE is regarded. (GIF ignores, SPR transfers the whole thing, and VIF transfers only the upper 64 bits).
The alignment stuff is hit by Kingdom Hearts and Lego Star Wars.
The vif1Regs.num (partial transfer) is hit by many games.
Some work fine, some (like Fatal Frame) want it to stay in IDLE.
Some games do have alignment left over, due to the fact they are odd sized packets. for example if it is a V3-16, thats going to be 48 bits for each NUM, so a bit is ignored and skipped by our code, so that isnt an issue as far as im aware.
and yes many games do partial transfers, some use TTE to send a little bit of data (Killzone), others just like to spread it over multiple packets.
Fatal Frame may be using a bugged unpack then for this scene.
It was the only game that got fixed by staying at VPS_IDLE.
Star Ocean 3 is a notable game that does partial transfers all the time and it works just fine on newDMAC (out of all games this complex one works, lol).

Revision 4016

NewDMAC: A few tweaks to get it to compile in Linux.

Revision 4017

GregMiscellaneous: zzogl-pg: Work on the GLWin functions a bit.

Revision 4018

GregMiscellaneous: zzogl-pg: Quick fix to the last commit.

Revision 4019

Fixed the bug i made on my killzone commit, all games appear to work now that
were broken, sorry about that!
Tested a bunch of games, including the recently broken ones.
Everything seems to work fine :)
I think the cpu detection's somehow got a bit wonky.
My Core i5-520M shows up as '8 physical [4 logical]' (which is supposed to be '2 physical [4 logical]') in the core count.
Don't really mind if pcsx2 can really up my cpu's core count, though...physically at that. =b
Don't really know from which revision it started to be like that, but it does that on this one under a clean build.
A minor cosmetic error, though; not that important.
Just wanted to notify you guys nevertheless.
A better place for us to notice it would be by submitting an issue, not hijacking a commit. thanks.
The sample code provided from Intel to accurately count the number of cores and threads on an Intel CPU? A 100k C/asm file.
100k. I kid not. Nor any AMD support. (and its not always right for intels either).
I may remove the physical core count from pcsx2 entirely in the near future -- the ability to count physical cores on a CPU will only become more and more difficult. Bulldozer for example will have two different categories of 'physical' CPUs. And future designs will likely only make the matter worse.
(and yes, this should be a discussion on forums.pcsx2.net -- *not* here)

Revision 4020

newHostVM: (WIP, may not run!) -- Applied host virtual memory mapping to the
EE/IOP/VU main and on-chip memory banks. Added a new OO-based system allocator
object for handling said virtual memory resources. Plus many code cleanups, and
some added mess that needs to be cleaned up.
What do you know: It does not run! :p

Revision 4021

newHostVM: (Restored booting) -
* Added some bounds checking to debug builds for VTLB mappings.
* Fixed a VU mapping bug that caused boot crashing
* Fixed some startup, shutdown, and reset resource management.

Revision 4022

newHostVM: Cleanups, improved error messages.

Revision 4023

newHostVM: Some Linux compilation fixes, warning removals.
I tested, and was able to boot Atelier Iris 1 in this revision in Linux...

Revision 4024

newHostVM: Sync with trunk (r4010-4019)
Panl: I'm going to finish the VIF recompiled code cache conversion to the new system, implify a bit of code, and then this will be ready for merge!

Revision 4025

* Applied the new RecompiledCodeReserve to the VIF recompilers (saves another
4-8mb of memory, depending on game).
* Fixed a bug in pxsFmt / FastFormatUnicode (string formatting).
* Final round of error handling cleanups.
(branch is basically ready for re-integration -- needs some testin for
obvious/show stopping bugs, thanks!)
so its almost done?:D

Revision 4026

newHostVM: Linux fixes.
* Removed some missing / obsolete files from codeblocks projects.
* Fixed a segfault on exit
* Implemented a platform-consistent pointer value string formatter (%p has no
defined standard)
Seems all is fine now. Good job. :)

Revision 4027

Internal Iso: Only search for dual layer once.

Revision 4028

newHostVM: MSVC compilation fix.

Revision 4029

Merge newHostVM branch. Feature overview:
* PCSX2 uses significantly less memory when starting.
* Overall memory use reduced (mildly for some games, significantly for most).
* EE and IOP main memory are now fixed at 0x20000000 and 0x24000000 -- useful
when using external cheat apps.
* Properly implemented the 'Shutdown' menu option -- Shutdown now unloads the
entire PS2 virtual machine and reduced PCSX2's memory footprint to bare
* Some more meaningful errors for when memory is a problem (out of memory, low
virtual memory, etc).
* Bugfix for pxsFmt when formatting long/large strings (over 1k)
Perfecting PCSX2 a bit more :)
Great work! Nice to see it finally merged in, have the installs been built and updated on the server or are you waiting for something?
Good job :)
Nice work, indeed.
Too bad there is no one to "perfect" gfx-part of the emu :<
Another improvement to the world's favorire emulator.
Thanks !!!!!!!
I have a question. PS2 action replay codes start to fail in PCSX2 since a few versions ago. Is the reason this? Memory changed to somewhat different from actual PS2?
Awesome sauce ! Good work. Now waiting for the Newdmac merge >:D
Awsome work guys!
Now compiling and going to test it out. :)
Hum, I have some assertions failure on linux => LnxHostSys:172
I can trigger it when I load a state or shutdown pcsx2. It is on rev 4056 but probably related to this one.
Anyway, in the comment of functions MmapResetPtr it is said to remap as PROT_NONE but the code does not do it. Maybe you wanted to use MmapReservePtr instead of Mmap ? It still triggers the assertion with this change but I can at least ignore it and continue. Do not know about side effect.
Yes, its supposed to be MmapReservePtr. Try that and see if it fixes the problem.
Yes that works. The assertion still appears however. Actually I thinks the assertion is wrong, it miss a not. If I'm correct, result is expected to be base.
Is there any issue if the value are different ? Maps base pointer is only a hint so the return value could be different, there is no guarantee !
Yeah, the assertion is supposed to use ==, not !=. I end up doing that a lot when I write assertions, because I usually think in terms of what I don't want to happen, not what I want to happen. :p

Revision 4030

Repository management: Delete several old/obsolete branches.

Revision 4031

Repository maintenance: removed several obsolete and glitchy instances of
svn:mergeinfo (some generated by buggy versions of tortoisesvn over a year ago).
This should fix the sloppy merge diff logs when I do trunk syncs. :)
Wow you are really being fast now! I haven't played anything in a while, but I will be testing a few games and see what this newhostVM has to offer.
Thank you for your dedication to the project!

Revision 4032

Creating wxSavestates branch! Planned goals:
* Fix Unicode support for savestate filenames by using the wxWidgets internal
gzip interfaces.
* Turn savestates into 'proper' zip files that can be opened and extracted by
users using standard zip tools (allows for easy memory dumping of EE or IOP ram,
for examination or modification).
* Add screenshot to savestates for later use by a GUI savestate browser (which
will be implemented later)
I'm just curious as to how you will get screenshots to work for all the gfx plugins, whats your plan?

Revision 4033

wxSavestates branch: (WIP, does not compile yet)
* Preliminary implementation of wx-based zip support (using wxZipInputStream
and wxZipOutputStream).
Will old save stats be usable after?
What is the use of wx widgets?
No, savestate compat will be broken.
Use of wxWidgets is described in the commit log for the prev revision: https://code.google.com/p/pcsx2/source/detail?r=4032

Revision 4034

wxSavestates branch: still nothing to see here (yet)...

Revision 4035

- Standardized DMA Source chains, all DMA's now act exactly the same (within
reason) Explanation for this in Hw.cpp. Consequently this fixed a hack id done
for FFX videos (Not the one there is a game fix for)
- Slight tweak to Path3 masking, an overlooked situation where Path3 can wait
between GIFTags.
- Improved the stability of MFIFO on both sides greatly for games such at Tekken
Tag (which boots again) Gran Turismo 4 and FF7 Dirge of Cerberus.
I'm expecting *Something* to break, so please report it here if something does,
please make sure it is THIS revision.
The DMA changes are mainly for jake as he is doing a generic DMA interface, it might fix some of the issues if the changes are put across.
Hmm... tekken tag boots again but at least on r4040 it's still pretty unstable, arcade mode seems fine but practice or 1-on-1 freezes as soon as the load and chars load.
is that guarenteed? i realised it was still a bit unstable, but it was a random hang >.<. If 1-on-1 freezes everytime (details or chars/level would be cool :P) then i can probably fix that :)

Revision 4036

This is part of r4035, you just "Thought" you saw a new revision..
Check FF12 :p
goddamnit i checked that and it was working >.<
adding a negative for fun! even tho the negatives should have been on the last commit really :P
Fixed in r4037
You got everything fixed up nicely in the new rev.. Quite happy with it, and am glad my FF12 works again. :)
Fixed GhostHunter and both Ghosthunter and Primal don't need patches anymore. Great job :)

Revision 4037

Fixed monumental cockup from my big commit, it shows, product placement really
does work!! FFXII now works again, at normal speed.

Revision 4038

Take 3 and done *i hope!* comments for r4035-r4038 in here please!

Revision 4039

*Insert Profanity here*
Adding a positive simply for the log message alone hehe.. ;)

Revision 4040

Fixed bug in Vif Unpack Recompiler causing Guitar Hero 3 to crash on the
memorycard screen.
Actually id be suprised if this bug didn't break a lot of stuff
Ah, I always got a discolored "Memory Card" label in this spot.
Didn't crash for me but it sure looked broken.
Nice fix :)

Revision 4041

Game Database Editor not needed yet.
Is there anything that needs to be done on the config end by users when getting the gamedatabase to show names for games in the console? I can never get names to come up despite it saying in the console that it loaded up properly etc.
No, it should just work.
Since it's getting loaded correctly I really have no idea why it fails for you ><
Hmm. I have no idea either. All it ever says is unknown. I've tried fresh installs of pcsx2 and thats made no difference either. Tried many games.
Looks like it happens when you use the full boot option. With fast mode it shows the titles fine.

Revision 4042

New option to backup the old, existing savestate when creating a new one.
Hopefully not too buggy :p
This idea about backing up savestates is creative.
Sometimes I forget to switch savestate slot and I get mad because I accidentaly replace and old savestate which I wanted to keep just in case.
Thanks Rama.

Revision 4043

* Basic savestate loading/saving working now (needs testing).
* No support for screenshots embedded into the savestate (yet).
You are planing on ataching screenshots to savestates?
Interesting feature which I didn't even now I would want.
BTW, on an unrelated to this revision sidenote:
Would you guys care to check what's going on with Bloody Roar 4 (BR 4). The game hasn't been working properly in ages (I mean for over 1000+ revisions).
The problem is ingame I get a black-screen when the game goes to a loading screen and everything get's stuck and the fight doesn't start. This happens regardless of game mode (usualy arcade) and especialy happens when selecting or playing against Xion the Unborn.
Sorry if this is too much trouble. Thank you.
Bloody Roar 4 works absolutely fine for me. played a few rounds, quit out and tried a few other characters, no problem. Id suggest you have speedhacks on and it doesnt like them, or a gamefix which doesnt work with this game.

Revision 4044

Fix for what i hope is the last Tekken Tag bug i find! I'd actually already done
this on the VIF side due to another game, but didn't do this side. Fixes it tho
;p Happy smashing of each others faces in..
So I tried to play Bloody Roar 4 again. I am using rev 4041 and it is not working. The same - Now Loading, then black screen.
I disabled all the speedhacks, I don't have any gamefixes turned on.
I tried with Patches enabled and off, with Peops CDVD 0.9 and then with CDVD olio 0.1, GSDX 4031 and 3693.
Everything I tried produces the same black screen.
If it is not too much trouble could you please tell me your plugins and settings that you use for the game. I just can't get it to work myself.
Thank you!
Bloody Roar 4 NTSC-U (SLUS_207.95) works fine for me.
Also recent code changes are great, good work :)
Rom: Make an iso if it, then use linuz iso, dunno what else to suggest but it works perfectly for me.
Thanks both for answers, and I won't be asking anymore. Clearly something is wrong on my part.

Revision 4045

GregsMisc: Sync with trunk (r3983-r4044)
Given that a branch was merged with trunk recently, I thought I'd better sync before this branch got too out of date...
I'm also starting to wonder if we should have a separate "zzogl-dev" branch, rather then commit everything in Greg's branch.
Of course, this branch should be merged relatively soon anyways.

Revision 4046

GregsMisc: zzogl-pg: Rename ZZKick.{cpp,h} to ZZoglDrawing.{cpp,h}, to make
syncing with zzogl easier.
Zeydlitz went with ZZoglDrawing in zzogl when separating the Kick code out in zzogl, and I think it's probably a better name for the files...

Revision 4047

GregsMisc: Just a bit of cleanup.
And, yes, I'm tired of typing out "GregMiscellaneous". Or copying it, as the case may be. I'll refer to this branch as "GregsMisc" in the future.
And basically, the history of what revisions had been synced from trunk was missing some revisions. I think they were the revisions where this branch was synced with the trunk, in fact. This commit takes care of that, so that commands like "reintegrate" ought to work.
That's probably because I removed some of the info from them in trunk -- the info is obsolete (and for most of these it was buggy/wrong), and it causes the trunk syncs for all branches to modifies the props on all these files needlessly. I didn't think you guys were using tortoisesvn for this branch though, so didn't know it would affect you.
(or maybe I'm wrong and these things aren't tsvn specific?)
Come to think of it, those are all gone in trunk. I'm surprised the sync didn't just delete them in this branch as well.
And given that the info was affected by my merge commands on the command line with svn in Linux[1], it must not be specific to tortoise svn...
[1]In fact, I'm unable to test anything in Windows 7 on my main computer right now. I did some hardware upgrades, and haven't got Windows back up and running yet...
Meta data are not turtoise specific.
Anyway, I thinks the culprit is me ^^ I'am used to old svn versions that did not support meta data merge info.
1/ You need to commit the directory and not only files (or sub-dir) to also add the meta data, which I maybe forgot sometimes. (the reason that they are old stuff still present in the branch in my opinion)
2/ When I merge back the branch the first time, I did not use svn merge (only diff) because it was already messy which probably made things worst.
Well I did not expect so much work in my branch. Anyway better merge back when it is done and create another branch.
Note: I made some changes in spu2x in this branch. Add a class that is not provided by soundtouch library (it was only an example in the soundtouch tarball). It would be a good things to merge it back to the trunk also but it would need a test on windows (If I remenber there is no impact on that side), and also in linux codeblock.
Could have been partially me on that, too; I'm not that used to the mechanics of branches in svn.
I was thinking of just going ahead and merging the branch in (though I'm worried about mucking up the metadata again), and then creating either a zzogl-dev branch, or a gs-dev branch that we could do most of the experimental changes for zzogl-pg in. (I was thinking about having be gs instead of zzogl simply so that changes in GSNull or even GSdx could be done in it.)
That way this branch can go back to being your personal test branch, rather then continually being co-opted for zzogl-pg work. :)
Of course, I can't test compile spu2-x in this branch in Windows at the moment, to be sure that it works...
Also, I do agree that a zzogl-dev branch would be more appropriate. I think zzogl work will continue to be pretty heavy for some time.

Revision 4048

* Added code to detect amount of physical ram installed on the host computer.
* Added logging of host operating system and physical ram to startup.
* Removed "PhysicalCores" stuff from both x86emitter and startup logs --
physical cores is losing its relevance with all the new AMD and Intel chip
Looking good on Windows here:
Host Machine Init:
Operating System = Microsoft Windows 7 (build 7600), 64-bit
Physical RAM = 4094 MB
CPU name = Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
Vendor/Model = GenuineIntel - stepping=0A
CPU speed = 4.210 ghz (2 logical threads)
x86PType = Standard OEM
x86Flags = bfebfbff 0c08e3fd
x86EFlags = 20100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3.. SSE4.1
Once I added in the missing include, looks about right:
Operating System = Linux 2.6.36-gentoo-r2 i686
Physical RAM = 3019 MB
CPU name = Pentium(R) Dual-Core CPU E5500 @ 2.80GHz
Vendor/Model = GenuineIntel - stepping=0A
CPU speed = 2.797 ghz (2 logical threads)
x86PType = Standard OEM
x86Flags = bfebfbff 0c00e3bd
x86EFlags = 20100000
x86 Features Detected:
Operating System = Microsoft Windows 7 Ultimate Edition (build 7600), 64-bit
Physical RAM = 4093 MB
CPU name = Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
Vendor/Model = GenuineIntel - stepping=0B
CPU speed = 2.399 ghz (4 logical threads)
x86PType = Standard OEM
x86Flags = bfebfbff 0000e3bd
x86EFlags = 20100000
x86 Features Detected:
Host Machine Init:
Operating System = Microsoft Windows 7 Ultimate Edition (build 7600), 64-bit
Physical RAM = 4091 MB
CPU name = Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz
Vendor/Model = GenuineIntel - stepping=05
CPU speed = 2.869 ghz (8 logical threads)
x86PType = Standard OEM
x86Flags = bfebfbff 0098e3fd
x86EFlags = 28100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3.. SSE4.1.. SSE4.2

Revision 4049

Merge the changes in the GregsMisc branch back into trunk.
Let's see. I rearranged a bunch of stuff, and cleaned up a few things. Greg reworked the Kick code, and worked on the swizzle code. Greg fixed an issue occasionally causing spu2-x compilation issues. And I'm sure I've missed things, since it's been a while...
Oh, this fixed Linux compilation, too, since an include was forgotten in r4048 or so.
Time to try those changes =)
Compile error on Ubuntu 10.10 32bit:
[email protected]:~/pcsx2-read-only$ grep -i error -C 3 /tmp/build.log -C 3
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp: In function ‘bool LoadShadersFromDat()’:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:312: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp: In function ‘bool LoadShadersFromFX()’:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:326: error: ‘EFFECT_NAME’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:345: error: ‘EFFECT_DIR’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:323: warning: ignoring return value of ‘char* getcwd(char*, size_t)’, declared with attribute warn_unused_result
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp: In function ‘void ZZDestroy()’:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:791: warning: comparison between signed and unsigned integer expressions
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:799: warning: comparison between signed and unsigned integer expressions
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCreate.cpp:807: warning: comparison between signed and unsigned integer expressions
make[2]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/ZZoglCreate.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 52%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/MMI.cpp.o
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZZoglCRTC.cpp: In function ‘void AfterRendererAutoresetTargets()’:
[ 54%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/PluginManager.cpp.o
[ 54%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/PrecompiledHeader.cpp.o
[ 54%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/R3000A.cpp.o
make[1]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 54%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/R3000AInterpreter.cpp.o
[ 55%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/R3000AOpcodeTables.cpp.o
[ 97%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/Linux/LnxKeyCodes.cpp.o
Linking CXX executable ../bin/pcsx2
[ 97%] Built target pcsx2
make: *** [all] Error 2
Hmm... That's interesting. It compiled in codeblocks.
There were a lot of header changes. Did you do a clean build?
I checked out a fresh copy of the trunk, and am checking it, in any case.
Actually, I see it. It'll compile a Debug or Devel build, but not a Release build. I'll take care of it.
Cool, thanks =)
np. See r4051.

Revision 4050

Create a separate branch for experimental zzogl-pg changes.

Revision 4051

zzogl-pg: Fix a compilation error when not building a Release build.
"[100%] Built target pcsx2"
np. I usually test Devel builds, so it's easy for issues with the Release build to slip by...

Revision 4052

Fix for Sonic Mega Collection, amazing how missing one small little detail can
change things!
Good catch.
Fixes Die Hard Vendetta too, good job :)

Revision 4053

Took out the code i accidently put back in from testing

Revision 4054

Workaround for Ape Escape Million Monkey's. SIGNAL causes issues with Path1,
this should avoid it for now until someone has a better idea :P Explination
given in both XG_KICK's
OMG..i dont know which revision after 4031 did it but i think one of the last 3 revs made ghost hunter pass the hangup from loading screen...and its really playable.
it's great to see fixes like this that make a game work instead of the (useful i KNOW) other work that is done on the emu. Keep this way and congrats. ;)
Ghost Hunter playable again? Yay. That games not worked for ages.
yes...only problem i found after 1 hour gameplay is that i have slow framerates when playing as spectral(the flying lady)...its all because of the effects around her...it tuns like 15-25 fps when playing as her...but if i drop the scaling from 5x to 2x it works with 50-60 frames...when playing with the normal character i get 50-60 with 5 res..so i have to switch the scaling to 2x when playing as spectral
Ok I checked and the game does indeed work. Mine uses a compile from a few versions ago (r4034) and the game works back in that version. BETTER YET all the sps issues in the game are now fixed (a huge issue with the game in this emulator since the very beginning), the only issue remaining is more a plugin issue which is of the smoke effects not working. Rather than a smoke effect you see boxes popup.
But who cares the game frickin works which is awesome :). Great work guys.
yep thats a very little problem too the black boxes in smoke effects when you shoot
Refraction.... YOU RULEZZZ !!! =D

Revision 4055

Fix ADMA not getting read when in spdif bitstream mode (which some games offer
for FMVs).
This option would cause them to hang indefinitely.
There's something wrong with the read audio but at least it doesn't die ;)
Hmmm... reading at the same rate as normal audio works? I remember I could never get games to send more than a few spdif packets without dying :/
Maybe I wasn't trying the right games :P
It "works", yea.
The read rate must be wrong though as the audio is skipping a lot.
how much is it skipping? it might be going off 30fps on interlaced videos and it's freaking the time stretch out ;p how does it sound with timestretch off and pcsx2 fps limited?

Revision 4056

debian: * remove an useless patch (was properly fix with latest branch merge)

Revision 4057

Fixed a bug in partial DIRECT/HL transfers, Fixes Ape Escape hang going ingame.
I know it's nit-picking, but any particular reason not to simply put:
ret = (minSize & 3);
Or how about the fact that the if (partial_count == 4) block is unreachable? This code needs to be reviewed.
Agreed it needs looking at and fixing, priority when doing this last night was to get Ape Escape working, doesnt seem to have had any ill effects on Ico (dont know how..) but yeh, will look in to it at some point and fix it up.

Revision 4058

IPU: Gave IPU0/Internal IPU a sense of timing rather than the whole lot being
dumped out instantly then interrupted later, fixes issues with data being left
in the fifo (mana khemia) and the IPU outstripping the other dma's (FFX
Mess/Tearing on Digital Devil Saga videos). Will remove the hack later and clean
up once im totally happy its ok.
Note: This is technically still a hack, but it shouldnt break anything like the
existing hack does, also it's closer to how it should be than anything we've
done previous.
This fix is great for FFX and the DDS games indeed.
The tearing and onscreen garbage are gone now :)
I wonder why you removed the Mana Khemia hack though.
It's still needed.
Also, it's a pity but we've lost 15% speed.
Hopefully that can be restored though :p
I doubt it. This is one of the reasons the IPU hasn't been given proper timing up until now. And really to do the timing without it being 'hacky', expect 30-40% speed loss. Pretty much, a true IPU emulation has to be done at interpretation level. Accurate IPU emulation is not a good prognosis.
well at least for me all cutscenes take 9-10% less EE usage.
well if you want to put it in as a "speed hack" that it loses all its timing, be my guest, but for accurate emulation, this is how it's gonna work.
Also the DMA is independant of the command in progress now, so no, the hack for mana khemia shouldnt be needed, it will run indefinately until it is empty
The speed diff isn't big enough to justify a new hack, imo.
And I tested the Mana Khemia thing, it's needed :p
If you have the game, it does an IDEC for the background picture if you choose to go "off campus".
It hangs when the hack is not in place.
Ah yea, what I didn't test was actually putting it back in, lol.
It doesn't fix the problem anymore, simply prints "how??".
well i tested your Mana Khemia off campus hang and its because of the too low EE cyclerate.
With default EE speed it hangs but if i crank it up a notch it doesn't hang anymore. :)
Well what do you say..
This actually works on the x1.5 cycle rate setting.
Anyone got an idea why? :p
No idea, will look in to it, if you give me a dump :P
yes it works but don't forget i have modified my pcsx2 to overclock the EE instead of downclocking it (like the original speedhack does).
Does this work with the original speedhack also?
Yeah, it works by changing when events happen.
We need to see though why exactly it fixes the game and maybe learn something about the real IPU by that.

Revision 4059

host mem: fix wrong allocation method on linux

Revision 4060

Correct an assertion. and remove an unused variable.
arcum42 and gregory since you merged gregory misc. you haven't got anything to do.Do you? :D
Maybe they havent, or maybe they want a breather :P
If you don't know what to write in the commit message, try these: http://whatthecommit.com/ (try F5)
Oh, on my side, it is just have a lots of work to do for my client (I did some consulting jobs). And so my free time just disappears :( But do not worry, I enjoy PCSX2 games at the moment too :p
I've been fairly busy the last few weeks myself. I've added a new motherboard, processor, and hard drive to my system (including a reinstall of all os'es. Haven't gotten around to getting windows back working, but Linux was the priority. And it was easier for me to install then Windows 7.)
I've also been doing a bunch of cleaning on my apartment.
But the merge was more because we had a substantial amount of work done in that branch, and I didn't want the trunk to get too far out of sync. There's still plenty to do on zzogl, and I'm sure once I have more time, and I feel like coding, there'll be more commits.
And, of course, there are lots of things I could do that don't involve zzogl. That's just been my point of focus lately.
Everyone pretty busy right now, it seems :p

Revision 4061

DMA: Disallow MADR/QWC/TADR writes while the DMA is busy, solves the Mana Khemia
Does it mean we don't need to up the EE cycle rate anymore in order to go off campus?
I've recently started playing this game (thanks to arcum42) and faced this bug.
Bingo! that's exactly what this means :)
Well, if this is really the issue then you should write a mail to GUST.
Tell them you fixed their coding ;)
This was the first thing I tried on the newDMAC branch, and it did not fix most GUST games. -_- Atelier Iris and company actually start an IPU0 transfer, start an IPU1 transfer after, and then start another IPU0 transfer after that. And they most absolutely expect the *second* IPU0 transfer to receive *all* the data (which can only happen if the first IPU0 transfer is ignored).
As i said to pseudo, there is nothing stopping the first transfer from starting, there is no stall or dma disable in place to stop the first one from starting. The first and second DMA write the same data to the QWC and MADR, by which time 8qw has already gone through the IPU, causing a desync. This is the only logical solution i can come up with. Why it didnt work on the new dmac i dont know, but it works well here. I should probably ignore the STR = true from the 2nd dma as well.
Jake: Maybe it didnt work because the IPU on the new dmac isnt laid out like it is now?
Rama: From all the stupidity ive seen (writing to the QWC pad anyone?) i wouldnt be suprised if it is their idiotic coders.
Ok, I found why. I thought Rama had replaced the IPU0 hack for the upper QWC (dmaIPU0, lines 370-ish), with the Mana Khemia hack for IDEC in IPU.cpp.
So yea, GUST games are still broken in the 'well known' way. Ie, we're still just magically ignoring the first transfer for no good reason -- pseudonym and rama tested, and the PS2 most certainly doesn't ignore transfers simply because the upper 16 bits are non-zero.
So there's some other criteria allowing GUST games to work on PS2 hardware. We have no idea what that criteria is... yet.
The upper bits being set is a seperate issue, it doesnt happen in this scenario
best guess its "adding" 2 lots of qwc together.
Pseudo calculated that once.
It looks like GUST are writing less QWC for the off campus scene because the image format needs less bits than the usual buggy stuff.
Something about 16 vs 32bit, don't remember exactly :p
It most certainly processes it in 32bit IDEC mode, i checked that when i noticed it was out of sync, leaving 8qw at the end :P
but yeh the whole reason it was out of sync was this double dma.
Start IDEC
start ipudma0 with qwc for idec command
transfer the 8qw that is in the buffer to come out.
Start ipudma again with the full qwc amount, same as before
IDEC continues running
IDEC finishes
ipudma0 still expecting 8qw from IDEC (which came out during the first dma start)
game sits there polling the ipu0dma CHCR.STR for finish which never happens.
thats what causes the hang. Im very certain that the 2nd dma is never suppose to happen. DMA writes while the DMA is busy is not allowed by the system, im 100% convinced on a PS2, it would do exactly the same thing, ignore the 2nd setting of QWC + MADR and STR write.
Yes this is not an issue. Writes to anything besides STR most certainly should be ignored. This actually fixes SIF issues as well as others. I thought this change was related to the primary GUST game issue that affects almost all GUST games, due to someone in the dev channel saying "great, ref removed the hacka nd now all gust games will be broken."
But you didn't remove the hack, so nothing is broken.
i commented out the hack for mana, not the general gust one. that is an issue i still don't have an answer for.
If this is what this whole arguement has been about, then it has been a severe waste of time, as i never claimed to fix that problem :P
Hello, I just tried updating to the newest rev to find out FFX FMV are broke :(
I did track it down however to this rev(4061). in 4060 the FMV play fine. This happens with all default settings except for the FFX FMV game fix.
here is a snap: http://i51.tinypic.com/aac276.jpg
it gets pretty bad, it looks like it renders small squares at a time. like a web page loading pics half way. but the video is actualy playing smoothly, and sound is fine. just all these little squares while it is playing.
Let me know if there is any more info i can give that would help.
ah yeh thats a timing issue. its possible something is still getting ahead, i attempted to remove the need for the ffx hack, you should be fine with the hack on
Ah the EE timing hack for when all else fails. It certainly did the trick and with or without the FFX FMV game fix. Thanks!

Revision 4062

* Create a nice FORCE_TEXDESTROY_THRESH define
* do not call GetMemoryTarget twice in a row. There is already a check in the
core function.

Revision 4063

Internationalization fix-ups. PCSX2 0.9.7 should *finally* be ready for
translations. Whew.
* Also did some work on re-introducing the game database dialog.

Revision 4064

(internationalization) Added new i18n folder for housing translation files (PO
and POT files). This folder is outside the scope of the pcsx2 source tree

Revision 4065

Wiki: Preliminary draft work for several wiki pages --
* PCSX2 Translation guide! (including quick Poedit tutorial)
* Basic and advanced threading tips.
I can't easily preview wikis when editing them outside googlecode, so these may
very well be a mess. I'll straighten them up when I have time, unless someone
else beats me to it. ;)
interesting stuff, though I only skimmed it.

Revision 4066

Fix up Linux after the latest commits.

Revision 4067

zzogl-pg: Mess around a bit with FlushReGetTarget.
Yes, this hacks was usefull.
All right, if those hacks are useful, I'll leave them in. It just struck me that if we got rid of them, we could get rid of that function, and simplify things a bit.
Getting rid of the checks on whether ptextarg was NULL was mainly because in those particular instances, we already knew ptextarg was NULL, incidentally.

Revision 4068

i18n: fixes for po filenames (they didn't match the ones in the wiki)

Revision 4069

wiki: Link fixes, refinements, etc. relating to translation guide.
Can some kind person compile this version for me and pass the link.
Thx advance. (SSE2 32bit with all plugins)
Can some kind person please slap iren at the back of the head and then tell him to stop being lazy and go compile it himself.
Tried, but got errors.

Revision 4070

Avih (of Firefox plugin "Smoothwheel" fame ;) ) worked on bringing back that
extended GSdx information we lost in the merge to the new WX Gui.
Here's his changelog:
GSdx, PCSX2: Fixed broken GS info at the title bar
* If the plugin doesn't support the API, PCSX2 will display only the image mode
(progressive/interlaced field/frame), NON i18n!
* If the plugin does support the API, PCSX2 will not display the image mode, and
instead display the info from the plugin
* GSdx now properly sends title info: resolution, image mode, deinterlace mode
(weave - bff, etc)
* To enable the full GSdx title info as it used to work before it got broken:
uncomment //#define GSTITLEINFO_API_FORCE_VERBOSE at GS.h of GSdx.
NOTE: When using an older pcsx2.exe with newer GS plugin, the title would
contain duplicate image mode info. All other combos work fine.
* PCSX2 still displays the performance info, etc in the title bar.
Thanks a bunch for bringing this information back, Avih! :)
Really missed the frame size info :)
Can some kind person compile this version for me and pass the link.
Thx advance. (SSE2 32bit with all plugins)
Pretty sure we're not allowed to.
Anyway, read the compilation guide, it's not hard.
The interlace field/frame info is supposed to remain in pcsx2. There is no reason to have moved it into the GS plugin. I'll fix.
Oh, and buggy. I fix.
Tried to compile but have some damn errors...
Ah thats why I wasn`t getting the title info coming up.

Revision 4071

Minor fixes for the earlier GSdx titlebar feature.

Revision 4072

Plugin API for GS: Changed the new GSgetTitleInfo callback to use a more
sensible parameter passing system.
Hmmm... I just tried running older pcsx2 builds with GSdx r4072 and they crash pretty much as soon as stuff gets initialized.
Eh, yeah, that's going to be a problem.
We thought about compat one direction, but not the other. Crap. This is why I hate messing with the PS2E api.
GSgetTitleInfo needs to be renamed to GSgetTitleInfo2 or something to fix the crashing and restore backwards compat.
I haven't time to do it now, in case someone else wants to help.
Suggesting patch: http://pastebin.com/Yc9KYnPp
PCSX2, GSdx: Fix broken backward/forward compatibility regarding GSgetTitleInfo
* PCSX2: Added GSgetTileInfo2 and deprecated=removed GSgetTitleInfo
* GSdx: moved to the new GSgetTitleInfo2
* New PCSX2 with new GSdx will have the new functionality, all other combos remain with old functionality.

Revision 4073

PCSX2, GSdx (patch from avih): Fix broken backward/forward compatibility
regarding GSgetTitleInfo
* PCSX2: Added GSgetTileinfo2 and deprecated=removed GSgetTitleInfo
* GSdx: moved to the new GSgetTitleInfo2
* New PCSX2 with new GSdx will have the new functionality, all other combos
remain with old functionality.

Revision 4074

IPU hack removal - Well, still one bit i'm not sure on, but everything else
should be correct. Hack was due to differences between IPU and the MPEG
Will check if I can find a game that gets there.
Hmm, nothing :/
Many games hit this, but it probably wont fix a lot, if anything, but its 1 hack less and some logical function ;p
Oh, I meant the D_TYPE case.
The comment said you didn't have a game to test.
Well, me neither :p
yeh its very rare ;p might be when ipu is used to do some post processing, or used in games like klonoa (passes through ipu then vif), not sure tho ;p

Revision 4075

missed DMVector in last commit.

Revision 4076

* fixed a bug that caused certain confirmation dialogs to not remember their
choices, when user had non-english language.
* Added wxWidgets-provided strings for a few things, such as Next, Back, and OK
/ Apply / Cancel.
Good one. Strings get saved in English again :)
Just quickly mentioning this here (will post in forums later) but there's a problem in "Kingdom Hearts". Dunno what's causing it but in Alladin's world in the section in front of Alladin's home (where mushrooms randomly appear), every time I try to kill a certain healing heartless or use the blue trinity mark the game freezes up on me. The mark I can safely ignore but I have to kill all the heartless before I can use the keyhole in the wall up top (they keep following me up there forcing me to stay in battle mode. Serial ID is SCES-50967 and I'm using plugins from r3855 (GSDX) & r4072 (Everything else) - GSDX keeps failing to load on later ones (System: WIN7x64).

Revision 4077

Hack for Midway (Thanks guys!) games, as to show their muppetry in coding, i
have left big dev warnings everytime it hits their cockup. On a more serious
note, Solves the issue of a failing COP Condition they are trying to achieve.
Hrhr, nice find.
this is the best emulator software in my life thanks to pcsx2 team.
Well, this is funny :p
How do you suppose it worked on a PS2 btw?
Also: Got a few games that run into this? The 2 Midway related games I have don't :/
My guess is the PS2 handles fuck ups much better than the emulator does, so its better at ignoring the issue.
Failing that, it does by some freak chance handle it correctly in some way not mentioned in the manual.
so far i only know Mortal Kombat Deception runs in to it. At first i thought it might be the recs calculating it wrong, so i loaded the ELF in to PS2DIS, there it was, clear as day, write to 0x1000E100 lol
There is a common thing in life: "If smt works, leave it as it is."
Some coders, make their game. If it works on PS2 -> OK.
Thats what matters for them.
If smt seems really worng, it is better to ignore it (unless it is an INT)
Good you find one case!
nice work :)
too bad pcsx2 is advancing so much and gsdx is left behind...most of the games i have have gsdx problems instead of from the emulator itself
GSdx advancements would most likely mean ~70% speed drops (or more).
Would you want that? Thought as much.
GSdx is where it should be (in my opinion). But I do think that there should be another graphics plugin who's goal is to be as correct as possible. Just for the sake of being able to take screenshots and such. Idk, its just a thought.
As for the midway fix, good job ;) I hate how they can be act like: "It works! OMG it finally works! Idk why it works but it does!". On a side note, do you know if the games using the balders gate engine do something similar to the midway games? I know theres a problem with them (Champions of Norrath (1 & 2)) and the balders gate dark alliance games.
I've heard through the grape vine, that some developers are exploiting some publicly undocumented features of the system (be it PS2, PS3, etc.) to reduce the chance their games are pirated, especially via emulation.
pico: mildly true. Games such as Valkrie Profile 2 use an encryption their elf file. the calculations are pretty simple to generate the decryption key, however due to accuracy problems, getting it right on the PC requires a "hack" (which we have :P) to force the correct result for that calculation. Other than that, i dont know how true it is.
invisghost: im not sure why those games dont work, i've heard they use mipmapping which causes serious graphical problems like with the rachet and clank games.
This seems like unlikely behaviour for the hardware. Please test whether it works with just the cpuTestDMACInts(); (if so it's a hackfix, but a totally harmless one)
+1 to sudonim. We could be missing some call to cpuTestDMACInts() somewhere that DMAC statuses are modified, which would leave a dangling INT1 in pending status that should be raised regardless of whether E010/E100 is written.
well dmac_stat needed to be cleared, cos it does a COP0 check. it sets PCR bit 0x100, then does E100 bit 0x100 then does a SPR0 (convenient placement for where it is in DMAC_stat and PCR no?) but no other clearing of the interrupt register goes on, so it attempts to modify the dma registers while the SPR is running, due to the CPCOND0 passing, even though SPR0 is actually still busy.
i forget to mention, VIF gets cleared from DMAC_STAT just before this part of the code, so it isnt a bit clearing issue in our code.
you two have just posted something nothing to do with this post, hence your posts have been deleted (invisghost and bloodindark)

Revision 4078

Edited wiki page SupportedLanguagesChart -- removed some redundant languages.

Revision 4079

i18n: Remove some redundant/legacy wxWidgets language codes, in particular
regarding Traditional/Taiwan Chinese.
What is i18? A new branch or what?
i18n = internationalization (18 because i-18letters-n)
What do you mean internationalization? Translating it to other languages?

Revision 4080

i18n: more minor bugfixes to handling of Chinese dialects/sub-languages, and
some bug fixes to language enumeration and language settings ini stuff.

Revision 4081

Fixes for Ikusa, Kinetica and Need for Speed Underground, should all be working
again (or as good as before r3274)
This solves the DIRECT/HL code problem which needed reviewing anyway :P
Im expecting some of the Path3 masking games to whine, they can whine, im getting sick of it lol
i hope we get quadcore support as a christmas present -_0
Malice working again too.
Kinetica works again :) +1
refraction - your game fixes are kick-ass, keep going. ;)
thats my job :) other guys improve parts of the emulator, i get the games working :P
Hey refraction, just wanted to let you know of a bug introduced in r4061. I left a message there with the details. it is still there with r4085. otherwise great job!
and i've replied to you on there ;p

Revision 4082

* Fixed command line help display for non-english (invoked via --help)
* Startup/wizard now uses default operating system language when possible.
* Added a language 'Apply' button to the first time wizard, which applies new
translations immediately.
Pure version of compiler does not pass the problem?
Seems to get gcc a bit confused:
/usr/local/src/pcsx2/pcsx2/gui/AppInit.cpp: In member function ‘void Pcsx2App::WipeUserModeSettings()’:
/usr/local/src/pcsx2/pcsx2/gui/AppInit.cpp:73: error: call of overloaded ‘wxString(FastFormatUnicode&)’ is ambiguous
/usr/include/wx-2.8/wx/string.h:698: note: candidates are: wxString::wxString(const wxChar*)
/usr/include/wx-2.8/wx/string.h:692: note: wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.8/wx/string.h:690: note: wxString::wxString(const wxString&)
/usr/include/wx-2.8/wx/string.h:689: note: wxString::wxString(const wxStringBase&)
/usr/include/wx-2.8/wx/string.h:682: note: wxString::wxString(int) <near match>
Incidentally, substituting:
wxString groupname(wxEmptyString);
groupname += pxsFmt( L"CWD.%08x", hashres);
for line 73 of AppInit.cpp, which was:
wxString groupname( wxsFormat( L"CWD.%08x", hashres ) );
gets it to compile as a workaround, but doesn't look particularly nice...
"* Startup/wizard now uses default operating system language when possible."
I hope this is indeed based on OS language and not location.
Too often applications pick their default languages from the location and not the actual OS language, and it can be super annoying.

Revision 4083

microVU: Implemented indirect jump address caching (speedup)
Indirect jumps (JR/JALR) get a table which stores the previously jumped-to x86
code entry points, and this table is indexed by the jump-to PC address.
If current jump is jumping to a previously jumped-to address, the table will
have an entry-point, but before it is returned, the microProgram for which the
entry point belongs to must be validated to see if it matches the current
contents of VU memory.
The program validation check is remembered and doesn't need to be performed
again until after a micro memory clear (which happens when vif writes to vu
micro memory).
hmm been over 3 months since i last committed something D:
yeah welcome back:D
Gotta make up for that lost time cotton :O
sweet, I was actually genuinely surprised when I saw MicroVU
But it's what makes it all the better
perfect. in the lastmonth the compilation was very most importatly.
welcome back!!!!!!!!!!!!!!
wow things are looking good and since jake is focusing on the languages this time you guys must be getting close to another official release
Someone could do a speed comparison? Or is not worth it?
Wellcome back cotton!
mailszero: in the GoW titlescreen theres a 1.5% overall speedup (~64fps to ~65fps).
For a lot of simple games there probably won't be much of a difference, but i think there will be some games that have a bigger speedup (i want to see if this helps with scarface's problem).
I also want to know if this fixes the slowdowns some people report happens with the mVU block speedhack.
ok rama said theres a 0~5% speedup in this commit; and it doesn't fix the mVU block speedhack slowdown that happens in some games like ffx (i'm still not sure whats causes this then)

Revision 4084

Wiki: Cleaned up the ChrootAnd64bStatusLinux wiki page for readability. (Still
needs work)
It is in much better shape now. Thanks.
No problem. I've always been pretty good at reading over and fixing up documents, I just tend to forget that the wiki entries are there...
Of course, I really should grab a few more chroot guide links, and put them in there. Especially for Gentoo, since I use Gentoo. ^_^

Revision 4085

GCC compilation fix.

Revision 4086

zzogl-pg: Fix compilation in Debug mode.

Revision 4087

microVU: minor changes
- Added mVUcacheInitReserve and mVUcacheMaxReserve constant values for now which
can be tinkered with until we implement runtime user-modifiable cache reserve-
- Improved the "microVU - cached program" printouts on dev builds.
- Fixed the typos in SysOutOfMemory_EmergencyResponse()

Revision 4088

Minor i18n-related bugfixes.
* "Browse" option in recent iso menu should translate now.
* Dialogs and config panels remember their positions more reliably (when using
X or alt-F4 to close PCSX2, for example).
* Preliminary language selector dialog (available in debug builds only). Will
finish it up later.
My "recent iso" list keeps getting deleted, I think it's from this build but I can't be certain.
in this build the recent iso list gets cleared every time you start pcsx2

Revision 4089

zerospu2: Use local copy of wavfile like spu2x

Revision 4090

* Bugfix for Recent Iso List (it stopped remembering stuff a couple revs ago).
* Doing some configuration panel additions and cleanups (UI/theme-related) --
I'm not sure this commit succeeded properly... I got some odd error when it finished. Verifying..
Hmm, seems fine. Whatever, then. :p
arcum/gregory: I didn't add the new resource to the cbp or cmakelists. I'm on an XP install and its not set up to be able to search the contents of files properly (stupid XP), so I'm having trouble finding which cmakelists.txt to modify.
Use this registry to search the contents for all file types under Windows XP, typically for finding out specific text within source codes.
Windows Registry Editor Version 5.00
ok I will update cmake this evening. FYI the cmake file is located at the root.
Speaking of that, it should be possible for cmake to do dependency checks on the .png files, so that it only compiles them if the dependency has changed. That would speed up rebuilding of minor cpp tweaks by quite a bit.
Hum, actually it is not an easy task. Cmake only generates makefile, it is Make that check the timestamps. It would be very easy (less than 10 lines) to create a manual makefile to do the jobs but it will not be portable (actually I'm not sure the current method is portable).
I think it does not impact too much file so the gain will be small (at least on 4c cpu), link time is actually slower.
I maybe found something. I need to do some test.

Revision 4091

wxSavestates branch: (partially sync'd with trunk**)
* Finished up zipfile-style savestate implementation
* Simplified BaseSaveState class, and removed lots of now-unneeded code.
* Prepared the i18n stuff for a pcsx2_Dev.pot file (WIP), and sorted more stuff
to pcsx2_Tertiary.pot.
** Doing merge and modifications at the same time is a bad idea, but my limited internet connectivity forced my hand a bit. Ah well.
I have one more thing to do on this branch -- change the filename scheme for the new savestates -- and then it'll be ready for final testing and re-integration. :)

Revision 4092

wxSavestates: savestates now include game serial code, and a ps2z extension
(which can be linked to any zip-supporting tool, like winzip or 7zip). This
branch is ready for extensive testing. :)
- Will it break compatibility with previous state files?
- Isn't the CRC at the file name enough?
- Am I correct to assume it will mostly be useful on systems without filesystem-level compression?
- Yeah, it'll so break older states :p
- The SLUS number is better to find your game than a random CRC.
- Savestates definitely need to be compressed. Otherwise we'd be looking at like 40MB per state.
Filesystem-level compression would do a worse job than zip and more importantly: It's not available on all OS's and file systems.
Also: this branch doesn't yet compile:
fatal error C1083: Cannot open include file: 'pxForwardDefs.h': No such file or directory
slus is very useful to found which game create the crc. Only need to check the DVD box, unfortunately I'm not able to compute CRC in my head :p
Note: on linux it needs some skill to enable the compression so automatic compression is very interesting.
> - Am I correct to assume it will mostly be useful on systems without filesystem-level compression?
PCSX2 states have been zip-compressed since forever. I'm just making them proper zip *archives* with embedded screenshot and easily separatable memory dumps.

Revision 4093

cmake: Add ressource file

Revision 4094

wxSavestates: add missing file.

Revision 4095

cmake: rework the resource stuff. Avoid rebuild and files are clear by cmake.

Revision 4096

wxSavestates: many bugfixes!! *now* it's ready for testing. :p

Revision 4097

wxSavestates: Fixed Bios CRC calculations and improved robustness against
saving multiple states at once (hackfix). Console title still doesn't display
the BIOS label properly ... not sure yet the good way to remedy that one.
Can I make a suggestion? Instead of having many savestates in the menu from the start, why not just detect the number of saves and auto generate the options from there with a "New Savestate" option at the top of the save menu.
Another suggestion would be to allow special naming (the label that appears on the menu & related) of each savestate.

Revision 4098

wxSavestates: BIOs boot/running status is now correctly displayed in the console
I'm away from home and can't test this on my linux box. Is it compiling, running, and working reasonably well?
Doesn't compile in debug here, the others prolly won't work either.
static void LoadBiosVersion( pxInputStream& fp, u32& version, wxString& description, wxString& zoneStr=wxString() )
/home/a/pcsx2/wxSavestates/pcsx2/ps2/BiosTools.cpp|67|error: default argument for ‘wxString& zoneStr’ has type ‘wxString’|
Removing the & from "wxString& zoneStr" fixes it and works on Windows as well.
Not sure if that's correct though :p
Nope, Not correct. I wasn't sure if that would work in GCC or not, which is why I needed it tested. I'll need to make an overloaded function for it. Annoying C++ standard crap. :(
Other than that I didn't see any issue.
Also the states seem to load a bit quicker in this branch.
Nice bonus :)
Thanks; I was planning on checking Friday or Saturday, but wasn't really going to have a chance till then...
Would be nice to beable to disable compression support for this if you can't already.
I'de rather use un-compressed states myself.
I like the idea of seeing the console name for the game in the titlebar, would be nice to see the slus id too.
The console name isn't always 100% valid though..., most of the time it's correct but I have a game or 2 that is way off on the title, I can't remember off hand which.
I can allways check back later and check to see if anyone here is interested in what games though and post the info.
Update..., might be nicer just to use the iso command line name for the title bar name.

Revision 4099

GSDx: Disable MSAA if all checks failed. Also, prefer normal 32 bit depth to
lockable 32 bit depth on D3D9. I was anticipating a use for locking but further
examination of the code revealed that to be impractical.
Another good revision,man. :D
Gsdx has issues with 4x res modes.
Seems slightly sluggish in most cases (even if you are getting more then 60fps).
Also GT3, I don't know the slus id yet, it's a us ntsc disk though, crashes when you start a race in 4x mode, but is fine in 2x mode.
Also would like to see 8x mode, current limit is 6x mode and the plugin freaks when you manually set it past that point.
Just wanted the dev's to know this... :)
Filtered modes..., point, biliener and trilinear modes would be good along side what is already there.
It's probably bilinear by default, I don't know.
Sorry for the offtopic stuff guys.
It is offtopic, and an 8x mode will not even be remotely useful until video cards with 4gb of video ram and approx 400gb/s memory bandwidth are on the market. your 4x mode is sluggish because its pressuring video memory and maxing out memory bandwidth. 8x mode would require FOUR TIMES as much memory and bandwidth.
The reason your fps remains around 60 is because of how most modern (6th generation) emulators work: many games run at 30 fps and/or using double-buffering internally; and that means that from PCSX2's perspective one frame renders really slowly and the next frame is just a fast copy/flip. PCSX2 tries to mitigate these scenarios, but when your GPU is being bogged down with an enormous workload, you're going to get studders and hiccups.
Your FPS remains at 60 because PCSX2 makes up for the slowness of the first frame by "rushing through" the next frame.
8x is not only unreasonable atm, it also tries to exceed d3d texture size limits. Forget about it until future notice, I do have something brewing but I have no idea when it'll be ready.
Bilinear and trilinear are both GS features, but we don't have mipmap emulation currently so we only do bilinear.
You'll also be hard pressed finding a quality difference between 4x and 8x.
A much more useful thing would be working AA.
It currently suffers from the same problem though: Massive resource usage.
Edit: (if mods see the del post above, read this one, tried to fix a few typos)
The reason I was thinking 4x.
1 2 3
4 x 5
6 7 8
Like aa, the internal res sort of acts like it in terms of accuracy.
The higher the res, the more accurate 2d seems to me.
And the nice the 3d gets.
I haven't tried forcing aa for the ps2 emu yet, but I can run 8x-16x aa on all the latest pc games so far (excluding mafia 2, it's physic's are to much for my card on max, 40% of the time).
1080p, aa and max details, with my new gtx 460 se, x6 cpu.
Optimization and the overall performance of things has improved drasticaly over the year.
Especially with the later public beta of pcsx2.
Most ps2 games run good enough at a measly 3.5ghz now, that's not even 4ghz or higher :D.
4x compared to 2x is like comparing near 1080p like quality to that of close to actual 480p res (should be high be most games don't much look it).
And since all the games have seem to run fine at 4x, I figuered why not 8x.
Games like boddy roar 3, and capcom vs snk I'm sure could probably run at 8x modes with no speed probs on modern like setups.
And who knows, perhaps tekken5 (along with most games) would too, I would of tried it anyways.
With the currect accuracy of the pixal upscaling in the ps2 emu, it allways screws up in some direction or another.
I figuered 8x might alieve that just a little.
And bring that polygon res up to the point where you call it as good as it's gonna get.
That was just what I was thinking anyways.
4x res is pretty good though.
I was surprised that all my games actually ran that good on it.
I was more or less expecting to top out 2x res on performance, not 4x when I got the card.
I only ran 4x previously on br3 and cvs.
At 4x, surprising enough xenosaga 1's slowest area's run so freaking close to 60fps, again at 3.5ghz and the card isn't even overclocked.
Xenosaga 3's slowest part, run's above 60fps at 4x, no more speed issues with it's smoke effect anymore in the realtime scene where kosmos vs omega.
Which reminds me, have you guys noticed the odd glow like effect or whatever it is the ps2 authero's where trying to do with tekken 5 and xenosaga 3?
In that scene where kosmos vs omega, and in the battle map in tekken 5, where it has a field of flowers.
It has 2-3 lower res wwhole screens on top of the normal res screeen, offset a few pixals.
Looks horrible because it doesn't filter or blend in anyway.
And in tekken 5, causes pixal corruption of the upper left corner for 1/16th of the screen maybe.
I was curious as to what your guys opinion's where on this.
As for the slight sluggishness onf 4x mode that I was talking about originally.
It seemed to me to be more or less a tiny timing prob of some sorts in the ps2 emu.
Been noticing some tiny timings probs here and there in diff games before when in 2x mode.
I can't remember exactly where, I'de have to play all my games to try to figuer out where again.
That and with gran turisomo 3 crashing when in 4x mode, I figuered something must of been wrong with the mode compared to that of 2x mode.
But what you mentioned about double buffering makes some sence.
I'm not sure if I know how to force tripple buffering or not in my driver in d3d modes, which may help I don't know.
Thanks for taking the time to respond though you guys :)
Still missed a few typos lol but now it at least shouldn't be misunderstood.
^^, darn google code needs an edit button.

Revision 4100

w32pthreads: maintenance work; applied patches inspired by the VLC guys that
make the code a little more sensible where pointer types are concerned. Removed
some obsolete ancient compiler crap regarding interlocked exchanges.

Revision 4101

wxSavestates: fix for GCC compilation error.
I did a certain minimal amount of testing. (Compiling, saving a few savestates, then loading between them) and it seems to work fine in Linux.

Revision 4102

Fixing some stuff on the GSDumpGUI (more update to come) to allow me to test
decently Gsdx while waiting for DirectX SDK to complete download
1) Change log to "log.txt"
2) Fix a crash when an invalid directory is specified in the textbox.
3) Fix working folder for loading library. Now it searches for dependencies in
the same folder as the plugin dll.
4) Fix configuration save/loading

Revision 4103

Added some more verbose logs to GSDumpGUI (I'll start now to make a native
loader for the dumps file inside the app)

Revision 4105

Clearing up everything was using the old replay code.

Revision 4106

Started working on the debugger. Prepared only the link between master and
client app. Have to investigate on the changes in the PATH1 done by Jake.
So, is it going to be a remote debugging feature?.. Like actual debug info could be sent to developers right from the PCSX2 itself?..

Revision 4108

Little fixes.

Revision 4109

Added some statistics to better identify the type of dump you are using.
Fixed some code to be coherent with actual pcsx2 state. (Still need to talk to
Jake to understand the new changes)
fear the feal cauze he'z on firah! :P
All I did was add a new gsGifTransfer(), that works JUST like GifTransfer3 (completely hack-free). You should retain support for GifTransfer1,2, and 3 as they have always been. Only need to add a new gsGifTransfer() support that works just like gsGifTransfer3.
Internally GSdxuses index #3 for the new transfer. As such:
gsGifTransfer1 = case 0
gsGifTransfer2 = case 1
gsGifTransfer3 = case 2
gsGifTransfer = case 4
I did it that way because I felt it would be the simplest method for retaining compat and for upgrading dependent code.
To clarify, case 3 should behave identically to case 2. I think cases 1 and 2 also behave the same. Only case 0 is the weird hacky one, and is the one that new pcsx2 dumps won't use. Old dumps will, though.
Things does not return then. I saw your code (MTGS) and managed to understand even before that
gsGifTransfer1 = not in use old
gsGifTransfer2 = path2
gsGifTransfer3 = path3
gsGifTransfer = path1 new
but the content of the dump seems incomplete somehow as rama1 maked me see from his screenshots.
Just like this...(same for the bios)
What I do is a simple fake GIF atm
Manage all GIF Packets as follow
if Transfer use correct function
if VSync call VSync(parameter)
if ReadFiFO2 call the function and deposit the result in a fictional array (not that many games use this one anyway)
if Registers update all the registers
Loop till the end
I'll have more to investigate on the dump generation...(cause the old dumps all works perfectly fine atm so i doubt its about reading the dump (i redirected old path1 to the new function))
You only have case 0,1, and 2 for transfer handlers!!
Add a case 3. that will fix it. (I would but I'm not at home and don't have C#stuff installed on my laptop)
Nope there are 3 of them Jake...I added in this release the third one when i realized of the new path.
I mean, there are all four in this revision 0,1,2,3
Try watching from row 197 to row 250.
That was the only significant change I made.
A less significant change: new PCSX2 versions no longer sends register writes to the GS via ringbuffer. PCSX2 uploads the registers the GS plugin's copy of register memory just prior to issuing a vsync. This shouldn't make a difference for dumping, though. Dumps start and end on vsyncs, and vsync is the only time GS plugins reference the registers in any meaningful way; so I'm not seeing a cause for breakage there.

Revision 4110

GSDx: fixed incorrect use of CComPtr that would leave a dangling reference in
the settings dialog code (only affects old pcsx2 versions and wouldn't be a
significant resource leak even there)
Eh, not a dangling reference. Whatever you'd call it.

Revision 4111

Little change to the function called. (Shouldn't do any kind of difference)

Revision 4112

Modified a little the code to be more modular. Should not change the behaviour.

Revision 4113

* increase a little the hack window (better for screenshot, not too big for
small screen)
* Use generic clut function in FlushDecodeClut
* Various clean and comment

Revision 4114

Small fix to logging.

Revision 4115

1) Resolved the problem with the GSFreeze. Now the states are loaded and
reproduced correctly.
2) Put an error message when trying to load old savestates not compatible.
3) Added a clone function for dump. (may be useful later on)

Revision 4116

Reactivated the overrides modifying manually directly the inis. Now the app
should be stable enough to allow base testing. I can now restart working on the

Revision 4117

Little fix to focus. Forgot to commit this one.

Revision 4118

Adapted the de-alias and frequency response filters from nenolod's "UPSE", a
high quality PSF player.
These 2 filters are present on the real SPU(2) as well and are meant to increase
the audio quality
by fixing aliasing and then equalizing the final result.
It currently mostly seems to accentuate the presence and highs.
Thanks a ton for hinting at this and for letting us adapt your code for SPU2-X,
nenolod! :)
PS: If you see glaring bugs, feel free to keep them :)

Revision 4119

1) Fixed crash when no ini was created, but an override is attempted.
2) Started writting the debug mode. (a little gif browser grouped by VSync is

Revision 4120

Forgot a little fix.

Revision 4121

Implemented basic Step and RunTo functionality in the debug mode. Still very
simple and probably bugged/incomplete. Just need to make some story in the svn,
before doing some new big work. :D

Revision 4122

spu2-x: compilation fix; pcsx2: fix the codeblock project; zzogl-pg: Add some
comments and debugging code.
For consistency, it might be better to protect all new debug code with #ifdef SPAM_UNUSED_REGISTERS (fog, dthe, colclamp). Could also avoid a small speed impact too on debug build without optimization.
Thanks :p
@greg: I might later. I mainly wanted to make sure I had the comment in so I'd recall later what wasn't implemented...
@rama: np.

Revision 4123

Experimental Step VSync support to debug intraframe.

Revision 4124

As Pseudonym suggested, now when stepping or running to it start from the
beginning of the dump.

Revision 4125

Forgot to reset the registers. My bad.

Revision 4126

On Rama request :
1) Implemented 2 new operations (Go To Start and Go To Next VSync)
2) Autoselect the client when started up
3) Fix little bug when trying to run to the packet 0.
I bet these new debug-functions might be very good for further work on pcsx2, so i will give a thumbs up for that - without meaning to get all "spammy'" :)

Revision 4127

Forgot little thing. :(

Revision 4128

Thanks Rama for the debug.

Revision 4129

Really fix last bug :p

Revision 4130

wxSavestates branch: sync with trunk, preparing for re-integration.

Revision 4131

wxSavestates: mergeinfo error...

Revision 4132

Integrated new wxSavestates. Features:
* Savestates are now 'proper' zip archives, which can be opened by any zip tool
such as 7zip or winrar. PS2 virtual machine memory components are stored as
individual files (such as eemem.bin, iopmem.bin, etc), and can be extracted,
modified, and re-packed easily (maybe fun for hacking!)
* Savestate filenames are now based on a combination of serial code and CRC,
ex: SLUS-12345_(0D386A2).00.p2s
* Savestates made during the BIOS will have meaningful CRC codes now, instead
of 0000000.
* Minor improvements to error handling.
* Better support for unicode and internationalized windows installs.
* Prep work for eventual screenshots embedded into savestates (WIP)
* Changed i18n macros around a bit to help differentiate out some of the lesser
needed translation items. gettext po/pot file updates will be forthcoming.
Cleaner and better, thanks Jake.
Nice work! There are some issues in Linux. If using gcc 4.5.2 compilations dies but if using gcc 4.4.5 everything compiles. The problem is:
[ 55%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/gui/SysState.cpp.o
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/gui/SysState.cpp: In member function 'virtual void MemorySavestateEntry::FreezeIn(pxInputStream&) const':
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/gui/SysState.cpp:100: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/gui/SysState.cpp: In member function 'virtual void SysExecEvent_UnzipFromDisk::InvokeEvent()':
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/gui/SysState.cpp:584: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
[ 58%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/ps2/BiosTools.cpp.o
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp: In function 'void LoadExtraRom(const wxChar*, u8 (&)[_size]) [with unsigned int _size = 262144u]':
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:271: instantiated from here
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:219: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp: In function 'void LoadExtraRom(const wxChar*, u8 (&)[_size]) [with unsigned int _size = 524288u]':
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:272: instantiated from here
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:219: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp: In function 'void LoadExtraRom(const wxChar*, u8 (&)[_size]) [with unsigned int _size = 1835008u]':
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:273: instantiated from here
/tmp/buildd/pcsx2-unstable-0.9.7~svn4153/pcsx2/ps2/BiosTools.cpp:219: warning: cannot pass objects of non-POD type 'class wxString' through '...'; call will abort at runtime
Seems that gcc 4.4.5 will let the program choke in execution while gcc 4.5.2 chokes in compilation.

Revision 4133

While waiting for understanding better how to make Gsdx more sane...
1) Added some basic GIF parser to detect some basic information about the
packets. (Still no registers, had little time. :P)
2) Little fixes to allow better navigation.

Revision 4134

Possibly fixed the problem of gsdx not rendering correctly when stepping into.

Revision 4135

Little temporary fix for the gif parser. More work to do later on

Revision 4136

Little fixes. Time to read some manual...

Revision 4138

Added Register detection. (Now missing "last" step to decode the real data
passed to each register based on the modes)

Revision 4139

Various changes to avoid using deprecated Gtk+ code. Gtk+ 3.0 is slated to
remove most of the currently deprecated calls...
I left defines in to error out on deprecated code, so that I don't accidentally add more in.
The big ones are that you are now required to use accessor functions instead of object members in a number of cases, and that all the defines for GDK keys were redone, so we have to make sure a compatibility include is brought in.
The GDK_DISPLAY call I changed is in code that isn't called at the moment anyways. It would only get called if we were using GSOpen2 on Linux.

Revision 4140

zzogl-pg: compilation fixex for MSVC builds:
* resolve a namespace conflict between std::count (due to a 'using namespatce
std;' directive) [debug builds only]
* switch all MSW-specific code to be unicode compliant so that unicode-only
Utilities lib can be used under Windows. [should work, but needs proper
* fix some properties sheets so that windows-specific DLL dependencies (common
controls and UUID stuff provided by Windows) are linked automatically into
wx/utils based plugins.

Revision 4141

Started doing Register detection for the packets. (Still missing A+D and FOG)
Happy Christmas to everyone. ;)
happy christmas for ya too.
Merry Christmas to all. :D
Merry christmas

Revision 4142

Cleared up a bit the code and added the FOG handler.

Revision 4143

Other clearing up and TEX0 implemented.

Revision 4144

Removed useless IF. TEX0 is always plain format.

Revision 4146

Forgot a little thing

Revision 4147

GSDumpGUI: Did a bunch of stuff I don't even remember. Disclaimer: I don't know
I know C# pretty well. And this code is a mess. :-/
First of all, get a JetBrains ReSharper. Seriously. It's a trial for 30 days and you can get a free license for free open source projects if you contact the devs. It'll save you a lot of work and will allow you to refactor the code with much less effort.
Then, why do you target .net 2.0? I'd go for a 3.5 at least. LINQ is really good at shrinking some code patterns and make things more readable.
But the most important thing is why .net at all? All I see is a wrapper upon wrapper upon the native code. It's ugly and will constrain you even further. C# and .net is good when you write a code that will live in managed environment and have as little interaction with the native code as possible. Or at least, move all the native parts/wrappers to a separate project, so it won't pop up here and there (like that hack at the start of the program, ugh).

Revision 4148

Require ToString();

Revision 4149

GSDumpGUI: compiles again, made changes for future reconstitution of GIF
primitives and packets

Revision 4150

Fixed dump not working correctly.

Revision 4151

GSDumpGUI: minor change to debugging info

Revision 4152

i18n: new POT files for r4152. Main change: Devel-build specific messages have
been separated, making the main and tertiary pot files much shorter and more
Pot files couldn't be extracted.

Revision 4153

wiki: updated i18n guides to reflect new devel pot file.

Revision 4154

Fix a few non-POD type warnings.

Revision 4155

zzogl-pg: Merge some of the changes from the NewRegs code into the normally used
Reg code.

Revision 4156

zzogl-dev: Bring up to date with the current trunk.

Revision 4157

zzogl-dev: Fiddling around with the interlace code.

Revision 4158

* Documented some of the event/threading proxy class and its underlying event
* Simplified and improved (slightly) the savestate memory cleanup on

Revision 4159

zzogl-dev: Made bUsingStencil a global variable. Commented out some 24 bit code
that didn't seem like it was being called. Added some defines and comments, and
made a few misc changes...
Line 840 of Regs.h you have "thsi" instead of "this", Just thought you might wanna know :)
Thanks. I typed those before going to sleep last night, and it shows a bit...

Revision 4160

* Solution file updates for zzogl (adds needed dependencies)
* A couple i18n fixes listed in Issue 915, relating to dialog message
formatting for a couple specific messages.
* Added some missing operator+() stuff for the pxsFmt string formatter.

Revision 4161

zzogl-dev: Get FFX-2's opening looking nice if interlace is on. Various
interlace related changes, and other cleanup.
If interlace is off, you still get that horrible double image. Looks very nice with it on, though, and Dot:Hack 1 and Dark Cloud's openings don't look as shaky, either.
I wonder if we even should have the ability to turn interlace off? I'm not sure if there are cases where it helps...

Revision 4162

zzogl-dev: Fix a mistake from r4159. More cleanup.
Fixing the mistake messed up the FFX-2 opening slightly, but uncommenting the stencil code in the memory function seems to have taken care of that. Hope that doesn't cause more issues.
And I'm really wondering about this RenderLookForABetterTarget function. Seems to me that it could find a "better" target that then isn't picked, causing the RenderCheckForMemory function to be executed, which, frankly, we want to do as little as possible...

Revision 4163

GSDumpGUI: temporary fix for debugger crash until we implement the real solution

Revision 4164

GSDumpGUI: went a bit mad on changing type width and signs after finding a
signedness bug, and (more importantly for now), handled (kind of) split GIF
primitives without crashing (hopefully)

Revision 4165

GSDumpGUI: Forgot a file

Revision 4166

* Added preliminary word-wrapping support for Han/CKJ character sets.
* UI bugfix for error/popup window message display (bug introduced just a
couple revs ago)
Good job :)
Just a note: Modern Korean DOES use spaces to separate each words so maybe no need to handle.
Oh that would be great news. Unfortunately, the language people are oddly interested in trying to support things like ancient dialects of Japanese and Egyptian Hieroglyphics; so when languages add new features to modernize, they get overlooked. >_<
By Language people, I mean the folks who plan Unicode updates. lol

Revision 4167

Resolved tree mess by passing entire class through tcp.

Revision 4168

GSDumpGui: Little things i forgot.
That didn't work out too well.
Got a crash when stepping through my FFX dump, then restarting the tool
and trying again won't work at all anymore.
The GSdx window won't come up.
This is pretty odd, as I checked task manager and no instance of the tool ran anymore.
probably old bug, this code shouldn'y change behaviour, but we'll see in chat later so i can test.
Here's some refactoring to remove all the fluff off the code (except from the TCP library): http://dl.dropbox.com/u/2214201/GSDumpGUI-r4168_refactor.rar
You don't have to apply it, but you certainly could check out the changes.
Main points are:
* using less code description (unnecessary namespaces, obsolete delegate declaration and object construction);
* lambda expressions instead of creating new anonymous delegates;
* using type aliases instead of value types (I left them where it's meaningfull, like in GSDump wrapper);
* using StringBuilder where there's a lot of string concatenation;
* using string.Format() instead of concatenating the strings manually;
As I said earlier, it would be beneficial to target .net 3.5 and make use of LINQ in some places too.
Oh, and BTW, you'll probably want to change the Architecture from AnyCPU to x86 to avoid all the pitfalls of running the Managed-Native code on 64-bit OS.
Oh, and Path.Combine() is there for a reason too. Now I'll shut up.

Revision 4169

Minor cleanups for the new virtual memory alloc/reserve system:
* Moved VIF dynamic recompiler buffers to the recompilers section of PCSX2.
* Using RecompiledCodeReserve for the VIF SSE functions.
* Minor bugfixes to VirtualMemory class implementations.
* Improved error handling and error message display.
* [TODO] : implement a call to cpuShutdown() to clean up VIF unpack/SSE

Revision 4170

GameDB updates, yay.
Thanks again, Shadow Lady :)
wow much work thanks^^

Revision 4171

zzogl-dev: Add a header for ZZFlush.cpp. Change some defines into forceinlines.
Move various things into ZZGl.h.

Revision 4172

zzogl-dev: Moved s_bDestAlphaTest & bCanRenderStencil to local variables.
Changed around AlphaDestinationTest.
g_bUpdateStencil was already a local variable, but was still being passed around as a parameter for some reason.
And the changes to AlphaDestinationTest were mainly to get rid of some redundancy. Seems a little easier to read, too.
When you said local, you wanted to said global ;)
Indeed I did...

Revision 4173

Avih renovated the configuration dialog a bit. It makes lots more sense now,
thanks :)
Just a slightly more detailed log message:
- GSdx DX9 dialog consistency:
1. Hopefully clearer wording and scaling-controls order.
2. Log z is disabled if irrelevant (when 32 bit depth buffer is used).
3. Custom resolution is disabled when a multiplier resolution is selected.
- MSAA should be working again on many systems:
1. Will only allow valid supported MSAA values (and prompt the valid values when setting an invalid one).
2. Will warn if choosing MSAA degrades the Z buffer bit depth (previously: would not use MSAA if it degrades z buffer, and prev-prev: crash).
MSAA settings should be dropdown rather than spinbox. The values are not ordinal (e.g. can be 2,4,8) and may differ from system to system. this Would also get rid of the annoying "cannot use this value" alerts, since only valid values for that system will be displayed there.
congrats on this avih.
Sorry for leaving out the details :p
DX10 configuration also benefits from the changes.
wow great job
very nice

Revision 4174

zzogl-dev: Refactor FlushTransferRanges a bit.

Revision 4175

Patch from avih, untested (but probably harmless) as I only have one monitor:
Make the GS window go full-screen on current monitor instead of always on
primary monitor.
works for me.
1 line-by-line comment
line 446:
446: #define wxUSE_DYNAMIC_LOADER 1
Any reason to enable this?
KrossX3: doesn't compile without it, probably a bug but it's enabled in later wxwindows versions by default anyway.
KrossX3: On top of what sudonim1 said, the wx bug is probably the inclusion of dynload.h instead of dynlib.h at msw/display.cpp. Couldn't get wxWidgets guy's comment about it yet.

Revision 4176

* Clean some alpha blending code.
Note: I also remove some debug message control by bDestAlphaColor. It seems not useful, in case I can still re-add them properly (ie with _debug flag everywhere)

Revision 4177

API change: Simplified handling of app/emu config defaults handling. Got rid of
the mandatory "defaults" override -- LoadSave APIs for Pcsx2Config and EmuConfig
now use the current settings of the class instead.

Revision 4178

cmake: use absolute path for resources file. ( issue 930 )
Just tested under Linux and this seems to do the trick. Thanks for the quick response.
Good. I can close the bug.

Revision 4179

Ran Cppcheck on SPU2-X, fixed a few things it found.

Revision 4180

GSdx: Double-click now toggles full screen.
This needs to be made an option, it's almost impossible to play when using a mouse as controller and most of the mouse options in Lilypad make the cursor dissapear instead.
Oops #1: It's a PCSX2 patch and not GSdx.
Oops #2: I didn't consider a scenario where mouse is used for input (thanks to prafull for thinking about it), which might now suck. So it probably requires another checkbox at the 'GS Window' config tab. Probably best to disable it until the user config is added.

Revision 4181

Disabling the code for full-screen toggle by double click. It makes pcsx2
unusable for people who use mouse input. I'll re-enable it later together with a
user option to disable it.
This is a bad feature.
Better would be if the user were informed in "Config"\"Emulation Settings"\"GS Window" about that pressing "Alt+"Enter" switches between windowed mode and full screen mode.
I agree, Alt+Enter is pretty much the accepted method. And who knows, maybe someone will make a plugin for a game that uses the mouse as a controller instead of the analog sticks, never know so its just a good idea to keep things simple. Alt+Enter
I like the idea personally.
Make an option, disabled by default.
If you don't like it, don't use it.
Same here. I like the feature.
Other apps also use this.
It just has to be optional for those people that use their mouse for input (lol).

Revision 4182

[Safe WIP] Presets: PCSX2 configuration for dummies:
- When Presets are disabled: Nothing changes compared to earlier pcsx2 versions.
- When enabled: All important config options are grayed out, and a slider is
used to select 1 of 6 overall config presets,
in the range of safest (and slowest) emulation, through trying to balance
compatibility and speed, to way-too-many-hacks.
- TODO: 1. Resolve UI inconcistencies ("Cancel" button). 2. Fine-tune the
presets. 3. Slight refactoring.
very nice though useless to me a great idea for noobs^^
Thanks for doing this. It would have taken me weeks :p
congrats for entering the team avihal
nice :) welcome aboard btw!
Welcome. It is a vey good idea !

Revision 4183

PCSX2: Presets: 1. GUI consistency. 2. Fine tuned presets.
The presets system is hopefully done, code wise. Fine-tunning the presets
themselves may still take place.
- GUI behavior should be as follows:
1. Overall: any changes made to the GUI without clicking Apply or OK would be
discarded (on ESC or Cancel or close ([X])).
2. On 'Presets' unchecked: As long as the config dialog is open, the GUI stays
with the values of the current preset (alternative behavior is available with
--> NOTE: OK/Cancel/Apply buttons are never disabled. This is also true for
r3768. Needs fixing one day.
- Fine tuned presets with some help from rama and pseudonim. Current Presets are
as follows (each preset adds to the previous one):
1 - Safest : Default settings + Individual speed hacks unticked (to
make it visually clearer they're not used).
2 - Safe (faster) : Recommended speed hacks minus vuFlagHack.
3 - Balanced : enable vuFlagHack, enable EE timing hack, EE cycle rate to
1 click.
4 - Aggressive : VU cycle steal to 1 click, enable (m)vuBlockHack, VU clamp
mode to 'none'.
5 - Aggressive plus : EE cycle rate to 2 clicks (maximum).
6 - Mostly Harmful : VU cycle steal to 2 clicks (maximum-1).
Note: The GUI consistency stuff turned out harder than I thought. I
intentionally left in the code some commented out Console.WriteLN calls which
should help debugging in case it's needed, but they should be removed
eventually. I'd appreciate some regression tests and possibly code review for
the entire presets system. Thanks.
Read the Issue 915 for i18n troubles with your new feature.
Read here for detals about it:
the trouble is first introduced in r4182.
pcsx2fan , Thanks, I'll fix both.

Revision 4184

Presets GUI consistency fix: Speedhacks 'Restore Defaults' resulted in grayed-
out controls if last applied settings include presets enabled.

Revision 4185

zzogl-dev: Change around the transferring code a bit, use the Point and Size
structs a bit more, and do some work on GetRectMemAddress.

Revision 4186

zzogl-dev: Add ZZoglMem.cpp & ZZoglMem.h from ZZogl, disabled currently, so I
can look at bringing in Zeydlitz's changes at some point. (Currently does not
compile if enabled.)

Revision 4187

zzogl-pg: Revert some changes to CreateFillExtensionsMap for the moment.

Revision 4188

zzogl-dev: Bring the branch up to date with trunk.

Revision 4189

zzogl-pg: Both the normal version of the memory code, and Zeyditz's from current
zzogl now compile and run. (Though this'll probably need a bunch of cleanup.)
I meant to mark this as zzogl-dev. Oh well...
Also, there is probably a bunch of duplicate code at the moment. I'll get things squared away later.
In the meantime, comment "#define ZZNORMAL_MEMORY" in GS.h if you want Zeydlitz's current version of the code, and uncomment it if you want the normal, in trunk version.
The goal is to eventually merge the former into the latter...

Revision 4190

zzogl-dev: Do a bunch of cleanup on ZZoglMem.

Revision 4191

zzogl-dev: Use the in trunk swizzle code, and more cleanups.

Revision 4192

zzogl-dev: There should probably be a break here...

Revision 4193

* add eol-style native metadata for everyone
* use a static buffer for g_vboBuffers
* comment code around g_nDepthBias

Revision 4194

zzogl: restore the opengl3 method for fill extension, fallback to the old method
if not supported
1 line-by-line comment
line 422:
422: all_ext = string(ptoken);
ptoken here points to the last extension.
it should be placed before line 403.
Thanks, I will fix that later
Ok fix in last rev.

Revision 4195

debian: minor refresh & update

Revision 4196

zzogl-dev: Get rid of the goto in ZZoglMEm, and use Point. Add ZZoglMem to
cmake. Enable it by default for the moment, since I seem to be working with it a
bunch right now.

Revision 4197

zzogl: print the full string of extensions...

Revision 4198

Major Settings Changes!
* PCSX2 now splits settings into two files: pcsx2-ui.ini and pcsx2-vm.ini. The
former is user interface clutter (window positions, confirmation dialogs, etc).
The latter is virtual machine settings, speed hacks, game fixes, etc.
* Added support for PORTABLE INSTALLS!! Portable install is currently manually
enabled by adding an empty "pcsx2-portable.ini" to the install location of
PCSX2. Portable installs should run seamlessly from any flash drive, etc. (and
will usually need Admin rights)
* PCSX2 install location and plugins folders are stored in the registry now
(unless portable install is enabled, in which case no registry is used).
* A button to enable portable installs from within PCSX2 is planned.
* NSIS installer will hopefully be upgraded to allow for a portable install
option as well.
nice job!
you learn how to compile SVN :P
RETARDED registry thing. I was hoping there never will be such stupid thing.
No wai: http://upload.worldofplayers.de/files6/fp.gif
@zantezuken: ...... childisch....
Please remove any registry writing unless final release is out.
What's wrong in using the registry?
It was made for this you know.
You've struck fear in to all the nabs who have UAC enabled ;p
oh, or norton/search and destroy
<rama1> evil pcsx2 writes to registry now and makes computers slow and crashy :/
<rama1> i see one key with 8 settings here
<rama1> that means 45% more crashy!
and now comes my question :
Why fix something that isn't broken ???
Seriously now one ini was enough, i don't need 2.
Don't really care about the registry thing though (UAC is for wussies).
and you went in your ini folder and went "gosh this is getting cluttered" how many times?
seriously, whining about an extra ini file (which in perspective can make things much easier for us, also easier to navigate, better portability) is highly un-necessary and a waste of your time.
It's there, it's staying there, get over it, your life is ruined. Sorry.
PCSX2 needs to know the location of its files and the mode it should work in to work as conveniently as it does.
We can either write this to some hidden folder in your user docs (as before) or directly into the registry.
Registry is prolly the safer option even as it guarantees read access rights.
Having an installer, program files entry and multiple conveniency features unfortunately requires this.
It was "not broken" because we did this before. You simply didn't notice.
@refraction : SIGH again, what perspective, easier to navigate WHAT?, you really want to read a whole file without scrolling, WHY? the original single ini wasn't that big anyway. Also i was just presenting my opinion don't jump on my head.
@rama : Well i can't really say anything because i know that what you said is true :). Maybe it'll fix PCSX2 for users that whine about it not saving settings etc...
Sorry but i am getting scared of the fact that you guys are becoming more and more like the guys from the dolphin svn (they are like "we have games that don't work but LOOK now we have a language selector YAY!!). This is why i tend to bitch a little. Sorry.
While the emulator is about the emulation of the games, it is also about functionality, there is nothing worse than a hard to use or inconvenient program.
The changes here are for our benifit more than yours, it provides us with better flexability for future changes, also less problems as rama mentioned. Not every update HAS to be "this fixes this game". If the dolphin guys want a language selector, hats off to them, not everybody can read english, especially well.
well yeah i agree with you that an emulator has to be easy to use, also i didn't say that EVERY update must be "this fixes X game" or "this gives a 1000% speedup", and if you say these changes help you i can't say anything more.
In my opinion everybody should know how to speak English because its the language of the internet blablabla *mumble**mumble* whatever.
Well whatever, i am not the one that decides on what or how you should spend your coding time (if i did, then i would be no better than the other "plsfixthisgame" noobs out there).
Sorry for wasting your time to give explanations to me (i'm still a novice programmer and i don't understand some concepts very well).
Anyways cheers to you guys for the emu couldn't be this good without you, keep up the good work :)
This is not 1999 folks. The registry hasn't been a source of problems for Windows since Windows 2000 came out over TEN years ago.
The registry is small and efficient for the purpose I'm using it, and it won't even be used if you use it in portable mode (and I know most of you will). This change also allows us to package 7z/zip downloads of PCSX2 again *without* the installer -- and that package won't use the registry. (omgosh! bet you wanted that!)
I doubt I'll use anything other than portable mode.
I just tried r4199 and with and without the pcsx2-portable.ini in the pcsx2 folder(or in the inis folder),the registry key is still created.
Just curious,why the old way was removed?
Before on the old gui pcsx2 searches for the plugins,bios and so on in the same directory where pcsx2 is but now on first start you must tell him where his files are and that info must be placed in the apps data folder or like now in the registry...what's so wrong with the old method(pcsx2 searches for his files where pcsx2 is and keep the info where they are in the pcsx2.ini in inis folder(a sub-folder inside the pcsx2 directory,not in some "god knows where location" )
1 line-by-line comment
line 294:
294: wxFileName GetVmConfig()
Jake, is it normal that both FilenameDefs::GetVmConfig() and FilenameDefs::GetUiConfig() return the same things !
Permission issues between various Windows / UAC versions and the program files directory install. Basically (there's more :p).
PCSX2 starting to be more and more bloatware. INI-way worked just fine before, why fix something that arent broken?
dude read the above posts and you will see why.
Or you don't know how to read??????
He knows how to read, just doesn't know what to make of it; technical explanations probably proved too foreign to him.
'Bloatware' and 'why fix something that arent[sic] broken' are the usual key terms used by any IT-literate people with limited knowledge.
It's a fact that Humans from various countries, are tending to not to use registry as much as possible, even though pcsx2 only utilizes registry only a little.
I myself would like to manually enable portable installation before running pcsx2, like it did in 0.9.6.
I think this change is the way to get along well with UAC related permission issues, as well as keep it portable as 0.9.6 naturally does. No doubt the 0.9.6 has UAC permission issues you need admin rights or it won't work as expected.
Anyways, in other words, it's a compromise between UAC related permission issues and portability as 0.9.6.
pcsx2 settings become a mess
At least portable!
PCSX2 ALWAYS was portable by default. Just keep press "Next" when Master appears it it ill re-use current INIes in your USB-stick.
I must first say that I'm happy about adding portable install, but..
Using registry for storing setinggs for emulators is a big no from my side.
Not that it's something problematic or causes errors, but it's a big problem
for those who use few copies of pcsx2 for the purpose of playing specific games
which tend to work faster (or overall better) on one version and worse on the other.
What I mean is that if you have different install and plugin folders for each
of your pcsx2 copy and those locations are stored under the same registry
key for each copy, they will be overwritten for the last copy used and
each time I would like to use a different copy of pcsx2 I'll have to set
it up again and again.
I dunno if it happens in this case, but this may generally cause trouble.
PS: Hopfully my explanation was understandable.. :)
marcos: well hopefully plugins (at least for now) will be compatible with future and current versions of PCSX2, so from now on, it doesnt matter what new pcsx2 you use, youll get the functionality of that version of the emulator but it will share plugins, that is the only difference.
obviously any version previous to this will ignore any registry settings anyway.
The portable option will be what you naysayers want.
The registry option is for all those people that needs installers.
No one will loose anything.
There's nothing more to say.
I'll be uploading bugfixes for this revision shortly.
And yes, the portable install is there for people who want 16 side-by-side copies of PCSX2 for custom plugins and settings for each game they play.
Installer packages of PCSX2 (and the registry settings they utilize) will be useful for people who do not have admin access for whatever reasons (yes it happens sometimes, especially nowdays), and that won't be going away either.
great, now gsdx can't save it's settings, memcards path and other keep resetting after restartng pcsx2. adding pcsx2-portable.ini to the install registry and Resetting settings, using emu GUI doesn't change anything at all, even the wizzard doesn't show up after it. Maybe it's cuz of russian letters in path to My documents folders, i don't know, but everything worked fine before and nothing works after these changes nevertheless of this portable feature..
and yep, i'm using admin account and UCC is disabled.
Well, maybe that's because of already fixed bugs?
Thanks for your answer.
PS: As I can see it, this set of changes seems to be the most controversial
in the history of pcsx2, at least among the users. :)
It generates the most heated disscussion for the moment.
This work is useless.
Even casual emu users will be using portable, because PCSX2 isn't perfect. it requires different revisions/plugins/settings etc for each game and when they come to the forums asking questions or complain, they will be recommended to use portable mode. It's much easier.
All this registry shit is useless work, everything was ok before. Rever the rev, don't waste your time on this shit.
you said "Portable install is currently manually enabled by adding an empty "pcsx2-portable.ini"" but in your AppUserMode.cpp code is return programDir + "pcsx2_portable.ini"; i think you should correct that....
1. PCSX2 was already creating a file on your PC in a hidden location regardless of modes. That was *invasive* behavior.
2. The new method allows to disable that completely (portable), and uses the registry instead of the hidden file when using installers [less invasive, easier to clean via 3rd party utils and installers]. Installers provide UAC-friendly install options.
Therefore, the new system REMOVES previously existing requirements for invasive hidden 'system-clogging' settings; and replaces it with a simple and standard method that is well-supported since over TEN years ago. It retains UAC compatibility for those who may need or benefit from it.
Finally, it wasn't "ok" before. The old wizard stuff was a hack, and people complained about its limitations frequently on the forums (specifically relating to running pcsx2 from commandline locations, which is now fixed). There is no logic to your argument.
> 1. PCSX2 was already creating a file on your PC in a hidden location
> regardless of modes. That was *invasive* behavior.
Omg, c:\Users\%USERNAME%\AppData\Local\pcsx2\usermode.ini is such a hidden location. indeed. So many files scattered over the C:\, I can't live with that!
2. Right, tons of shitty registry keys instead of just one small ini-file. Riiight.
> Finally, it wasn't "ok" before. The old wizard stuff was a hack, and
> people complained about its limitations frequently on the forums
> (specifically relating to running pcsx2 from commandline locations,
> which is now fixed). There is no logic to your argument.
Okay, I guess there is clearly no logic behind all those negatives (19 vs 14 atm). Indeed, ppl like it.
I don't understand, if you code emulator for yourself, why make it public? if you code it for everyone, why ignore community?
Technically there is only ONE "shitty" registry key. The other contents are technically values and data. One ini file contains many values and data, one registry key the same.
We do not "ignore" the community. People have complained of theold system and the old ini for a long time -- it directly interfered with portable installs, which are very popular (and something I personally *never* used). So I fixed it. You're the fuck face with an attitude. I spent hours of my life, and worked on a plane and in an airport and in a hotel room after hours to try to get this finished as quickly as possible. You probably played a lot of games, jerked off a few times, and then bitched because the word "registry" was used.
The registry is a compact and efficient alternative to the file system. Keys in the registry can be sorted, searched, and loaded much faster than files on the hard drive. It reduces burden on the file cache. It avoids wasted space on the hard drive (most inis are well under the 4k cluster size). It has simpler security/UAC rules, and is more secure at the same time. There are no known bugs in the registry.
Finally, it will ONLY BE USED BY THE INSTALLER, which you probably won't use anyway.
What more do you want? You're the religious whackjob on a random and misguided crusade against the registry.

Revision 4199

Linux compilation fixes.

Revision 4200

Minor tweak to savestates to help improve threaded responsiveness. May or may
not work as expected (thread scheduling doesn't always behave in a consistent
manner). Shouldn't hurt in any case.
MVS 2008 generating
25>..\..\gui\SysState.cpp(437) : error C3861: 'Yield': identifier not found
25>Build log was saved at "file://d:\PCSX2-Development\PCSX2-svn\pcsx2\windows\VCprojects\Win32\Release\BuildLog.htm"
25>pcsx2 - 1 error(s), 0 warning(s)
========== Rebuild All: 24 succeeded, 1 failed, 0 skipped ==========
When changing "Yield(4)" in ..\..\gui\SysState.cpp(437) to "Threading::pxYield(4);" It seem to compile and run, but I didn't test it more than that. FYI/

Revision 4201

Fixes for issue 915 (comments 24/26/27): 1. Presets slider i18n name icons were
all "!Panel:". 2. Speed hacks sliders got broken (reverted the code to pre-
I have some issues with preset on linux.
1/ The slide bar is few pixel large, it is impossible to select the level.
2/ When unselect preset, it did not restore my previous config
Only tested on Windows. Maybe need to set a minimal height for the presets. I'd appreciate a screenshot.
When unchecking "Presets" it would leave the GUI settings at last preset values. If you press Cancel and re-open the dialog you would see your last applied settings. This is by design to allow using a preset as a base for further tweaking.
I'm fine for 2. Anyway I send you a screenshot.

Revision 4202

Re-enable Double-click toggles Full-screen, added a checkbox on the GS Window
config panel (default = enabled).
Objection: "default = disabled" would be better.
pg..., +1
Yep, the feature is nice but mouse input users would be confused by this.
I agree that users who use mouse input might be confused at first, however, the vast majority of the users don't use mouse input (correct me if I'm wrong), and for those, I think this feature would be much more useful if enabled by default.
However, I'm also fine with any modification, preferably following some convincing arguments.
It is a question of respecting minorities, not because there cute, but because they have a purpose. And the purpose of those who actually uses mouse input is to enlighten that this should be disabled by default.
Thank you.
I don't think it much matters either way, though I do lean towards leaving it disabled by default and allowing those who want it, to enable it.
How about this argument:
"Since the option to use mouseinput is a feature,
most users who actually use this probably assume that an additional mouseinput feature,
which they furthermore are probably unaware of, is not enabled by default.
If it would be up to them to disable it, most of them probably woudn't know what to do."
Is this humble enough?

Revision 4203

Compilation error fix and updated about box credits a bit.

Revision 4204

* Added a --portable command line option to force portable mode operation.
(same thing as adding pcsx2_portable.ini)
* Removed the old and complicated first page for the wizard. New page just has
a language selector and some links to the CSX2 configuration guide and FAQ. The
usermode/settings stuff has been supplanted by the simpler portable mode
I compiled r4204 to experience the new feature introduced in r4198, but encountered the error in screenshot upon running pcsx2 from scratch, and First-Time Wizard didn't pop up.
pcsx2-ui.ini and pcsx2-vm.ini don't exist in inis folder.
Jake, me too I did not find the new files (In case you did not see my comment in the register troll). You wanted probably to do something like this.
Index: pcsx2.snapshot-4199/pcsx2/gui/AppConfig.cpp
--- pcsx2.snapshot-4199.orig/pcsx2/gui/AppConfig.cpp
+++ pcsx2.snapshot-4199/pcsx2/gui/AppConfig.cpp
@@ -294,7 +294,7 @@
// FIXME? ini extension on Win32 is normal. Linux ini filename default might differ
// from this? like pcsx2_conf or something ... ? --air
- return pxGetAppName() + L".ini";
+ return pxGetAppName() + L"-ui.ini";
wxFileName GetVmConfig()
@@ -302,7 +302,7 @@
// FIXME? ini extension on Win32 is normal. Linux ini filename default might differ
// from this? like pcsx2_conf or something ... ? --air
- return pxGetAppName() + L".ini";
+ return pxGetAppName() + L"-vm.ini";
wxFileName GetUsermodeConfig()
I'm also unable to get it to work in portable mode (haven't tried non-portable). My freshly built executable is called pcsx2~latest.exe. Tried putting pcsx2_portable.ini in pcsx2 root dir, and also in pcsx2/inis and also in both, with or without deleted pcsx2/inis/pcsx2.ini.
It always asks me to reconfigure the plugins. If I invoke it with --portable it shows a language selection dialog before asking to configure the plugins.
After configuring the plugins (I uncheck "use default directory" from all checkboxes and give it explicit dirs to use), changing something, saving, exiting pcsx2 and running it again (still with pcsx2_portable.ini at both root and inis) it asks again to reconfigure the plugins again.
It also creates a inis/pcsx2.ini file which seem to have only EmuCore options. So I can't find the UI ini file (haven't looked outside the directory at which I'm testing).
When creating an empty pcsx2~latest_portable.ini at pcsx2 root dir (and leavig pcsx2_portable.ini at inis dir) it converts this ini file to partial ui ini (some options are there, the plugins dirs are not there). After changing some configs and saving (or after exiting or restarting) it went into infinite loop which prevented me even from invoking the task manager with a CTRL-SHIFT-ESC. Had to reboot.
Can you explain exactly the relations between the registry, ini files/names and portable mode? Does it also have a transition mode where it tries to reads the "old" pcsx2.ini but saves it immediately as 2 separate ini files (core and ui)?
Overall, while I appreciate a portable mode, something seems to me overly complex here...
It is possible that identical file pcsx2-ui and pcsx2-vm generate some bad behavior. PCSX2 open read the file twice and overwrite some configuration during the write...
The more I think about it, the more I tend towards the idea that the ini file names should NOT be related to the main exe name (i.e., just stay hardcoded). The inis directory can be chosen with command line argument, and possibly also the ini file names themselves (haven't read the CLI options docs), and making the ini file a function of the exe file name just introduces more opportunities for confusion and bugs (along with some flexibility which can probably mostly be achieved in other ways).
pcsx2 be prompted each time you start can not find the plug-in
Settings file can not be saved
Testing it, command line works as expected, pcsx2_portable.ini is created.
pcsx2 asks for GS plug-in to reset because it can't find it.
It does not set any directory in the [Folders] section to install location. (only BIOS can be set in first-Time wizard) so settings end up in user directory.
It does appear to adjust paths.
settings are reset on each launch.
there is "PS2Emu" in my registry, not sure if these are old keys.
so, it seems to half-work, but it is WIP so there will be bugs here and there. Keep up the good work.

Revision 4205

Indentation: Converted some spaces to tabs under pcsx2/gui.

Revision 4206

rewrote zerospu2's pcsx2_aligned_malloc/free which linux builds might use.
the old logic was wrong for a few cases.
Some reason posix_memalign() isn't used for this?

Revision 4207

Bugfixes to the new pcsx2-vm / pcsx2-ui split ini system (WIP). Also fixed
minor formatting errors in the intro wizard page.

Revision 4208

Major settings bugs from the last few earlier commits fixed here. Sorry folks.
First time wizard is still busted as you know.
Just mentioning it here so people don't report :p
Much better. Now pcsx2 remembers my plugin settings again...
Incidentally, one oddity I noticed when playing with the first time wizard in Linux in portable mode:
My system is just set up for an English (US) locale, so that and the system default are all that's listed in the wizard. However, if I choose either and hit apply, it switches to Vietnamese. ^_^
Going into gui/i18n.cpp, and commenting out the line:
if (wxGetLocale() && (info->Language == wxGetLocale()->GetLanguage())) return true;
in the function i18n_SetLanguage takes care of this, as does moving it below the next line of code:
ScopedPtr<wxLocale> locale( new wxLocale(info->Language) );
Of course, I haven't had a chance to test those code changes in any language but English, so I don't know if that'd mess up anything else...

Revision 4209

Removed the PostBuild from the project to allow easier autobuilding.

Revision 4210

GSDumpGUI: Clean up GS plugin loading. Try all parent directories before giving
up. Attempt at human readable plugin loading errors (fails badly).

Revision 4211

SPU2-X: Made the visual debugger available via configuration dialog.

Revision 4212

Several bugfixes for the new portable install mode.

Revision 4213

spu2x: drop liba52 of codeblock project. (liba52 have been dropped since last
Thanks :)
Arcum, by default spu2x select the "Unknow" api. Unfortunately on 64 bits system portaudio seems to use oss which allow 1 application to use the soundcard. (so audio player block spu2x).
1/ Add a button options in gui to select the api.
2/ Change the default value in the code. Nearly all people uses ALSA (or pulseaudio that is ALSA compatible). See patch below
3/ both
What do you think ?
Index: pcsx2.snapshot-4199/plugins/spu2-x/src/SndOut_Portaudio.cpp
--- pcsx2.snapshot-4199.orig/plugins/spu2-x/src/SndOut_Portaudio.cpp
+++ pcsx2.snapshot-4199/plugins/spu2-x/src/SndOut_Portaudio.cpp
@@ -291,7 +291,14 @@
wxString api( L"EMPTYEMPTYEMPTY" );
+#ifdef __LINUX__
+ // Use ALSA API by default on linux
+ // On 64 bits systems, "Unknow" selects OSS which allow only 1 application to use the
+ // sound card... So 64bits people does not have sound with spu2x... --greg
+ CfgReadStr( L"PORTAUDIO", L"HostApi", api, L"ALSA" );
CfgReadStr( L"PORTAUDIO", L"HostApi", api, L"Unknown" );
CfgReadStr( L"PORTAUDIO", L"Device", m_Device, L"default" );
m_ApiId = -1;
I'd say #1. Being able to choose the api makes sense to me.

Revision 4214

* get Zeydlitz GLSL work (-DGLSL_API to enable it) by default use nvidia cg
* various update to properly use the zz shader API
* cmake option (GLSP_API) to select either GLSL or cg
* Fallback to an abolute path when open a shader (fx or dat) file
There seems to be a typo in the change made to "branches/zzogl-dev/cmake/SearchForStuff.cmake":
GLSP_API <- Shouldn't this be GLSL_API ?

Revision 4215

SPU2-X: Some improvements to the developer debug window.
NOTE: Said window only works in Windows AND in a debug/devel build.

Revision 4216

I misscalculated some coords in the previous commit.

Revision 4217

Undo some changes that shouldn't have been commited.

Revision 4218

SPU2-X: Further tweaks and additions to the debugger.

Revision 4219

zzogl-dev: Get the GLSL work set up as an option in codeblocks.
Note: if I personally start up the plugin as compiled with GLSL, it errors out when compiling all the shaders. But then, something similar happens if I try using Zeydlitz's version...

Revision 4220

SPU2-X: Disable the frequency response filter until good config parameters are
found. It currently overemphasizes the highs.

Revision 4221

zzogl-dev: Get rid of all the errors when running with GLSL on nvidia. (Still
doesn't work properly)
Hope this doesn't break it on non-nvidia cards...
You GlslHeaderString should be different for VERTEX_SHADER and FRAGMENT_SHADER. Just now you use #define VERTEX_SHADER 1 for both of them, that means, that fragment shader's code is not used.
If you look closely, GlslHeaderString doesn't actually return that part of the header. VERTEX_SHADER and FRAGMENT_SHADER get tacked on afterwards, as appropriate.
I noticed that, and made sure not to include it. Though I just noticed a different mistake...
A! You forget \n after GlslHeaderString -- so you #define for VERTEX_SHADER 1 does not work at all. Also check line 896. There is to AddWrap.
I noticed the second, which was the mistake I mentioned. Didn't notice the first, though. For some reason, I was thinking the '\n' was in there somewhere...

Revision 4222

zzogl-dev: A few corrections to my last commit.
You'll probably see ZZNORMAL_MEMORY get commented and uncommented for a while, incidentally.
Does GLSL part work or not?
And put #extension ARB_texture_rectangle: enable in shader file, where it should be. We use this headers trick to made different shader's program from one shader file, but same parts should be in .fx file.
Not for me. But then, I've never seen GLSL work on an nvidia card.
Without the changes I made, it was giving errors and warnings on compiling every shader. With the changes (mainly the extension), it doesn't give any errors or warnings, but nothing is displayed in zzogl either.
And I'll move the extension. I originally was putting it in the header because the errors were pointing more towards the version.
This library looks potentially useful, btw:
o'k. Nvidia failed in glUniform4fv. Let me look at this.
Aha, it was obvious error. Change
glUniform4fv(location, 4, param.fvalue);
glUniform4fv(location, 1, param.fvalue);
It works on my nvidia card.

Revision 4223

spu2x: linux compilation fix
The Linux side of SPU2-X really needs attention, yeah.
The output module problem and resulting latency is so bad.. :p
Thanks for cleaning up behind me, gregory :p
No worry, I try to add a settings for the api. It is easier when the code compile fine :p
Actually there are some moves inside debian people to take over the soundtouch package ownership. With some luck, we will finally get soundtouch 1.5 in debian/ubuntu.
Rama it is your turn :p. I implement my new feature but I'm afraid I probably broke windows build. If you could give a quick test of rev4224, I will be glad.
Ah someone just uploads soundtouch 1.5 to debian experiemental (with ia32 interface too) ! Maybe with some ubuntu lobbying, they will integrate it in the next ubuntu release (april).
Whops, bad time to break it. I'll be away a while.
Oh well :p

Revision 4224

* fix linux compilation debug build
* Add a linux option to select the API output of portaudio (ALSA, JACK and OSS)

Revision 4225

spu2x: fix previous commit: restore correct api at startup

Revision 4226

SPU2-X: Minor change on the ADPCM decoder. 2 other known decoders do this as

Revision 4227

Presets: Now the first preset is numbered "1" (was 0). 0 based index is not for
mere mortals..

Revision 4228

zzogl-dev: fix a typo in cmake

Revision 4229

i18n: Added new locales folder to trunk (build rules/makefiles coming soon).
Currently available languages:
* Chinese Simplified
* Chinese Traditional
* Russian
(more coming soon)
Typos in path
zn_CH should be zh_CN, for Chinese Simplified.
zn_TW should be zh_TW, for Chinese Traditional.
Which are referenced from SupportedLanguagesChart in the wikis here.

Revision 4230

i18n: removed isolated i18n folder, instead favoring an integrated locales
folder in /trunk (same system used by most other gettext apps).

Revision 4231

wiki/i18n: update SVN links to point to the new locales folder. Instructions on
using svn are still not especially clear in my opinion, but oh well. >_<

Revision 4232

Fixed small bug that prevented the slow motion toggle to work. Shift + Tab now
enters slow motion.
Yay, Jake +1'd me :p

Revision 4233

i18n: simplified some message allocations for the new presets system.
DevNote: pxE's are meant for long/multiline messages only, not individual words.
Is there a down side for using pxE's? I had the impression it can only help translators.. while not using them has only one aim of making developers lives easier when generally using translatable strings.. have I missed something?
Oh.. and thanks for the fixes.. :)
pxE's are actually more complicated for translators, since it means they have to reference the source code to see what the text actually says. Typically in other forms of Gettext, the text string is included in the template file, and so a translator can do all the necessary translation work with any basic text editor.
The advantage to pxE's is if the text of a long string changes -- a spelling correction, punctuation change, or slight rewording that doesn't actually change the meaning of the text. in these cases, standard gettext would cause a "fuzzy" match, which either doesn't get translated at all, or requires special heuristics-based utilities to be matched up to the old values.
So the main goal of pxE's is to keep translations from not working if we make punctuation, spelling, grammar, newline changes, etc. The secondary goal was to overcome a serious parser limitation in gettext itself, which makes it difficult or impossible to have multi-line gettext strings in the code, using multiple "" sets.
And so they're only useful on text that is long enough to merit those sort of changes, or that need to be broken into multiple "" sets for editing sanity.
Got it. thx.

Revision 4234

i18n: moved a couple more messages to the pcsx2_tertiary pot file.
Thanks for the ongoing effort on translations :)

Revision 4235

i18n: typo fixes for chinese

Revision 4236

Fix the apply button not graying out anymore like it used to.
This is a patch from Jake.
Yeah, I for one disliked that button's behaviour,I always felt the need to double back and check if my changed settings had realy aplied or not (they were always aplied but I was still checking :P)

Revision 4237

Presets: Bug fixes, code cleanups, better documentation:
1. Bugfix: Some configs were affected by presets although they shouldn't have
(e.g. MultitapEnabled and few more).
2. Bugfix: GUI: moving the presets slider was forcing unaffected values to last
applied settings (would override settings changes which took place at the GUI
while presets are enabled, e.g. most GSWindow options).
3. Better code resilience for future SysConfigDialog panels which might not be
affected by presets.
4. Removed unused code and improved comments.
Log correction: Log item 1 (some configs were wrongly affected by presets) is bogus.
In fact, The presets currently (and previously) ONLY affect the main config dialog, and configs which should be affected by the presets and are outside the main config dialog are not affected at all until pcsx2 is restarted (most importantly: sys-menu -> enable patches is only getting the preset after pcsx2 restarts).
I'll fix it soon.

Revision 4238

cmake: (WIP) rule to compile translation file on linux.
Note: to install them, you must call "make install" with root access. Files will
be install into /usr/local/share/locales...
Hmmm... I checked out a new copy of the pcsx2 source, made a directory in the root directory called "build", went in it, and ran cmake .., followed by make. This is what I received:
/usr/bin/msgfmt: error while opening "/usr/local/src/pcsx2-locale/build/locales/zh_TW/pcsx2_Devel.gmo" for writing: No such file or directory
make[2]: *** [locales/zh_TW/pcsx2_Devel.gmo] Error 1
make[1]: *** [locales/CMakeFiles/translations_pcsx2_Devel.dir/all] Error 2
If I go to the main directory, do cmake ., and make, I get this instead:
Scanning dependencies of target translations_pcsx2_Devel
[ 0%] Generating zh_TW/pcsx2_Devel.gmo
[ 0%] Generating zh_CN/pcsx2_Devel.gmo
[ 1%] Built target translations_pcsx2_Devel
Scanning dependencies of target translations_pcsx2_Iconized
[ 1%] Generating ru_RU/pcsx2_Iconized.gmo
[ 1%] Generating zh_TW/pcsx2_Iconized.gmo
/usr/local/src/pcsx2-locale/locales/zh_TW/pcsx2_Iconized.po:23: `msgid' and `msgstr' entries do not both end with '\n'
/usr/local/src/pcsx2-locale/locales/zh_TW/pcsx2_Iconized.po:36: `msgid' and `msgstr' entries do not both begin with '\n'
/usr/bin/msgfmt: found 3 fatal errors
make[2]: *** [locales/zh_TW/pcsx2_Iconized.gmo] Error 1
make[1]: *** [locales/CMakeFiles/translations_pcsx2_Iconized.dir/all] Error 2
make: *** [all] Error 2
A bit further, but still an issue...
I do not know exactly the po syntax but I think pcsx2_Iconized.po have some bad extra \n. I did not touch it because I can not test chinese. Note the translator made a new version ( issue 920 ).
The first is real error, I need to understand and fix. Hum it seem to miss some mkdir. Thanks for the report.
I commit a fix + update the translation that must be ok now.

Revision 4239

Fix for GTC Africa Jerkyness (Placement issue), Fix for Aura for Laura demo
causing graphical errors, was multiplying VU Cycles by BIAS twice, not really
clever :P
Let me know if any games stop loading, im not expecting any problems, but knowing my luck there will be.
Where else was VU Cycles being multiplied by BIAS?
in vif_transfer, but as vif cycles :P

Revision 4240

Fixed long standing bug with Syphon Filter - The Omega Strain involved in the
handing of Filling Writes

Revision 4241

Added some extra "how much in VIF fifo" checks, removed a silly one, fixes
what the ... GAME REPAIR SPREE !!!
Getting some regressions off my list :p
Note: This might only fix Gungrave OD, i dont have any other version :(
Gungrave working? OMG! I so gotta test that tomorrow XD
I'm not sure which, but this, r4240 or r4239 seems to have introduced a little lighting glitch in Final Fantasy X. I'll test to find out which in the near future.
Screenshot of the problem:
Note the ground at Tidus' feet.
if you could find out id be greatful :)
I apologize, after testing I have found that the glitch was already present in r4238, and it doesn't look like there have been any changes that could affect that apart from these three in some time.
While I don't recall seeing this glitch before, I could have simply missed it previously. In any case, I don't recall what revision I was using previously.
Nps, when you find out, submit an issue :)
First Gungrave game still isn't working. The screen goes to black after the Red Entertainment logo plays out (which is before the games intro).
Well Gungrave Overdose works. The first one you can bypass the logo error with speedhacks but it still freezes when you're supposed to take control over Grave.
okay ill need to speak to shadow lady on that one then
@armin: Which speedhacks are you using to get past the logo error? I've tried enabling all of them in different order (mixing them up and everything), but the game still goes to black after the Red Entertainment thing. I couldn't even get past it when in software mode with all of the speedhacks on/off, in DX9 or DX10 mode.
@refraction: Here's a thread I submitted on the PCSX2 forum for Gungrave... http://forums.pcsx2.net/archive/index.php/thread-17672.html
...if that helps at all. Also, the latest official build that Gungrave has worked on from start to finish is the 0.9.6 one. Every other official/beta build from that point on, the game crashes within the first 10-15 minutes of being in the game.
I used all speedhacks except Enable fast CDVD, mVU Min/Max Hack and Vu cycle stealing. Yeah I know it's weird but when I disable all speedhacks the game freezes at the logo. I first thought Skip MPEG fix would help but that just freezes the game when the intro animation should play. But again it still freezes when you're about to take control over Grave. He pulls out his guns and points them and you stare at that screen forever. Speedhacks on or off it still happens.
Huh, still no luck. I tried enabling/disabling the same speedhacks, but it still isn't getting past that logo. Even under software mode. Might be another setting that's letting you get past that part. But yeah, that is pretty weird.
The game's compatibility seems to be systematically lowering though, as the revisions go up. The game could be played from start to finish on 0.9.6, but in the later revisions (1888), you could only make it to like the second stage before the game would freeze up. On r3119 I think it was, you could only get in the game for about 5 minutes or so before the screen would become all garbled and whatnot, and the game would crash. On r3878, you could actually get past the logos and the intro cinematic, but once you get to the main menu, the screen goes black and the game crashes. Now it seems that you can't even get past the logos.
well I don't know. I know it's the speedhacks. Coz without them on it won't work. Everything else is defualt options. Yeah that game is pretty weird there.
Look if you're going to talk support, can you take it to the forums please, this isn't the place for it.
We aren't talking support, we're talking about how the game still isn't working, even though you said it "fixes Gungrave" in the revision description. I just felt like pointing out how the game was still incompatible to backup my review (from what I understand, no one likes getting something other than a positive without a reason why). I didn't want to say it right away until I at least tried armin's solution for being able to get in the game, so I could have changed my review from neutral to positive if it had worked.
Well yeah that's all I was pointing out. Gungrave still doesn't work.
I also added (underneath) that it was just Gungrave OD that i was sure of, to quote
"Note: This might only fix Gungrave OD, i dont have any other version :("
Im sorry you're dissapointed, but if you want to talk about how to make the game work in the current state (to best you can) The forums is the best place for it, not here, the conversation is in no way benificial to myself or this commit.
Sorry ^^' All I was planning to say way that Gungrave still doesn't work but it kinda went out of control.
First, I'm not disappointed. As you can see from my review, I'm neutral. I don't care one way or another. I just thought I'd point out how it still doesn't work, since you aren't able to check it yourself.
Second, like I said, I wasn't trying to start a support discussion about how to get the game to work. I'm just seeing if armin's method of enabling speedhacks really does allow the game to get past the logos and the main menu, in to the game itself. Like I mentioned, the farthest you could get in the game before this was up to the main menu, so I wanted to see if this commit would allow you to get past that or not. If not, compatibility would have gone down, if so, compatibility would have gone up (which, like I said before, would've warranted me changing from neutral to positive). Which brings me to my third point...
You don't think it's beneficial to know that this commit not only didn't fix Gungrave, but might have actually made the game even more incompatible than before? Or made it so that the only way you can get in the game is by enabling speedhacks?
Not trying to derail the discussion for this commit or anything, but you seem to be getting bent out of shape over a simple misunderstanding. We just tried to have a short discussion regarding where the compatibility for Gungrave stands as of this commit (did this commit make it more/less compatible). We weren't trying to troubleshoot the game in order to try and play it.
Im not getting bent out of shape, i understand you're concerned that the compatability is progressively getting worse, I will when i get chance look at the gungrave you are worried about, i will get shadowlady to help. The comments here are mainly made for pointing stuff out (which you have thank you) however the conversation has continued in to kind of a how to make it work now which isnt really helpful from my side, it either works or doesn't from a programming perspective.
So please, all im asking is to keep discussions to the forum and quick informative remarks here. As you've already made a thread as posted above, that would be an awsome place to take it from :)

Revision 4242

Patch from Jake: On some scenarios EmuCore config would be saved to both vm.ini
and ui.ini.

Revision 4243

cmake: do not separate gmo file by lang directory (issue to create the
l10n: update zh_TW (remove extra \n)
Looks good...

Revision 4244

zzogl-dev: Update to latest trunk.

Revision 4245

cmake: add a L10N_PORTABLE option to allow installing the file in bin/Langs (no
superuser right needed)
The option is on by default.
Note: pcsx2 does not detect yet mo file on linux.

Revision 4246

Presets: better semantics on arguments.
hey dude, i dunno if you check your gmail but, can you check your gmail? :P
Fashionably late :P

Revision 4247

Patch from Jake: Make sure both ini files are created together when
changing/setting settings folder. previously: vm.ini creation was skipped here.
Hello, this change actually activates a bug since the function SaveUiSettings() called by the newly added line AppSaveSettings() gets called for the first time at that particular spot in the code.
I do a clean install in linux (but probably the same in windows have not really checked) , open PCSX2 and run a valid iso with all settings on default. I close the program and open it up again. I then go to Config -> Plugin/Bios Selector and just hit OK to close the windows and the program "hangs". Basically all three buttons (cancel, apply , ok) get disabled but I can keep changing stuff if I want to in the windows but those three buttons stay disabled and I can't really close the configuration windows. Only way to fix this is to kill PCSX2 and remove these lines from [email protected]_ui.ini:
But whenever Filename00 gets recreated the same behavior happens. Since I backup my settings and rarely changed them I did not notice till now but I was testing something and decided to change the sound plugin and noticed this behavior on r4261. I compiled a few revisions and found that this commit caused this behavior.
Also a quick hack/change to fix this is to go to line 1045 and change it from:
sApp.GetRecentIsoManager().Add( g_Conf->CurrentIso );
//sApp.GetRecentIsoManager().Add( g_Conf->CurrentIso );
This made the bad behavior disappear but it's probably not the fix we want.
Summary of the issue since I rambled too long:
Whenever [RecentIso] is on the configure file PCSX2 hangs when hitting OK/Apply in the components selector windows. Tested on Linux, have not confirmed on windows but I will reboot check and report soon.
r4263 works fine in windows. So the problem is in Linux only.

Revision 4248

i18n: on linux seach l10n file also in Langs directory
Note: Langs will also be easier for a tarball release than /usr/...
Running pcsx2 direct wrong, Reset setting is invalid
windows crash
Problems of signature:
Name of the problem: BEX
Application Name: pcsx2.exe
Version of the application:
Application of time - stamp: 4d3b1e3a
Fault module name: StackHash_0a9e
Fault module version:
Fault module timestamp: 00000000
Abnormal deviation: 00000000
Exception Code: c0000005
Abnormal Data: 00000008
OS Version: 6.1.7600.
locale ID: 2052
other information 1: 0a9e
other information 2: 0a9e372d3b4ad19135b953a78882e789
other information 3: 0a9e
other information 4: 0a9e372d3b4ad19135b953a78882e789
Version r4248
The system is 32
windows 7
Did previous version r4247 work ?
I just tested. 4247 doesn't show this ssertion, 4248 does ("Devel" build, windows xp 32):
Compiling and running on windows, I get the following assertion when running:
..\..\gui\AppConfig.cpp(227) : assertion failed:
Function: AppConfig::FolderOptions::operator []
Thread: Main/UI
Condition: false
Message: Incorrect usage of jNO_DEFAULT detected (default case is not unreachable!)
Yes, I found the issue, I need to do more duplication of code...
Avihal could you give a quick test on rev 4252. I really need to find a way to compile windows versions...
What configuration panel do you have ? On my side, I get only Emulation setting, memory cards and plugins/bios selector ...
r4252 seems fine - no assertion. I'm not quite sure I understand your question, but I think I have the same panels as you:
From Configuration menu: Emulation settings, Memory cards and Plugins/bios selectior. The last 2 options open the same dialog but at different "tabs" inside it, and the Emulation settings opens a dialog with 6 "tabs".
Come to the irc channel if you need some more tests.
Ok I found the panel it is only appears on debug build !

Revision 4249

debian: add a "pcsx2-l10n-unstable" package + some refresh

Revision 4250

debian: forget 2 files

Revision 4251

Presets: Bugfix: 'Enable Patches' system-menu item is now properly aligned with
presets behavior.
- previously: was always not-grayed-out even if presets were enabled, and would
get applied on only next restart if set only by preset.
- Also, the presets system now nicely supports menu items too.
"Wait for vsync on refresh" is always grayed with presets, don't see why the need for that.
"mVU Block Hack" should never be enabled in any preset, I have at least 5 games that get slower with that speedhack, it really depends more on the game wetter it'll speedup or slowdown so not good on a preset even tho it's safe (no point forcing it if it can actually slow down your games, no?).
"mVU Flag Hack" should be enabled since the "Safe (faster)" preset, higher presets change the cycle speedhacks.
"EE timing hack" can actually kill some games and slowdown others by a lot, not sure if this is needed in a preset at all.
Hmmm... should have created an issue for presets instead... oh well :p
vsync is disabled and grayed out in presets because it can slow games down, and I thought the presets should have the least "interferences" for a fast setup. Once a reasonable setup/preset is found, presets can be disabled and vsync enabled while keeping the rest of the options at last preset.
re: mVU block hack and Flag hack: rama, pseudonim and myself (I mostly listened) tried to find such presets that would span a nice range (highest agreement rate we got was 66% for preset 1 - safest! :P ), and I think the current ones are not too bad.
However, two things:
1. There can never be a set of presets that would gradually speed up all games. Some would definitely break along the way, and we have to set them such that it has the best impact overall (very hard to measure or assess).
2. I'm completely open to any set of presets. In fact, you and the others probably know much better than me what presets to choose, what options would be too bad to be used widely, etc. What I do think is that the range should be wide (as in: break games at the "upper" presets). Not for the sake of breaking them but rather to let the users know they can get beyond the "limit" of a good setup.
Other than that, and set of presets which gets a consensus, I'll gladly put instead of the current set.

Revision 4252

i18n: Fix assertion crash of my previous commit. I recreate all logics for the
folder option to avoid issue with jNO_DEFAULT
Note: now it will be easy to add a folder selection in the appearance panel (if
still exists, it does not appear on my system)

Revision 4253

pcsx2: i18n: move Langs folder relatively to the application root instead of
user data.
Yes, this is the more correct and expected default behavior.
On a semi-related note, I had considered having pcsx2 search both AppRoot and Documents folders for languages; on the premise that it might be easier for devs and translators to throw things into the docs folder.. but eh... prolly better to just stick with the simple approach unless there was some definite need displayed for that.
Yes better keep it simple. For linux (do not know windows behavior) they can also puts them into $CWD.

Revision 4254

Configuration dialog: The 'Apply' button is now disabled when the dialog is
opened (was only being disabled after clicking it, rest of the dialogs were
behaving ok).
- The automatic disabled Apply on open didn't work for SysConfigDialog because
GSWindowPanel and VideoPanel were using SetValue for text boxes when they
initialize, which triggered a "SomethingChanged" event (it captures, among
others, the wxEVT_COMMAND_TEXT_UPDATED event which is also triggered by SetValue
for text boxes). The solution, per wxWindows docs, is to use ChangeValue
instead, which doesn't trigger this event.
Good find! I didn't know about ChangeValue.
Me neither ;) And it's also a bit*h to debug events and their source (which I haven't eventually, and instead applied some common sense and elimination techniques).
To debug events, make sure and download the microsoft symbols.
Run PCSX2 from MSVC, and go to Tools->Options and open the Debugging panel. In there you can download symbols. Downloading symbols will fix the broken stacktraces when you place breakpoints in code that runs from windows events.
Will try that next time. thx.
You'll still have some trouble (sometimes) tracking the actual source of the message if its a queued message from another thread -- for threaded message tracking, there's really not much you can do except utilize message queue logging analysis.
But for GUI-to-GUI messages it usually helps a ton, since those are all on the GUI thread and usually run immediately, and not posted through the queue.

Revision 4255

zzogl-dev: Copied a few changes to zzogl over. Tweaked the logging code.
Commented out a logging message, and removed some extraneous endline chars.
I hope that GLSL shaders is working for you now.
Just wanted to ask what's the general plan with zzogl-dev? Are you converting it to GLSL-only, dropping all the Cg code?
Makes sense to me, since all GPUs that are fast enough for pcsx2 have GLSL support anyway. And the open-source drivers should catch up pretty soon (I think currently GLSL 1.30 is still a problem).
I thinks there is no plan ;) For the moment the idea is to keep both.
For linux package distribution, GLSL is better.
1/ fully open source. CG is non-free on debian.
2/ better support of amd64 (no need to have 32bits libraries on amd64 system)
For me, it must not have any performance impact, but it might be interesting to do some bench. Well it depends on the shader compiler not the gpu.
In my opinion, open source driver will probably need 2+ years to be usable on PCSX2. Some extensions have some patent issues. Moreover the performance of the drivers is really bad and the driver is cpu limited which will be killer for the emulation (except it can uses core not used by PCSX2). Open source drivers will be very nice to help debug and profiling in gl call.
You still need libGL and most of the graphics stack in 32bit format to use GLSL (or OpenGL in general), so I don't think 2) is a valid point. Yes, you won't need the Cg toolkit in 32-bit but that's a rather minor issue.
Some extensions have some patent issues. <- Which ones? You're talking about s3tc and floating point render targets? I think these are available, if you just compile mesa with the correct defines enabled. s3tc needs some external lib, but that's all.
Moreover the performance of the drivers is really bad and the driver is cpu limited which will be killer for the emulation (except it can uses core not used by PCSX2). <- Again, which ones?
I'm using r600g (gallium) on a HD4750 (RV740), which is picking up some nice speed recently. The r300g development is even more interesting, according to some recent Phoronix benchmarks the open driver is now outperforming the proprietary one in some cases.
But you're right about the CPU-bound bottlenecks. However Jerome Glisse is going to work on these shortcomings in the mesa statetracker in the next weeks and months (there are already testcases available).
Hopefully this is going to remove some more bottlenecks. Also keep in mind that:
1) r600g doesn't use tiling by default
2) Z-buffer compression also isn't used
3) The GPU shader code assembler is rather simple
4) LLVM could be used to optimize GLSL IR
So lots of performance still unused.
I wrote GLSL support as an experiment to move from proprietary solution. It could be important for porting from linux to other x86 oses (MacOS have a bit NividiaCG issues). Also it was a part of rewriting ZZogl based on OpenGL 3.0 standart, rather than OpenGL 2.0 with a bunch of ARB's.
Anyway, I am not planning to remove HLSL shaders support anyway.
For the point 2, distributions already provided the 32 bits graphics stack not the Cg toolkit (at least on debian/ubuntu). And cg is really painful on launchpad, I cannot use the distribution package...
I do not know the details of patents, but yes it was float stuffs. If you need to recompile mesa, for me it is not easy available. In most country there is no patents anyway.
Yes I know there is on going work. In my opinion a powerful video card will compensate the driver. If I'm correct John B. said that they target 50% of the proprietary driver and r600 is much more complexe than r300. Yes they are rooms for improvement but that need lots of time and man power. For the moment I'm only afraid on the cpu usage which is critical for an emulator like PCSX2. However I'm truly interest on the opensource drivers status. It is the main reason why I bought an AMD gpu (HD5770).
@Zeydlitz: No, unfortunately. I'm still fiddling with it on and off, though.
And it would be nice to use GLSL instead of the cg toolkit, if nothing else, to remove a dependency. We'll need something that runs dependably for both Nvidia and ATI, though, and for the immediate future, I'd imagine we'll have them side by side.
I'm using a nvidia GTX 460, btw, and had been using an nvidia 8800 GT before that. (And I have a graphics card laying around that I think is a 8300 or 8400. I thought I had an ATI graphics card around somewhere, but it hasn't turned up.)
It's strange, because I have both ATI and nVidia cards, and ZZogl is working with proprietary drivers on both of them. And as I recall, you using debian as I am.
Actually, you're thinking of gregory on that one. I'm using funtoo.
And it is possible it could be a difference in driver version, or some library version, or something. I may have to see if I can set up a small partition with a simple Debian or Ubuntu install to test with the same hardware and a different distribution. I just hate resizing partitions, even if I do have the free space.
I have tried updating my nvidia driver, and compiling a simple test program to make sure GLSL shaders actually work on my computer, btw...
I was going to test on my laptop, which uses a built-in Intel graphics card, but it isn't exactly capable of running pcsx2 at a reasonable speed. :)
On intell, as I think, GLSL should not work. If it crush, check than CreateShader call is exist (I found, that some drivers does not provide this functionality).
Intel mostly wrote the new GLSL compiler for mesa. Of course GLSL isn't supported on i915-based GPUs but it works for i965 (Arrandale and Ironlake cores e.g.). Like I said above, the only problem is GLSL 1.30 support:

Revision 4256

pcsx2 gui: restore the "folders" panel in Appearance menu
The folders panel used to be in the Plugins/BIOS selector window, currently it's the only element in the "Appearance" window which kinda doesn't make sense since it kinda doesn't do anything for the appearance :p

Revision 4257

Removed FTZ and DAZ options from the EE and VU panels.
PS2 behavior is the same / close to always on, so having them optional got

Revision 4258

Portable-install change: Renamed the file PCSX2 looks for to know when it should
run in portable mode.
The new file name is simply "portable_install" (no file extension).
Since it doesn't have an extension anymore it won't look like there's something
to configure in it.
For the portable mode
It does store information in the empty file "portable_install" after finishing the FirstTime Wizard. The example of my "portable_install" opened with Notepad:
IMO the prvious behaviour is fine for portable install since it's natrually portable, given inis, plugins, themes(new path stored in "portable_install" in above example this time) as relative path to pcsx2's main directory. And it detects whether inis\PCSX2.ini(now they are PCSX2_ui.ini and PCSX2_vm.ini) is present or not:
If PCSX2.ini exists, boot pcsx2 normally.
If PCSX2.ini doesn't exist, boot pcsx2 into FirstTime Wizard.
What I expect is if either PCSX2_ui.ini or PCSX2_vm.ini is missing, running pcsx2 will boot into FirstTime Wizard.
So if people wanna rerun the FirstTime Wizard and configure pcsx2 from scratch in portable install mode, they'll delete PCSX2_ui.ini and PCSX2_vm.ini, then run pcsx2.exe.
I also tried clear all settings(Config -> Clear all settings...) but that will delete the empty file "portable_install" and then PCSX2_ui.ini and PCSX2_vm.ini left in inis folder, I think the expected behaviour is deleteing PCSX2_ui.ini and PCSX2_vm.ini upon clear all settings.
Whops. I decided on this change when the ini didn't store stuff yet.
Thanks for the heads up, will fix it asap.

Revision 4259

- Added missing FrameSkip gui code so skipping works now when you select it ;)
(Implementation is a bit clunky. Might change it later to look a bit nicer,
might not.)
- Changed a few more dialog layouts a bit.
- Prevent changes to the PAL/NTSC "base frame rate" in release builds.
(It's still possible to edit via pcsx2.ini or in devel/debug builds. And yeah,
sorry Shadow Lady :p )
Ehr, and also made F10 available in devel/debug builds again.
It toggles SysLogging as usual.
(I figure that it's convenient to have, even though we don't currently do rec resets before enabling logs (as the comment suggest)).

Revision 4260

And a small one last:
Changed a warning many users misunderstood as *Serious Problem* so it sounds
(lots) less severe ;)
Thank you! lol, i keep meaning to do stuff like this, another one on my "could possibly do" list was to remove the "EROM Not Found" type warnings and only have them display when one is found, kinda like old amiga games did with extra ram, people get so worried when things say they arent found ;p
Yep. Countless forum topics with titles like "PCSX2 error", when the problem was simply stuff like this :p

Revision 4261

Bames database: forcing Ico to VU Clamp mode = Normal (otherwise the camera gets
weird occasionally).
Shouldn't the forced settings only be the ones that don't work fine by default? Normal clamps are the default settings, if users change it... well that's on their own doing.
I guess it doesnt hurt too much forcing settings we know work, however if i recall you need to change one of the clamps to full else the intro freezes, cant remember which tho.
Yep, that's FPU. It's already forced to full via the same patch though :)
This here is prolly done so the new presets don't break the game.
shadowlady: indeed. However, since setting VU clamp to none may give a nice speedup, it was added to the presets system (starting from preset 4 IIRC).
Because it may also break some games (e.g. Ico), I consulted pseudonim if I should remove this speedup option from the presets. His answer was that it gives a nice speedup so it should probably stay at the "unsafe" presets range. So that's how it is now.
However I still think that if we know that it breaks specific games, it would be nice to force it at the DB file even if that's a default option, such that it won't break on higher presets values. And so I did for Ico.
refraction: the ee clamp freeze thingy was already added to the DB file a while ago.

Revision 4262

Reverting R4258.
Didn't know we actually *do* save information now in pcsx2_portable.ini :p
It could at least be renamed to portable.ini, or something. I dunno why I felt compelled to add a 'pcsx2_' on the front. I was crammed in the fuselage of a 737 jet at the time. I wasn't necessarily thinking clearly :p
It still stores information in pcsx2_portable.ini, exactly the same content as I commented in r4258(according to the path where pcsx2's main directory is, here is R:\0.9.7):
The most severe problem is that the pcsx2 is not REALLY portable, if you rename the folder of pcsx2's main directory(the effect is path changed), run 0.9.7 it complains GS plugin not found(because base path changed of pcsx2's main directory).
I tested r4282 under Windows XP SP3 Taiwan version(i.e. non-English OS).
I should have tested it earlier but I had thought the fix is perfect this time and needn't to test it.
Ok, thanks. The only option that's meant to be stored there is RunWizard -- the others I wanted to be low-level hacking options that a user can specify manually if they really wanted to -- but they aren't supposed to be saved to the ini. wx's "create missing entries" option needs to be turned off when working with the portable ini. Should be a quick fix.

Revision 4263

zzogl: align_16 array before sse2 instruction + minor stuff
That takes care of the Mana Khemia crash issues on my computer.

Revision 4264

Games DB: Ico (all versions): r4261 was setting VU clamp to Extra instead of
Normal. Fixed.

Revision 4265

zzogl-dev: A few tweaks to the GLSL header code I hadn't gotten to. Fix/comment
out some asserts. Move the extension line to a better place.

Revision 4266

pcsx2 gui: move around the "folders" panel. Remove an useless menu
Ok for now :)

Revision 4267

Fix for the Gungrave everybody wanted. Was a small programming error in GIF
MFIFO, now fixed :P
Works again, thanks for looking into the issue and fixing it.
you're welcome :)

Revision 4268

GIF MFIFO: Wrapping of MADR and TADR when transferring from the ring itself.
Fixes Front Mission 4
This really worked.
FM4 becomes playable at last, congrats :)
bring the game fixes refrac. :D
Im on a mission, trying out my new product, i call it "Regression-Be-Gone", so far it works pretty well :P
More and more good news XD
refrac, good mission. :P
Yeah, your product is always good !)))
Thanks man !!)))

Revision 4269

pcsx2 gui: really postpone appsavesettings the first time

Revision 4270

- fixed VS2010 project files and added configuration for AVX
- ConfigIcon_Appearance.h seems to be missing
AVX does not do much yet, about +1 fps in sw mode. First xbyak has to be updated for VEX, then I need to re-write the rasterizer to use 3-op instructions. The ymm regs could be useful for extra storage in the upper part but that's all, no integer instructions available in AVX 1.0.
lol welcome back dude :P
its legendary gabest! oh yeah!
Got myself a i7-2600, the new baseline cpu for pcsx2 :P
Good to have you back :D
omg he's back again! cant wait to see new work in gsdx:D
welcome back
welcome back gabest dude.
ConfigIcon_Appearance.h is generated from png files as a build step, same as the other ConfigIcon_* files.
HOLLY SH*T !!!))))))
GSDX will live !)))
Welcome back!, All pcsx2 fans waited for this moment.
Welcome back gabest. I missed you!
Mere mortals greet you, God! xD
wb, gabest. great rig you got there.
Nice, everything compiles right except ZZogl in VS2010 now; thanks, gabest. ;)
Great Work! Thanks!
But I also noticed another problem: That's when I Compile PCSX2 using VS2008, I got the release can run on x64 win7 only with VCRedist(x64) installed, But when using VS2010, I got thr release need VCredist(x86)
I wang to know why dose it happen?
ZZOgl plugin can not compile in vs2010
Error message:
aviUtil.h (415): error C2664: "MessageBoxA": can not convert parameter 3 from "const wchar_t [1]" convert "LPCSTR"
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
1> c1xx: fatal error C1083: Can not open source file: ".. \ memcpy_amd.cpp": No such file or directory
Only the project - Properties - Configuration Properties - General, the character set from "using multi-character character set"to "Use Unicode Character Set" does not appear in vs2010 error C2664: "MessageBoxA": can not convert parameter 3 from "const wchar_t [1] "into"LPCSTR"information
Nice to see you around Gabest. Hope you enjoy this Sexy Sandy Bridge.
Set ZZOgl project to use Unicode.
so i heard you´re supposed to be a guy who knows a lot about gsdx, so does that mean you will look into the current bugs in gsdx?namely the fatal frame 1 and 3 hardware problem and silent hill 2 and 3 chopped screen prob?
that would be awesome!!!
Great to have you around Gabe.
nice work great

Revision 4271

added missing ConfigIcon_Appearance.h to the project file
Thanks for the help, always appreciated :)

Revision 4272

I was bored tonight so I updated the embedded portaudio to the latest svn. It
has some fixes for everyone, check portaudio's svn log from 1541 to 1570 for

Revision 4273

pcsx2 gui: do not call swap iso when isofile did not change.
Note: the code avoids some locking which turn into deadlock with GSOpen1
It must be fix the issue 940

Revision 4274

wiki: linux compilation guide update (new package on debian and ppa link)

Revision 4275

* Update TODO and README with latest new.
* improve the support of l10n

Revision 4276

GSnull: Dialog box fix.
When build with cmake, these symbols weren't getting exported, so instead of bringing up a dialog, it was giving errors on the console when you try to configure it. Not that there's much to configure on GSnull, anyways.

Revision 4277

Presets slider: added minimum size (there were complaints that it's barely
visible in Linux).
If you happen to test it on linux, please let me know that the presets controls
appear and are usable (checkbox, the word 'Preset', a slider that can be set to
6 positions, and a colored preset name)
Thanks. I have a nice slide bar on linux :)

Revision 4278

PATH3 Masking: Tweaks mainly for Path3Masking to fix TOCA3, This is the best
Path3 masking is ever going to get, there might be an occasional glitch, but
nothing major *fingers crossed*, Now have the ability to log Path3 stuff
seperately which will help if problems do arise.
Cleaned up Gifdma a little, removing duplicate code. Disabled a few console
writes we dont nee really.
someone remind me what TOCA3 is?
TOCA Race Driver 3
Yeh that one ;p
Yeh that one ;p
Uh... this one killed KillZone Oo
Urf.... i checked all the other usual ones too >.< alright, ill check it out later ;p
damn finniky stuff
It might have also broken the spiderman thingy you asked me to check few days ago. Or at least, with this revision I'm unable to get past the loading screen after pressing Start.
Confirmed, spider-man also broke with this revision.
okay ill check that too, now that the freakyness doesnt happen ;p

Revision 4279

zzogl-dev: Update to latest trunk.

Revision 4280

pcsx2 i18n:
* add/update various translation
* add a patch of Weimingzhi to fix wrapping issue on asian languages.
I need to update my translation (Turkish) :) I just need some help about it.
Well, tell me what do you need ?
I need pot files of the latest rev, I can't find them. I've checked svn directory. The templates there are actually the ones I translated :)
Also I'd like to know how I can import translated parts from the old pot files to the new ones. Thanks.
Note: I'm on linux. Try also to read the various wiki https://code.google.com/p/pcsx2/w/list
1/ svn checkout http://pcsx2.googlecode.com/svn/trunk/locales pcsx2_locales
-> this part must be done only once
2/ svn update pcsx2_locales
-> update the file with latest modification
-> pot file are in the templates directory. Note potentially there are not aligned with latest code but that not critical for the moment. Well I guess I need to learn how is it working :p
3/ Try to play with poedit. I think on linux you can use msgmerge but I'm not sure.

Revision 4281

Fixup Spiderman and Killzone from r4278
Thanks man !!!
Killzone is the one of the best games for PS2 !)))
Hey i broke it, dont get too excited :P
Usually if something breaks, its killzone, i really should have this in my QA testing before i upload changes :P
Hey, just my opion, but would be a smart move now the KZ3 is coming out.
Should give PCSX2 even more ackknowledgment. Not that it really needs, the emulator is amazing. Anyway, i was just thinking out loud. ;)

Revision 4282

Small Hack to prevent games which check the QWC/MADR for the end of a DMA
transfer (instead of the BUSY flag, why???) from start writing the next transfer
before the previous had finished, causing errors in some cases after the DMA
write while busy prevention was added (Street Racing Syndicate)
It would be probably more accurate and nicer to have the transfer do the cycle delays every 8 QW, drawback being that would be a lot slower, which would cause complains, so this is a sort of "comprimise" where it works similarly to how it has for a long time, but providing a "still transferring" look towards the end of the transfer.
why not have it not report it is finished until the BUSY flag is gone?
thats essentially what ive done. usually QWC gets set to 0 cos its been transferred and thats all it cares about, it completely ignores the busy flag which is frustrating as that's what it is there for >.<
ah, k

Revision 4283

zzogl-dev: moved a bit of code from NewRegs to Regs, moved commented versions of
some of the rest over, and got rid of NewRegs.
I figure I can gradually filter in the other changes if I think they are worthwhile, and I haven't done anything with NewRegs in long enough that I thought I'd get rid of the code duplication. Half the changes are in Regs now anyways, and the others aren't mainly because I want to examine the logic, and make sure they aren't messing anything up.

Revision 4284

zzogl-dev: Get rid of fta. Add and use a few enums. Play around with

Revision 4285

zzogl-dev: Organised the framebuffer code in ZZgl.h.
is not equal to
There is ptex missing.
Ah. Must have missed it.
Thanks, I'll fix that.
Taken care of.
An additional minor thing.
1 line-by-line comment
line 165:
165: FB::Bind(); // switch to the backbuffer
The code is not aligned with the comment. Either the comment can be removed or you must call unbind.
Looks to me like it's the comment that is wrong. In fact, it seems to me that I noticed at least one of the comments didn't correspond with the code, and forgot to remove it...

Revision 4286

zzogl-dev: Fix a mistake I overlooked in my last commit.

Revision 4287

Mostly code cleanups, XBYAK 2.99, VEX conversion for the sw renderer (3-5%
faster), GSState::Move fix for dark cloud 2 invention crash.
Congratulations!!! you are the best!!
Just wanted to say that AVX 1.0 is hopeless, the instruction set is full of holes, vzeroupper is worse than emms (using ymm, then xmm, no vzeroupper, extreme penalty), but the biggest WTF is that unpacks/shuffles/permutation or anything else cannot move data between the two half of the ymm regs. My every attempt to make shorter code (and hopefully faster, vtune 2011 isn't AVX-ready...) actually results in the same length, because a lot of vextractf128/vinsertf128.
However, the CPU is already fast enough to run almost anything at full speed :)))
4>.\GS.cpp(603) : error C2039: 'data' : is not a member of 'std::vector<_Ty>'
4> with
4> [
4> _Ty=uint8
4> ]
Finally a GSDX update, yay
nice :D
GSDX update of any sort is always welcome!
he's back! I love you gabest

Revision 4288

vs2008 compatibility fix
And thus I managed to avoid updating to a new version.

Revision 4289

cmake: add a PACKAGE_MODE option to reduce the burden of packaging

Revision 4290

debian: update the package with new cmake PACKAGE_MODE option
Most likely missed a "\" at the end of the DUSER_CMAKE_CXX_FLAGS line in the rules file.
Yes good point.

Revision 4291

linux: create a small linux script to properly launch PCSX2 from a desktop
Is chdir always/generally available on all distros,
and wouldn't $0 there mean: "launch_pcsx2_linux.sh"
making it chdir "scriptname"?
Or pehaps i am just tired and are missing something,
It is nice to see activity in the linux area anyways :)
I used dash shell to test the script so chdir is probably fine.
Good point for $0. It depends on how the script is launched.
absolute_or_relative_path/script.sh (good)
script.sh (bad) -> dirname $0 will be '.' I need to add an error message
Ah, my arch system does not have chdir atleast, it does not seem to be a stock coreutils/bash thing atleast. though there is a perl-chdir-package on the community-repo. https://bbs.archlinux.org/viewtopic.php?id=56761 <--
I do not know how it is in most dists though, so i couldn't say "who" has the exception :)
I like the work on these things in any case, keep it up :)
ok, I replace chdir.

Revision 4292

wiki linux compilation: update data for archlinux.

Revision 4293

wiki linux 64b: update archlinux data.

Revision 4294

* fix a missing \
* refresh the patch

Revision 4295

- more project cleanups and small code changes, also added the psx emu interface
- someone should check __xgetbv under linux (avx/fma detection)
gabest, did you take a look at the issues on gsdx on issues section?
Not since a year, d3d rendering problems will never be fixed without doing something fundamentally different. It's not that I don't have any plans, just still preparing for it mentally.
Thanks for your work Gabest!
Are your "plans" in relation whit software/CPU render or D3D/OGL?
gabest, i understand, thanks for the info and strength for you to make your plans come true.
Maybe its just me but I get an unresolved external relating to __xgetbv in vs2008 (feb2011 dxsdk)
GPUDrawScanlineCodeGenerator.obj : error LNK2001: unresolved external symbol ___xgetbv
x86emitter.lib(cpudetect.obj) : error LNK2001: unresolved external symbol ___xgetbv
GSDX VS2008 Compile OK Not found error
Please update DirectX SDK and Windows SDK
Temporary files not cleaned up?
hmm odd, going to make the update to vs2010 anyways since it seems to be mainstream now (even dolphin dropped vs2008)
I checked with VS2008, it compiled. Maybe it's because I had SP1 installed.
Hi guys,
My compilation under windows 7, using vs2008 is failing like Konaj's,
it was compiling fine just before this update, though. Below is the log, seems like it's failing to find the "xgetbv" function:
1> Creating library C:\Users\BloodyShade\Desktop\ps2\pcsx2\\bin\plugins\GSdx-SSE4.lib and object C:\Users\BloodyShade\Desktop\ps2\pcsx2\\bin\plugins\GSdx-SSE4.exp
1>GPUDrawScanlineCodeGenerator.obj : error LNK2001: unresolved external symbol ___xgetbv
1>C:\Users\BloodyShade\Desktop\ps2\pcsx2\\bin\plugins\GSdx-SSE4.dll : fatal error LNK1120: 1 unresolved externals
1>Build log was saved at "file://c:\Users\BloodyShade\Desktop\ps2\pcsx2\plugins\GSdx\Win32\Release SSE4\BuildLog.htm"
1>GSdx - 2 error(s), 0 warning(s)
2>x86emitter.lib(cpudetect.obj) : error LNK2001: unresolved external symbol ___xgetbv
2>C:\Users\BloodyShade\Desktop\ps2\pcsx2\\bin\\pcsx2.exe : fatal error LNK1120: 1 unresolved externals
2>Build log was saved at "file://c:\Users\BloodyShade\Desktop\ps2\pcsx2\pcsx2\windows\VCprojects\Win32\Release\BuildLog.htm"
Compiled here too in VS2008, had SP1 as well tho :p
Compilation works under WIn7 64bit. (VS2008 with SP1)
The build works fine for me. Anyone with linker errors should make sure that they clean the solution before building.
gsdx sse2, ssse3, sse4 compile all of the normal
Please check the c + + include directory and lib directory is set if there are problems
Security software may also cause an error
clean the solution before building
same problem as [email protected], using VS.net 2008 without SP1
The the solution is simple, install SP1, you should always keep your VS up to date anyway! No reason not to.
refraction and the others are right, I just installed sp1 and tried and it now compiles correctly. Thanks for the info guys.

Revision 4296

zzogl-dev: Break targets.cpp into multiple files.
This probably still needs a bit of cleaning, and I might break up targets.h later...
nice, that .cpp file looks monstrous.
i can't stand looking at 3k+ lined cpp files :D
Yeah, it's always been a hassle to work with. I've meant to slice up targets.cpp for a while, and it already had several classes as a natural dividing point.
Of course, I'm sure I now have duplicated code hanging around, and targets.cpp is mostly misc. stuff that didn't fit cleanly in the new files, but that'll all get resolved with time...
Worse, it looks like a large chunk of what's left in targets.cpp belongs in ZZRenderTargets.cpp. It just wasn't included in that class. Though half of that is dead code that was left in for reference because some of it should actually be done in the new code, but isn't...
Really a good thing to split this too big file.

Revision 4297

Patch from Jake.Stine: portable/registered install modes fixes:
(Jake:) here's my final patch for the pcsx2 inis and portable mode stuff:
it removes the ability to modify paths in portable mode (patchs are fixed to cwd
anyway). Paths are still displayed for user convenience, read-only.
Also fixes some minor bugs and annoyances reported by users.
That should pretty well clean up most of what I broke when I rused the portable
install feature in a few weeks ago.
May want to review it first, I still haven't had much time or inclination to do
my usual amount of code quality control.
(avih:) I tested it briefly and nothing seemed horribly broken (read: looks OK
after little testing). Didn't do a proper code review though.
Now it's portable.ini instead of pcsx2_portable.ini for portable installation.
I tested the behaviour of portable mode is the same as prior to r4198, when the portable mode had not been introduced.
Ah, well-done eventually.
Yeah it was a complicated thing to implement, only in the sense that what was already in place was overly complicated and fragile. It would have been easier had we thought of this in the first place, since this system is mostly a simplification.
The big thing is that it should now work as expected when doing two things:
1) zip and move pcsx2 to a different folder, or run from flash drive, etc.
2) run pcsx2 from the command line in a folder outside pcsx2's home dir. (like c:\games\ or something).
Previously the custom/CWD dir method in PCSX2 would fail on both of those.
(and, of course, we don't lose the ability to install/use PCSX2 from standard non-elevated user accounts; which is a common courtesy in the increasingly paranoid and strict permissions environments of today's operating systems).
Why the negative emailgoo?
"1) zip and move pcsx2 to a different folder, or run from flash drive, etc."
This doesn't work as expected and will complain missing GS plugin, because two clusters of paths in PCSX2_ui.ini won't be automatically changed to reflect CWD after moving pcsx2 home dir to a new location and run pcsx2 from there(my pcsx2 working directory is R:\0.9.7):
Bah, I forgot about that. Those paths should be ignored in portable mode. Hopefully avih or someone can fix that up for you. It's pretty easy.
Jake, If you can describe in few words how the new system works and what are the main sequences, it might help..
Hey guys, i think you shouln't make the memcard folder readonly, a lot of people have more than one memcard folder, myself included and this is very annoying, i got no problem with the other folders being read only.
why do you need more than 1 memcard folder? just label your memcards..
@refraction, well is not that i can't handle the readonly folders it's that i've been using pcsx2 from a long time ago and i got various folders for memory cards (downloaded, cheated, normal, old, even some for specific games), and before this change i just picked the forder i needed and that was all, very easy, now it's not so easy...
Erg, yeah. This is one of the problems with portable stuff vs. user-local stuff. Namely absolute folders/dirs vs. relative folders/dirs.
Portable installs can have configurable paths, they just need to make sure everything is local/relative to the PCSX install dir. That ensures that its actually portable.
By definition, user-local installs should do everything with absolute paths because relative paths have potential security hazards, and cause Windows to require elevated user rights in some cases. That's why PCSX2 uses absolute paths for everything right now, because we had issues with that.
This is one reason why no one wants to develop software for PCs anymore. >_<
@Jake.Stine, yes, i agree with you about that, but then i don't see any diference between choosing the iso path and choosing a memory card folder path, and i'm sure that the first one will not be local/relative to the PCSX install dir. And as i said before i don't mind the inis, bios and plugins being readonly, i even think they should be.

Revision 4298

linux: avoid some corner case in the linux launcher script

Revision 4299

linux: launcher script v2. Add another check and replace test by '[ ]' for
*sigh* Jake left the project? If so then I do understand why there is no more progress in pcsx2 project =/
It takes another train called real life. However there is still progress albeit slower.
Well, good luck to him. He did a great job.
I'm upset and now I have the real feeling of fear that pcsx2 will die unfinished, bcoz there is no real changes in pcsx2 since Jake left this project.
Good luck to the rest of team.
You know all emulator projects die unfinished ^^ Fortunately, open source project never die completely. Anyway do not worry, there are still devs for pcsx2 ;)
Hey, guys, there are progress happening - don't diminish the efforts of the ones that are still committing and improving the areas they feel like contributing too - solely because it is not in a particular area that happens to be "your" interest.
And i agree with gregory, open-source seldomly turn outright dead - there will be an infinite possibility for anyone to pick it up and keep working on it. :)

Revision 4300

linux launcher: replace chdir by cd for portability...
This script is progressing nicely, will test it some more when i get back home :)
As it is on arch, via the "pcsx2-svn" AUR-PKGBUILD, pcsx2 ends up in /opt/pcsx2/ as default, making it a bit iffy when it wants to create config-files.
Though i have just started experimenting with pcsx2 on linux, so i don't know much on how this is supposed to be originally.
What i did a few rev's back, was to move it to /home/prep/emul/pcsx2 anyways.
What about something like /home/user/.config/pcsx2/configfilesandsuch (or is that actually how it does work in other cases (i.e i'd "blame" the PKGBUILD script?)
And yeah, cd would work in all cases i suppose, i don't really know what chdir did in comparison though :)
Keep it up!
Chdir does minor additional thing, anyway I used to use it :) Probably csh-ish.
Ask the maintainer of pcsx2-svn ;) Actually I told him that it could cherry pick my debian patches. My patches update default path and support the $XDG_CONFIG_HOME variable.

Revision 4301

* clean old asm stuff
* include the generic immintrin.h for sse instruction (gcc load the good
instruction set from the -m flag)
x86 asm & cpp could probably be drop later

Revision 4302

cmake: force the unicode build of wxwidget
Note: requiere cmake 2.8.3 or above (no impact otherwise)

Revision 4303

* replace CALLBACK macro with EXPORT_C_ like others plugins
* fix missing g_bSaveZUpdate in debug

Revision 4304

Local static initializers are evil, avoid them like plague.
nice ;) i have a question, is there a a chance to port the software renderer to mac? Unless it's using some directx functions and it's inseparable from gsdx? Cheers :)
Disclaimer: I'm not Gabest.
All the renderers currently in GSdx use DirectX, including the software renderer. To work on the Mac or Linux, GSdx would need an OpenGL renderer to be written. Gabest started working on one at one point, but he doesn't know OpenGL, and none of the devs working on pcsx2 at the time really did, either. (For all the work I do on ZZOgl, my knowledge of OpenGL is pretty limited.)
As I recall, the initial code for that ended up getting taken back out of GSdx at some point.
I also recall a significant area of code that'd need some rewriting to actually compile in gcc.
And you'd have to write a dialog box, though that's minor compared to the other two points...
i see, well thanks for the clarification, didn't think that the software mode was using DirecX as well, maybe some day hehe :)
Is there diffrence in speed betwen OGL and DX ? I meaan not relevant for plugins.
Almost every part could be ported easily, there is one last step that needs d3d, when the one (or two) output image is blended on screen, that could be replaced by something available on the mac.
cool, this could be a good feature, i mean isn't 100% emulation (of the gpu) basically based on software rendering because there's just not enough to describe certain effects (functions) from the EE in DirectX? Eventually CPUs will be able to handle games with software renderer with more cores and stuff. Heck almost all games that i play on my machine run full speed in software mode and i prefer accuracy to hi-res, only game that struggles in Snake Eater heh ;)
I specifically recall that some of the GSVector code broke when compiled under Linux. I don't really recall the details at the moment, aside from the fact that it seemed like it would have needed a big enough code refactor that I didn't feel like dealing with it at the time.
It was one of these things where gcc was following the C++ spec exactly, and Visual C++ was being more loose about things.
It's been around a year since I last tried to get things compiling under Linux, though, so things could have changed...
Unless it was the union of different sized fields, I cannot think of anything major.
Since I couldn't remember it too well, I fiddled around a little to see what issues it gives me. Looks like it starts giving fits about having variables in anonymous structs and unions that have constructors.
(GSVector2i in GSLocalMemory was the place I observed the issue. There could be other places...)
I would check it myself, but where to start? :P
Any advise how to setup the project for gcc?
Assuming access to Linux, the easiest way is to make sure that you have codeblocks installed in Linux, and open up GSdx.cbp with it. That is an old codeblocks project file for GSdx I made a long time ago that's still in the trunk. It's probably missing files and/or has files that don't exist in it, but it's a good beginning point.
From there, just right-click on the project and build. You'd have to fiddle with other, more minor code issues before getting to the one I was mentioning, though.
The code I was running into was the spot in GSLocalMemory where it has an anonymous union with an anonymous struct, and the struct has two variables of the type GSVector2i. It errors out when it sees the variable declarations, because that class has initializers in it. (I tried commenting out the initializers, and it went past that point.)
Installed codeblocks on windows, now I see... The best idea would be to convert every vector constructor to some static create call.
This is going to be nasty :P

Revision 4305

Trying to isolate the rasterizer step-by-step, for better multi-threading in the
VS2010 working fine, this on VS2008 tho:
1>.\GS.cpp(387) : error C2039: 'back' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>'
yet another cpp0x trap :P
it's better to drop 2008 isnt it? dolphin already did it. ;) better than keep fixin every occasional error in 2008 or 2010.
As far as I know other devs still use VS2008 (not only for pcsx2), so no I don't think that's a good idea. Not everybody is eager to just drop everything to jump to the new stuff ;p

Revision 4306

Fixing typos...

Revision 4307

Minor changes:
- Added an EE roundmode patch entry for AR Tonelico 2 that fixes a fall through
floor bug
- Disabled an exception in the ISO file reader. It now continues working when it
runs into incomplete game rips (may need a review).
- Disabled 2 annoying logs :p
Thanks for you work Rama!!
good to see game fixes again.
Interesting, I never played ar2 long enough to notice that prob.
The iso loader thing, I might beable to check once a new public build comes out.
I've got 1 iso that doesn't load with the internal iso loader, needs the plugin ver instead.
So I'll check it sometime in the distant future.
Sounds exactly like my test case, yea.

Revision 4308

Tweaked the rasterizer to be about 10% faster in multi-threaded mode (2 or 3
threads), still far from optimal.
great work :)
Now it's guessing how many threads to use for each batch of primitives. Sometimes the threading overhead is larger than the actual time spent on drawing, I'm trying to heuristically find those cases, 32 lines / thread looks good.
sounds good, looking forward to next commits :)
>> Sometimes the threading overhead is larger
Why is that so?
Does this mean a 10% increase in performance for software mode only?
Either way, that's awesome...
Should net me a few fps in gt4...
It's for those with more than 2 cores. Just set rendering threads to 3 in software mode.
So are you starting adding support for the 3,4 cores as said you will be working in the future?? Keep the great work!! Very good :)
HOLY SH*%! ))) Its FASTER !!!
Multithreading !!! 8D
Only one question Gabest - will you work further on rasterizer acceleration ?))
You said that it is "far from optimal" and this gives us hope (^_^)
On my i7 2600 it only uses 40% cpu time, while HT isn't much help when the sse execution units are full, it should still reach 50%.

Revision 4309

Cache Emulation: Updated cache emulation for new VTLB, Dead or Alive 2 (Japanese
Version only) now playable. You can enable this under the Recompiler options by
ticking the "Enable EE Cache" box, however it will only work with the EE in
Interpreter mode. Also fixed some cache bugs from the old implementation.
Note: Once DoA2 is ingame (start of fight), you can switch to the EE Rec until
the fight is over with good speed! Hopefully one day someone will be brave
enough to implement it on the rec side so you dont have to mess about :P
nice work, great to see more games playable :)
I am very long dreamed about this game! Thank you very much ^_^
BTW you can use the rec in the menus if you wish, but you will need to change back to interpreter before you select your character, so it isnt totally worth it ;p
Nice, I hope to check this out sooner or later whenever the next public build is ;).
This is the copy I got:
"Dead or Alive 2 Hardcore (NTSC-U)[SLUS-20071].iso"
I assume it doesn't work as of yet, regardless this is a huge step I thinks.
I'll have to get my hands on the nippon ver then.
Yeh the slus one doesnt boot, it goes further now and doesnt crash, but it still doesnt boot :(

Revision 4310

Path3 Masking: Fix for Resident Evil Dead Aim (also fixed the occasional glitch
i mentioned in my last Path3 commit)
Path3 games looking great now :)

Revision 4311

Fixed many gcc errors, there are still plenty. Intel's compiler might be a
better alternative.
Got rid of those "contructor inside anon struct" errors and other minor non-standard things. There is only the __super keyword left I think. And of course everything which is Windows related.
Cool. I'll take a look and see what's left when I get a chance...
Oh, also, we could probably put back the _aligned32's. It just never got added to Pcsx2Defs.h on the Linux side. It should be a matter of copying the _aligned16 definition for Linux, and changing 16 to 32.
Any chance on getting it so you can use mingw/gcc in windows to compile a win32 build yet?
arcum42: I did not remove pcsx2defs.h because __aligned32, there were many other conflicts. The declarations GCC likes are usually under linux ifdefs, and those aren't visible for windows. Btw, it also did not like the way align was defined, it told me the attribute will be ignored unless I put it after class/struct or the type.
[email protected]: Not yet, I could not figure out why xbyak includes code from _WIN32 when it isn't defined anywhere. Could be predefined by mingw.
In my last commit I moved directx related things from GSDevice to GSDeviceDX, that was one more eliminated dependecy. We need a GSWnd for linux and it could be compiled more or less with the GSDevice-/GSRenderer-/GSTextureNull classes. The rasterizer has native windows threading, I still can't decide what to do with that, I just know I don't want w32pthreads. std::thread would be a better choice if vs2010 had it already, I will have to find a 3rd party implementation till then. (is there something smaller than boost?)
As far as GSWnd, in Linux, we'd essentially change all the HWND's to void*, and remove WndProc & OnMessage. Same goes for GPURenderer.h. I'd assume in GSRasterizer.h, all the HANDLE's would be dealt with similarly.
The thread code would still need to be dealt with. One of the benefits of pthreads is that it's cross-platform. There is a threading class in wxwidgets as well. (And if you find an implementation of std::thread for Visual C++, as of gcc 4.4, it is available if you compile in c++0x mode.)
Oh, and I checked, and there doesn't seem to be a gcc equivalent of _super.
I also get some errors about xbak_mnemonic.h having functions named and, or, xor, and not, incidentally.
For now I'm giving up on gcc, but with intel's I can already compile it 90% under linux.

Revision 4312

Just moving code around.
good work but you can fix the graphical issues from super robot taisen
“GSDeviceDX.cpp”: No such file or directory vs2010

Revision 4313

adding a missing file
[email protected], care to elaborate on WHY you negatived this commit? as the negative option says "Negative: I oppose this change, and I am willing to explain why." so what's the explination?
Guess he's just sad his Game didn't get fixed? From last commit comments:
"Comment by [email protected], Today (5 hours ago)
good work but you can fix the graphical issues from super robot taisen"
It'll get fixed some day with the D3D fixes. Don't wait for it though.
In the mean time use software rendering.
Ok but in the software rendering, super robot taisen is pixelated and very ugly, there aren't filtering texture in software mode.I must wait a long time for the D3D fixes?
Yes, you should wait.
Software rendering will Always be ugly, unless you put your pc through a TV like your PS2 does (software mode == exactly what the ps2 outputs). That will never be fixed. D3D might get fixed at some point. Try the forums, someone might be able to help you.
Always? What about some kind of special AA or/and other filters. They probably VERY cpu intensive, but maybe in the distant future...?
software rendering isnt processed like hardware, so you can't change the resolution or anything. Software rendering has the 1xAA option which is actually a feature of the PS2, but thats it..
thanks refraction and ramapcsx2 but in the forum nobody want help me
Roo: I can see why
pcsx2 don't have other filter like hq2x, supereagle or 2xsaI,why?
super robot taisen(alpha 2,3 and ogs) don't support the bilinear filtering i think
jfre1 why?
what,sorry i don't understand oO
Scaling filters "HQ2x, Eagle, etc" work badly on typical PS2 games.
We've tried adding them once, they gave a horrible result.
I can see one option to improve software rendering, but it's very complicated. The resolution of the scanlines could be increased by 2 or 4 times (by reducing the step size), the resulting extra samples could be stored to shadow copies of the 4 MB video memory, and when something wants to use the output as a texture or in a different pixel format the buffers could be merged, similar to the Resolve call for multi-sampled D3D render targets. The speed would be greatly reduced and the code would have to somehow remember which page is currently drawn with extra samples, and for real multi-sampling the rasterizer should process 2x2 samples instead (instead of 1x4 as now), but that just adds more troubles.
That sounded quite complicated alright. :p

Revision 4314

This one wasn't needed afteral :p
ah yes, sorry i forgot :P Got dragged to bed, you know what women are like!
Of course I do! Very well so. Obviously.
OMG, a new and improved excuse, I like it because it happens to everyone :D

Revision 4315

The core of GSdx is now compatible with intel's compiler on linux.
- GSWnd is not implemented, no config dialogs either
- no output, just the null device
- threading classes were not tested (my first experience with pthread)
Codeblocks messed up a few tabs, I have to realign them now :P
VirtualAlloc isn't implemented either. JIT compiled code won't run yet.
I'm in process of installing icc so I can take a look. Most Linux systems do use gcc, but as long as it's actually compilable, work on getting it to compile with gcc can always come later. I'm sure I could throw together a quick and dirty gtk+ dialog box on the Linux side.
Oh, and as far as VirtualAlloc goes, you might look in Utilities, and compare WinHostSys.cpp with LnxHostSys.cpp. That code uses VirtualAlloc on the Windows side and mmap on the Linux side...
It's probably not that far from compiling with gcc too, as before.
I also got a strage error message with hash_map, could be because it is not standard, for now I just defined it to std::map in stdafx.h.
I ended up running into some trouble getting intel's compiler working with codeblocks on my system. I'll revisit it in a bit...
It went surprisingly well here, just installed ubuntu, codeblocks, some packages, the compiler (wanted java for the debugger, installed that too), then only had to remove two automatically added switches from the project. I don't even know where and how it finds the includes or libs, lol.
The first helpful page I found was this one:
Yeah, I'm going to try it from my Lubuntu partition instead of the distribution I usually use. I installed that so I could test in a more mainstream version of Linux occasionally. (Lubuntu is basically Ubuntu with lxde instead of Gnome.)
I usually use Gentoo, but it seemed like it may have been either installing icc to a non-standard place, or providing an older version of codeblocks that wasn't set up for the latest version of icc.
One thing I did out of ordinary during the install, when it asked about the user, I choose the third option, so the whole thing was placed under my own home directory.
Well, got the intel compiler installed under Lubuntu, though I had to mess with the location of the binaries. (Biggest thing was waiting for the download, though, really.)
There was one thing I had to tweak to get it to install. In GSUtil.cpp, it includes svnrev.h, which isn't actually created under Linux. (I'm assuming you still had a copy from Windows...)
I just #ifdeffed it out, and hardcoded SVN_REV & SVN_MODS for the sake of compiling the plugin...
Too bad, because with a few modifications I got it compile with gcc now :)))
Any suggestions to auto-generate svnrev.h as on Windows?
I think it's actually just hacked around currently in pcsx2 and plugins, by only including that file if it is on Windows, and putting dummy variables in.
It'd be possible to write a batch script to do it. "svn info" gives you the information it would be based on. I think I recall setting something like that up for the old build system, and then never updating it to work when we switched to codeblocks.
It'd basically be a matter of taking the results of:
svn info | grep "Revision:"
extracting the number from it, and writing a quick header file around it. Probably isn't worth it until GSdx is working at least as a null plugin, though.
Glad to hear you have it working in gcc, btw. Compiling with the intel C++ compiler looks like it adds some dependencies that might be a pain for packaging...
There is something similar to SubWCRev, just found with google:
This is it actually, at the bottom of the page:
A port of SubWCRev to Linux.
Currently down for maintenance lol
Oh well, if it comes back up, we could grab the binary, stick it in the same area as bin2cpp, and create a build script that runs it before compiling gsdx.
Nice one!

Revision 4316

GSdx fix0red for GCC
Forgot about svnrev.h, consider this revision as WIP.

Revision 4317

... adding the missing GSdx project file for GCC...
I'm not familiar with the compiler switches of gcc. What has to be set for debug and release builds?
Mainly what you've already done. -g for Debug, so it includes all the symbols for debugging, and -O2 for Release, so that it optimizes the build. And switches to turn off any optimizations that cause issues with the plugins.
-Wall and -Wextra can be amusing if you want to see a million compiler warnings. -std-c++0x would be useful if you want to use things in the c++0x standard, like std::threads. -msse and -msse2 should be in there for using sse. -m32 tells it you are compiling 32 bit binaries.
If you use wxWidgets, you'd include this:
`wx-config --version=2.8 --static=no --unicode=yes --cflags`
Also, if you have any defines you check for for debug and release builds, you'd want to add them.
A lot of the ones you see in the codeblocks project for pcsx2 are switches to turn off optimizations that have historically caused issues, or turn on optimizations individually in some cases. A lot of that is legacy, though.
To use the new instruction of your cpu, you can also set -mavx (there is also -mfma4 and -mxop but I think it is amd specific)
Add also this warning: -Wstrict-aliasing, it will report a warning when the strict-aliasing optimization will broke the code... Can save a few a white hairs :)
Hm, I thought -march=pentium4 will make the compiler use sse2, without it intrinsics were not even visible (icc was not so picky). How is it different from -msse2? Codeblocks does not have those switches on the list.
AFAIK, vc++ handles pointers quite to opposite. I added those restricts because by default it assumes every pointer may point to the same memory and adds unnecessary extra steps to a simple copy from one buffer to another.
It does somewhere in the list, but I believe -march=pentium4 does turn it on, because a pentium4 would have sse & sse2. Forgot that -march=pentium4 was added. We used to need -msse & -msse2 before it was put in.
-march=pentium4 is basically telling it to enable a bunch of compiler flags for features specific to a pentium 4 compiler. -march=native is even nicer, because it enables flags for whatever cpu you have, but if you're compiling something meant for other systems, it probably isn't the best flag to use.
(And most of the binaries on my Gentoo install are compiled with -march=native. ^_^)
-msse2 -> enable sse2 intruction set.
March will optimize for a cpu. So it will enable sse2 and others things.
-march={cpu} : Generate a binary *only* for the specific cpu type (and later, compatible models [most later cpu's support earlier optimizations, or gracefully bypass them]). This flag should generate the faster code on x86 architectures. Fall back to the most recent (mainstream) model in your vendors line if yours is not yet available.
-mtune={cpu} : Tunes the binary for given cpu on x86 architecture. This means that the binary will still execute on a 386 (if it did in the first place), while also including optimization for the cpu supplied to the '-mtune=' switch.
Oh, forgot to mention -fpermissive. It basically lets you get away with things that would otherwise be compilation errors that they consider "bad code practice". This used to be required to compile pcsx2, but at some point all the code that needed it got rewritten.
Still compiles and works fine on Windows, too. Nice :)
Does the debugger (gdb) has a feature like visual studio to skip first-chance exceptions? I'm thinking of the many segfaults on pcsx2's startup.
The better I got: gdb will continue when a segfault occured but it does not work for all, I do not know why !
handle SIGSEGV nostop
[wx] /home/gabest/Documents/Projects/pcsx2/bin/plugins/libGSdx-dbg.so: undefined symbol: _ZN13GSLocalMemory14PixelAddress32Eiijj
Path: /home/gabest/Documents/Projects/pcsx2/bin/plugins/libGSdx-dbg.so
File is not a valid dynamic library.
ooops :D
My __forceinline was defined wrong. Now it loads!
Two issues with gcc.
1. It does not want to align GSVector4i on stack. The attribute is set on the class. This will randomly crash:
GSVector4i v = (GSVector4i*)mem; // mem is aligned, &v isn't
2. Why _mm_loadl_epi64 isn't a movq? In emmintrin.h defined as _mm_set_epi64((__m64)0LL, *(__m64 *)__P); Pretty strange.
Adding the option -mpreferred-stack-boundary=2 seems to help. Upon function entry it inserts what I need: "and eps, 0xfffffff0", but nothing happens for -mpreferred-stack-boundary=4 (or 5, for GSVector8).
Did you try -mstackrealign too ? Maybe need gcc 4.5...
What is the code generated in the binary for _mm_loadl_epi64 ? On zzogl _mm_loadl_epi64 is generated as a movq !
Note: the gcc bug you have found is maybe a reason why gsdx crash on wine !
I only checked the debug code for movq, could be nicer in release. The calling of _mm_set_epi64 just does not suggest it will be compiled as a movq.
There was an old post about this on virtualdub.org, http://www.virtualdub.org/blog/pivot/entry.php?id=188, that might be the reason for _mm_set_epi64.

Revision 4318

Implemented virtual alloc functions and changed the event class to use
VirtualFree can accept zero size, munmap cannot?
Line endings becoming mixed on the new files, there was some svn magic against this. Anyone knows about it?
I have done it see 4319. On linux it is svn propset svn:eol-style native

Revision 4319

gsdx: add svn:eol-style metadata

Revision 4320

cmake: add some properties to compile on fedora 64 bits

Revision 4321

GSdx: gcc build runs, and judging by the frame rate it may even draw something.
Looks good. There are still issues somewhere, since I've had it crash a few times, once in UpdateDIMX, but it appears functional as a null plugin...
Oh, and I've run into the stack boundary issue before. It used to cause Yugioh: Duelist of the Roses to crash on the opening. :(
(The crash in UpdateDIMX was when starting Persona 4, incidentally...)
GSState aligned, m_env member aligned (by chance maybe), m_env.dimx not aligned. GCC just ignores my alignment attributes nearly everywhere.
So, gcc not only understands #pragma pack, it even takes precedence over attributes set on members. GSDrawingEnvironment and GSDrawingContext were tightly packed, with the exception of the aligned members which vc++ honored, because in the past these structs were written to the state file as is, but not any longer.

Revision 4322

Fixed an ENDX register bug and switched the dealias filter with the frequency
response filter.

Revision 4323

GSdx: A start at a configuration dialog for Linux.
It's missing a few things, isn't hooked up, and I haven't messed with the formatting yet to make it look nicer. Still, it's a start...

Revision 4324

GSdx: more alignment fixes for gcc.
That took care of most of the crashes I observed. There's still a crash or two lurking, but not as easily reproducible. Seems to work relatively well as a null plugin...
Pseudonym mentioned winelib to maybe get DX9 support? :p
Possible, but if I try to run pcsx2 under wine, the moment it crashes is the first time GSdx tries to draw anything. With pcsx2 0.9.7, anyways. (ZZOgl actually works in wine, interestingly...)
Might be feasible, but just seems a little iffy due to that.
OTOH, Gabest did start coding an OpenGL renderer once. We could pull that code out of an old svn revision and dust it off...
Or someone could just try to translate it to opengl :P First to present the output of the software renderer we are going to need at least these functions: texture allocation, output merger (merge, interlace), and flipping.
I think we should keep the opengl parts separate from the windows build, managing the enviroment there is painful.
Well, yes, translating it to opengl is an idea, too. ^_^
I just figured it'd be easier to start with what had previously been done. And I've already found the last revisions of those files... (r1472 looked like around the last time it was worked on.)
And yeah, for now let's keep the Opengl bits Linux only. We can port it to Windows later, when it actually works.
The big thing, of course, will be convincing myself to learn OpenGL. I do have a huge book about it that I bought. I suppose I should start reading it...
(Though, actually, I have picked up a few things about it from ZZOgl. Just not as much as I'd like. And we have more then just me working on the Linux side of things now, which helps.)
Might be some help, but I never actually tried that old code. It is still not clear to me how the window is managed, now pcsx2 opens an empty one as it seems. On windows I'd have to subclass that to get the messages, opengl also needs to bind to a window somehow. No idea how these things are done on linux.
Ah. In that case, I might just want to use it as reference for roughly what should be happening.
And actually, that's going to be one of the first fun parts. ZZOgl doesn't actually use GSOpen2, so it creates a XWindow, gets messages from there, and passes the XWindow to Onepad, which grabs the keyevents off of that.
Which is well and good, but we are using GSOpen2 in GSdx. And last I checked, it passes some sort of funky non-standard Gtk Widget to us. So I need to figure out how to bind OpenGL to it, and pass events over to Onepad from it.
wxWidgets does seem to have some support for OpenGL, so I might see what I could do with that. Or I could just have GSdx use GSopen if on Linux. :)
This is actually one of the bits I've been planning to work on on ZZOgl but never seem to get around to, incidentally...
Are you trying to make gsdx work in other system than Windows?
read the last 2 commits... your answer is there.

Revision 4325

GSdx: made dx11 detection code a bit nicer, but not sure what happens on vista
without the dx11 runtime, it probably won't detect dx10 either.
thanks.. who cares about vista :)
I tested r4332 (EMUCR) on a fresh Vista-32 installation, without any updates\upgrades whatsoever except for the VSC++ runtimes.
GsDx did NOT detect DX10.
Yea, since it tries to load dx11 dlls. I could fix it, but hate to do things without being able to test it myself.
>> but not sure what happens on vista without the dx11 runtime
It makes available DX9 only.

Revision 4326

pcsx2 utilies: 'mkdir' the full path.

Revision 4327

cmake: add GSdx compilation (based on codeblock)

Revision 4328

GSdx: started a hardware independent device, will be useful for GDI/SDL/etc
output later.
Yes, I'm trying to skip learning opengl :P

Revision 4329

GSdx: updated linux project files.

Revision 4330

- Set default interpolation mode to "Catmull-Rom". It most closely mimics the
original sound.
- Bit of documentation and a fix for Async mixing core resets.
Nice, i always used that mode as well

Revision 4331

GSdx: GSDeviceSW almost ready, just need an image resizer.
Can you please look at the memory leaks GSdx has again?
We worked days (weeks) on fixing them all and now they're back.
You can easily spot the HW renderer not releasing all objects by switching between HW and SW via F9. Memory usage keeps increasing.
How do you notice it? I just tried switching about 50 times and taskman reports between 150-155 MB.
Checked with dx9, something increases there :P
Well, that's odd. I still register increased memory use by switching renderers but it's not GSdx this time.
Sorry for assuming it was, I'm just so used to seeing this :p
I verified GSdx is fine by looking at the vga memory with GPU-Z.
It shows the allocated vga mem in real time and back when we fixed GSdx leakage it constantly grew until it spilled over to main memory.
Guess we'll have to look at recent'ish changes in PCSX2 then :/
It was VirtualFree, I set the size.
"If the dwFreeType parameter is MEM_RELEASE, this parameter must be 0 (zero). The function frees the entire region that is reserved in the initial allocation call to VirtualAlloc."
The renderer switching logic is pretty twisted.
Oh yea, it is.
Feel free to make it nicer if you have an idea how to :p
And every F9 calls it twice!
That's odd. It shouldn't, iirc.
Just put a breakpoint inside _GSOpen and press F9.
Curious, I'll try to see why that is.
Bah, deep in the threading mess we miss some state check and thus it tries to open twice.
Can't see where though, need someone with better debugging skills than I have :p
Fixed in r4363.

Revision 4332

GSdx: memory leak fix.
Always same graphical bugs from super robot taisen
Alright, which one? Gamefaqs lists several from this series.
Super Robot Taisen alpha 2 and 3,Super Robot Taisen Original Generations and Gaiden.
gabest can look at Dirge of Cerberus when you have some free time, that game gets a strange effect (one half of the screen updates slower then the other half leaving a trailing effect, in dx9/10 hw mode), its not really a big deal since the game works ok in software mode, but I am curious what causes it.
Me i have black borders,lines and squares in the background
roo you are extremely annoying, not EVERY commit has to fix YOUR game, we have better things to do.
I haven't made a comment here in long time but I had say something
who ever this roo guy is does not even deserve to get an answer from you guys at all I mean he popped up the same annoying question about his problems with SRW over and over he's been asking about it for 6-7 commits now what is with you man these Guys are not here to serve you so quit it
PS: Nice commit by the way
He reminds me of ferrarinews with his GT4 posts :D
indeed, good job gabest.
roo, you're pathetic. Negativing this because people dont like your selfish insistance.
If there's one game I'm scared to test, is Skygunner in HW mode. Any brave knight around?
Roo, please stop being a child and have patience. Thank you for your work, gabest.
Kids will be kids :p
I kinda feel sorry for gabest. This roo kid is totally uneducated.

Revision 4333

- Fix a duplicated "Open in Explorer" button in standard install mode.

Revision 4334

GSDX: Fixed broken window title info (native resolution, deinterlace mode).
Didn't even notice it was gone :p
And you also won't :P
I knew something was missing from the window...

Revision 4335

GSdx: The revision makes every super robot taisen game look perfect! Just joking
:P But I tested OG and Alpha 3, and didn't notice anything terribly bad till the
beginning of the first battle stage.
Any idea on this? :
[01:12] <rama1> some games loose stuff when pressing F9 now
[01:12] <avih|away> ok, didn't test that one
[01:12] <rama1> nearly all the display in breath of fire
[01:12] <rama1> text in dragon quest 8
[01:13] <avih|away> so that's broken SW rendrer?
[01:13] <rama1> i think it's broken savestate restoring
[01:14] <avih|away> he did put much work into it i think recently. for linux. alignment stuff.. that can break things
[01:14] <rama1> the GS state (and only that) gets saved / restored when doing a renderer switch
It used to work fine some revs ago, even with that double _GSopen2 (which also needs to get fixed but is a PCSX2 thing).
Does this revision fix anything? :p
Just saving progress. If no interlacing is used one could already derive a class from GSDeviceSW and display the output with something that accepts a bitmap in memory.
No idea about switching, I tried it yesterday several times, but with one game only. Going to test it with more.
Nothing strange with dq8. Running around in the first town. Dialogs stay.
Oh yea, just tried it with a latest PCSX2 build and it works fine there.
With just r4314 it's broken though.
Someone changed smth recently? :p
Thanks for te fix gabest!!
Please, can you watch the fog bug (in hardware mode) in ICO?
Sorry for the request, but is my favorite game.
if this fix does work roo is gonna do the chicken dance while somersaulting ohhh!!!I could see the joy in his eyes now hope this shut that Go*da** basta** up
Since we are on the topic of game fixes here are a few I've had problems with (all games are NTSC, most work in software mode,so fixes aren't urgent|required), I'll try to keep it to the most popular games.
"DIRGE of CERBERUS" = slow screen update on right side, the movie intro flickers (could be from slower framerate (48fps));
"Rule of Rose" = movies won't play in hw (F9 to software to make them play)
"Echo Night Beyond" = missing textures, see through walls, blurry (used to work on really old gsdx), software is ok but slow.
"Ghost in the shell" = green vertical stripes in game (or other anomaly's)
"Tales of Legendia" - is a really messed up game looks ok runs around 2-10fps in hw mode, software mode runs at 30+fps (but it's missing text dialogs), (hw = slow, sw = missing textures)(usually its the other way around)..beware of using hardware mode on this game,your PC can generate more heat then when using intel burntest :P
anyways good work, glad to see gabest back and gsdx getting updates again, not a lot of people have the experience to work on gsdx^^
>> konaj
Those are known issues and they will not be fixed in close future. gabest planning to rewrite the whole plugin almost from scratch, but this will take a time.
Message to project admins.
Could someone add sdl-1.3.0 to 3rdparty in a way that it compiles not just under windows?
If nobody has done it by tonight, ill have a go :P
1.3, specifically? Because looking at their site, 1.2 looks like the last release they've done. Anything that's 1.3 looks like it's basically whatever the latest nightly build is.
As far as 1.2 goes, if you can build Onepad, you already have the sdl libraries installed in Linux. It's part of the prerequisites. (libsdl1.2-dev)
In the build options for the project, under "Compiler Settings" and "Other Options", put the following:
`pkg-config sdl --cflags`
And under "Linker Settings", under "Other Linker Objects", put this:
`pkg-config sdl --libs`
The former tells it where the include files are, and the latter adds the library flags, so it links against them. Onepad uses sdl for gamepad support...
I need 1.3, already made a working sdl output on windows, just a few lines, like this: http://slouken.blogspot.com/2011/02/streaming-textures-with-sdl-13.html
Hmmm... I see what you mean. First step will probably be to add sdl 1.3 in, then we can worry about getting it compiling. It already compiles with Linux with a makefile, anyways; we'll probably just want to hack up a codeblocks project for it as well...
I'm assuming the snapshot from Monday on the sdl site is a good one to use?
Yep, I used that one.
Why not make a new SDL project in Code::Blocks and just copy and adapt some of the # code from the main.c or main.cpp it makes?
Just a note, I would love to get involved in the actual project but I don't know enough about C to be of any help - I mean my futile attempts to use OpenGL don't seem to be producing anything, it compiles fine but produces nothing in the window.
@gabest: sdl 1.3 is in, and I hacked up a codeblocks project file that will build it. For the moment, run ./configure before building the code file, to regenerate SDL_config.h before building. I'm sure we can do something about that later, but I wanted to get the project file in. :)
Of course, you can always just build with ./configure; make; make install as well...
watch in battle mecha,there are graphical bug with the texture filtering checked.
you kidding but its serious...
The only thing I'm concerned abouts is da dx11/10 detection.
On the public build, I have all my ini's set to dx10/11 mode.
For now, only my win2k3 is setup as my os, I goto start a game and it fails.
I had to re-write all my ini files to set it to the dx9 equ.
(I'm using menu shotcuts with custom ini files to run each game with).
Ex. H:\Emulation\Console\PlayStation2\PCSX2\pcsx2.exe --cfg="..\..\CFG\ISO.ini" --cfgpath=".\CFG\GSdx - 4X" --gamefixes=IPUWait --nogui "..\ROMs\Final Fantasy X (NTSC-U)[SLUS-20312].iso"
I posted this one because of the game fix, it's not in the cmd line help...
But it works lol.
My req would be...
Check for dx11, if not then check for dx10, if not dx10 then fall back to the dx9 equ of it.
Ie hardware mode, or dx9 software mode if dx11 soft mode selected...
Other then that, fps display in window instead of titlebar.
That's the only thing keeping me form using the full screen mode.
Woudl be nice to see that like in the old ps1 emu days, with a toggle button of some sort.
I suppose one more, a newer public build lol :D.
That would be nice, been wanting to test out a few things, especially the new mem alignment stuffs, hopefully the ptr's don't go changing every time I goto run the game, so my hacks stay at the same addys...
Either way, I just wanna check outs a new public build, I'm sure alot of people do.
This 1090t x6 of mine is just waiting for something to work with ;).
gabest you have really played at super robot taisen, i am not sure...
roo... stop hastling gabest, stop hastling every...single...little...person who makes a commit, if we want to fix your game, we will fix it, till then, stop negativing commits, you are ABUSING the system, it is not designed for people saying if it fixes their game or not, it is designed to show if the commit breaks or fixes something, or if it works or not in what it was meant to do.
Stop posting and negativing, for the love of god...
I guess [email protected] will be the resident -1 ...
sorry but its so annoying to have a lot rev for nothing because since the first rev i see always the same problems in my game.
[email protected] every one here know many very good games with various graphical glitches and if every one will complain.. good luck Gabest and thanks
ye good luck gabest for fix my game lol
heh, at least the guy has some humour. :P
Well.. if you call this a humor.
grr my game isn't always fixed!!!!!
roo, if you want the developers to fix your game then you'll have to follow the rules and post a bug report in the forums. Then you need to be patient, which actually reminds me I still need to do a dump of a problem that occurred in Kingdom Hearts (been a while since I tried playing though).
A quick link to the bug report for the developers that are interested in trying to fix it (just give me a few minutes to go get the dump).

Revision 4336

GSdx: SW+SDL output, commented out until it can be compiled on every system

Revision 4337

Add SDL 1.3 to the 3rd party folder.
This is just a straight copy at the moment...
This sounds to me like the beginning of something really good. Nice to see such an effort by you and gabest to make GSdx SW renderer platform independent.
Was wondering though if wxWidgets has a good enough infrastructure for stretched bitmap output (maybe also OpenGL for ZZOGL). If yes, it might be simpler (and overall better) to use it instead of adding a new dependency (SDL) to PCSX2, and might replace the X-output that ZZOGL uses. Just a thought.
Well, keep in mind that sdl 1.2 was already a dependency, it just was required to already be installed rather then bundled with the program.
I figure if it gets to the point where we are bundling GSdx with Linux, I'll look into redoing the code that uses sdl 1.2 to use 1.3, and remove that dependency. (It's mainly the gamepad code in Onepad that uses it.)
As far as wxwidgets goes, there's wxglContext and wxImage, but I'm not sure how easy to work with they are.
The X-output side of zzogl is due for a bit of a rewrite at some point regardless, since it still uses GSOpen and not GSOpen2. I had some trouble getting it working with GSOpen2 initially, and then it fell through the cracks...
Thanks for the info. Didn't know SDL 1.2 was already a dependency.
Regarding SDL vs wx for emulation output, as a hunch, SDL might indeed be a better overall choice, but since PCSX already heavily depends on wx, I thought it could have been nice to be able to keep the dependency list at wx.
That being said, GSdx is an external plugin for PCSX2, so it might have its own dependencies, and SDL sounds perfectly reasonable for that...
There are lots of games that use libsdl on linux anyway. Libsdl is kind of the "directx" of linux. On debian amd64, there is already a 32bits.
However I'm a bit concern about the version number. I'm afraid that most of distribution will not bundle 1.3 in the coming month, years! Anyway we could still use a static linking.
I gave a quick glance at the compatibility. A compilation of gamepad against the new 1.3 version could be enough.
as said in 4354 I'll revert the negative after answered (just for attention)
the clean_msvc.cmd deletes .pch files which are in the 3rdparty folder of SDL
just update your repository use the clean_msvc.cmd and update again afterwards to see what I mean.

Revision 4338

Preliminary codeblocks project for sdl 1.3.
Note: at the moment, you need to run ./configure in the SDL-1.3.0-5387 directory to generate a new SDL_config.h file before it will compile in codeblocks. (I didn't really want to overwrite SDL_config.h with something Linux specific...)
Also, I haven't actually tried using the generated library with anything.
SDL does not load: "undefined symbol: DSP_bootstrap". Any idea? :P
Audio hates me :'(
undefined symbol: snd_pcm_hw_params_set_channels
That symbol looks familiar. If you don't feel like disabling the audio, go into the linker settings, and add "asound" to the list of libraries. That's the library you would link against for alsa.
Is there no way to load a dynamic lib from the same directory where gsdx is? I think my confusion comes from not knowing where to put it.
Well, static linking is an option too.
Yeah, forgot about that. Plugins, we'd usually set to dynamic, and libraries to static. I'd just set it to static and not worry about it. We basically want to do things about the same way SoundTouch and SPU2-X do them.
Got it loaded with static linking and by disabling audio, but now it explodes at window creation.
What kind of animal is *dsp? :P
First fault at X11_CreateWindowFrom / X11_GetWindowTitle / XGetWindowPropery.
First thought is "digital signal processing". :)
Nah, it's a pointer to some gtk window. Very useful.
Passed to GSOpen2.
Ah. Think that's actually a pointer to some funky panel on the gtk window, then, iirc.
(And trying to use that pointer is exactly where I was running into trouble when I was trying to convert ZZOgl to use GSOpen2.)

Revision 4339

GSdx: enabled SDL output under windows, known problems: after shutdown it won't
show anything again, deinterlacers aren't done yet.
Bit slower than the others but it works so far, nice :)
I noticed that on windows it uses dx9 and the abgr texture type isn't created as "native".

Revision 4340

Corrected a couple of English descrepancies as pointed out in Issue 952 . Noting
SuperVU is correct. sVU doesn't mean it should be superVU, it just looks nicer
as sVU than SVU, especially when coding.
Thank you.

Revision 4341

GSdx: more alignment fixes for gcc.

Revision 4342

Undoing last commit, it was a mistake, linux tools are not easy to use.
great works gabest

Revision 4343

MFIFO fixed Guitar Hero Videos, another case of developers assuming SPR1 will be
finished before SPR0 gets to the data being written >.<
is it not possible to use a variable that both functions can access to prevent SPR0 from taking action until SPR1 is finished? For example:
SPR1 {
SPR1Done = false;
// code
SPR1Done = true;
} SPR0 {
while (!SPR1Done) {} // Empty loop for waiting
// code
Omg, not another SIF. PLEASE ><
nope the game goes
start spr1
start spr0
wait till they end
if it went
start spr1
wait till end
start spr0, wed be ok ;p
The game obviously expects spr1 to always be slightly ahead of spr0, so on a ps2, this would work fine, but where i put a small fix in to stop games that watched the QWC trying to start SPR0 off early (which i applied to SPR1 too, but not the part of SPR0 that MFIFO uses) we ended up transferring QWC - 1 in to the scratchpad, then MFIFO would transfer QWC, which as we do it instantly, ended up copying 1 blank QW, so applying the same change to the MFIFO part avoids this and waits on the last QW.
what about this then:
SPR1Done = 0, 1, 2, etc. at appropriate places
SPR0 {
while (SPR1Done == 0);
// code
while (SPR1Done == 1);
// code
// etc
what is a SIF? tried googling it but just came up with nonsense that I'm sure has nothing to do with what it meant here.
gb: i dont think you understand, it's something we have no control over, plus we are trying to maintain some means of timing as some games are very sensitive to this. the SPR did previously do it all at once then pretend to take longer to maintain the timing, but some games did sneeky tricks to check a different way if it had finished or not, which then in turn caused problems elsewhere, so we couldnt do that.
SIF is a unit that sends data between the IOP (Ps1/peripheral side) to the EE (main ps2 area) and it can be very sensitive to timing.
Ah, fair enough, live and learn as they say

Revision 4344

GSdx: working on linux port again, almost ready to run.
gabest you re the best
Are you porting GSdx to linux?? Amazing!
As far I understand it will be software only via SDL.

Revision 4345

GSdx: I'm restoring the original SDL_config.h, it broke the windows build. No
idea how to proceed under linux, letting it use its own window works, trying to
use the one provided by pcsx2 does not. Could be a multi-threading problem with
X, or not using a top-level handle. Just guessing.
Well, I just got home from work, so I'll have a chance to look at it...
Went back to GSOpen to create my own window like other plugins, but XOpenDisplay simply segfaults.
I'm looking into it. I'll see what I could find. It'd help if printf was actually displaying text. :(
Already wanted to ask why it did not print anything. The watch panel of codeblocks is not very useful.
I'm not sure. I use fprintf(stderr, "..."); in most of the other plugins, but wrapped a bit, but it isn't working here. And using SysMessage doesn't seem to be helping much. I may just need to rig up a logging function...
Have you try to create a SDL_config_linux.h (generated by ./configure)? Then just add a new switch to current config?
#elif defined(__LINUX__)
#include "SDL_config_linux.h"
I did, actually. Trouble was that I ran into a bunch of problems compiling if the defines were in SDL_config_linux.h instead of SDL_config.h. I could probably rig up a precompilation script to generate SDL_config.h before compiling in Linux, but it'd still be pretty easy to accidentally commit the changes.
I'm still thinking about the best way to handle that one. At least I've got a bit more time to work on it now that I'm on my weekend...
Interestingly, this time when I tried creating SDL_config_linux.h, it worked fine. I must have missed something the first time...
Also, it looks like printf not working is caused by sdl. If you use:
SDL_Log("Hello, World!");
instead of:
printf("Hello, World!\n");
It prints properly.

Revision 4346

GSdx: renamed None to something else because X11 defined it for itself.

Revision 4347

GSdx: fixing windows side...
Windows side? Are you porting GSdx to linux?
gabest explain me the functioning of texture filtering pls
if you haven't noticed from previous commits, yes it is being ported, and gabest isn't here to explain the functioning of texture filtering either, forums are for that purpose... On another note nice work Gabest, i hope this actually sees the light of day :)
if you look at the code GSDX..
It is clear that porting GSDX with SDL software mode new option to windows/linux.
Right now SDL doesn't build in the Devel target in VS2008.
2>C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ivec.h(96) : warning C4190: '&' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
2> C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\ivec.h(77) : see declaration of 'M64'
SDL_assert.h includes intrin.h inside extern "C" { ... } Funny it worked on all the other compilers.

Revision 4348

Patch to the memcard manager from ValDanX.
It used to overwrite formatted memory cards before this, oops :p
I couldn't find a test case for the other memcard manager fix.
Could you explain what behavior it fixes?
After moving one card to another, then dst card was removed, now she takes the position of the src card...
you don't include full path... in this version fixed only deleting formatted cards... Msgbox::YesNo return bool...
i'm actually glad to see valdanx here, after so much nonsensical hate towards the guy its cool that he actually made some sort of difference

Revision 4349

GSdx: SDL_assert.h fixed for vs2008.
Thanks :)

Revision 4350

GSdx: just updating visual studio project files (redundant settings, broken x64
compilation, etc.)
So, why there is still no x64 version of pcsx2? :P
Also, SDL is as fast as DX9 can be. That internal BGRA-RGBA conversion was a bit slow.
X64 is just not a priority, seeing as it may not even be faster but definitely would take ages to code.
We would need all new recompilers basically or else it wouldn't make much sense.
For now we've put it on *The ToDo list*, pretty far down :p
Don't let rama's bucket of cold water cool you down.
Dude, couldn't you had answered that question like... 2 years from now? hum? You screwed things up now. If gabest quit, I'll blame you.
[just kidding @both of you :P ]
Linux compilation is broken on the latest svn:
from /home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL.h:73,
from /home/wingnux/pcsx2-read-only/plugins/GSdx/GSDeviceSDL.h:25,
from /home/wingnux/pcsx2-read-only/plugins/GSdx/GPU.cpp:26:
/home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL_stdinc.h:181: error: size of array ‘SDL_dummy_uint64’ is negative
/home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL_stdinc.h:182: error: size of array ‘SDL_dummy_sint64’ is negative
make[2]: *** [plugins/GSdx/CMakeFiles/GSdx.dir/GPU.cpp.o] Error 1
make[1]: *** [plugins/GSdx/CMakeFiles/GSdx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 19%] Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/pxStaticText.cpp.o
[ 19%] Built target FWnull
[ 22%] Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/x86/MemcpyFast.S.o
Linking CXX static library libUtilities.a
[ 22%] Built target Utilities
make: *** [all] Error 2
Did you run configure?
I had to reset configuration, because Windows needs the generic SDL_config.h, while linux needs the one configure spits out.
I use cmake to build pcsx2 (cmake CMakeLists.txt -DCMAKE_BUILD_TYPE=Release && make -j4 |& tee /tmp/build.log) and it doesn't need ./configure.
[email protected]:~/pcsx2-read-only$ svn up
A generate_pot.sh
[email protected]:~/pcsx2-read-only$ ./configure
bash: ./configure: No such file or directory
I'm new to linux and not familiar with cmake, it might not be up-to-date. The command you posted ran here without errors (I already has the static SDL lib built in codeblocks), but I cannot find SDL in the log file anywhere.
Now it breaks @ 89%.
Here's the (quite long) error log: http://notepub.com/?fb=&note=134328
It's the spu2-x project making the errors now, but I don't know much about that.

Revision 4351

Memcard Manager:
- Fixed drag and drop not updating the "Enabled" flag. This meant some changes
to the oop design choice (removal of some const qualifiers). Hope you don't
mind, Jake :p
- Added abort query for overwriting memcards when in copy mode (drag and drop
with ctrl pressed on Windows).
- Changed the sizing a bit so the table fits into the dialog here.

Revision 4352

Memcard Memcard Manager:
- Cosmetic fix to some messages. Don't start the slot numbering with 0 but with
1 line-by-line comment
line 205:
205: (m_MultitapEnabled[0] != g_Conf->EmuOptions.MultitapPort0_Enabled) )
Copypaste error?

Revision 4353

Exclude the EE timing hack from presets as it breaks text in the BIOS
(interesting!) and is reported to cause a few slowdowns even.
It also breaks some games while fixing another, should only be enabled by game like it's been used for known cases so far :p
Then this hack should become part of the gamefixes section with comment that it fixes a game, but breaks others.
I'm not sure which revision introduced this, but I'm getting the following error when building GSDX or PCSX2 (Visual Studio 2008 Professional, Windows):
error LNK2001: unresolved external symbol ___xgetbv
Romulux: It already is in the Game Fixes section.
SNP: that should just be GSDX, it should be fine if you use the profile "Release SSSE3" some of the other profiles dont seem to work right at the moment (gabest needs to update the project)
I am using Release SSSE3, and I definitely remember there being an unresolved external symbol error when building PCSX2 itself, and the symbol began with __xget (I don't recall if the bv was there, I'll check shortly).
Install visual studio sp1.
whoops! :), right, it's been there a long time, I just forgot about it.
Just a clarification about the change by rama: the EE is not excluded from the presets, but rather forced to off for all presets.
An example of a setting which is excluded from the presets is the framelimiter. The framelimiter it can be changed by the user regardless if presets are enabled or disabled. But the EE timing hack is forced Off for all presets.

Revision 4354

Updated the FFX Video Fix, should work again now. Added DMA End log messages to
DMA logging. Hopefully one day someone will reverse engineer the FFX video code
so we can see if we are really doing something really wrong or if the code is
just dire >.<
sorry I'll remove the negative after someone answered it's just to arouse attention.
the clean_msvc.cmd deletes .pch files which are used by SDL.
Then negative one of the SDL ones, not this one.
sorry, ironically I hoped for a fix to the FFX fix xD but I finished the game (again) a week ago^^ can still fight the dark aeons though so thanks anyway
nice fix for ffx videos.
it seems like a lot of Square Enix games have video issues in pcsx2 for example the ffx-2 videos get all messed up when using up-scaling in gsdx (also play a little slow), Dirge of Cerberus videos also play slowly.
Fix works, yea :p
Fix many video of other games!!!! Good fix.
out of curiosity, what other games?
Intro of "Bolt" the video was ruined in the middle.
cool :)

Revision 4355

pcsx2 i18n: add a script to generate pot file on linux.
Linux compilation is broken on the latest svn r4354:
from /home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL.h:73,
from /home/wingnux/pcsx2-read-only/plugins/GSdx/GSDeviceSDL.h:25,
from /home/wingnux/pcsx2-read-only/plugins/GSdx/GPU.cpp:26:
/home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL_stdinc.h:181: error: size of array ‘SDL_dummy_uint64’ is negative
/home/wingnux/pcsx2-read-only/plugins/GSdx/../../3rdparty/SDL-1.3.0-5387/include/SDL_stdinc.h:182: error: size of array ‘SDL_dummy_sint64’ is negative
make[2]: *** [plugins/GSdx/CMakeFiles/GSdx.dir/GPU.cpp.o] Error 1
make[1]: *** [plugins/GSdx/CMakeFiles/GSdx.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 19%] Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/pxStaticText.cpp.o
[ 19%] Built target FWnull
[ 22%] Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/x86/MemcpyFast.S.o
Linking CXX static library libUtilities.a
[ 22%] Built target Utilities
make: *** [all] Error 2
did a quick grep - both pxL and pxLt are used.
it might be better if the script updates the existing .po files automatically as well (msgmerge -U filename.po filename.pot).
Did not know about msgmerge. It is really a good idea.
@Wingnux, do not compile gsdx for the moment at least on cmake. I did not have time to play with it.

Revision 4356

Changed how portable install handles "Clear all settings" so it doesn't remove
the portable.ini anymore.
Instead it resets the flag for running the first time wizard.
Why not just delete that INI and create a new blank one?
I see no need to delete the file.
It'll be a bit more consistent to delete the whole RunWizard entry though, a change I have waiting for commit.

Revision 4357

GSdx: SDL works on linux now, there are still random crashes though.
Still have to figure out how to impement GetClientRect. What's the X11 equivalent for that?
I'm not sure it is what you want, try to look XGetWindowAttributes or XGetGeometry
Nice. I was planning to look more at this this weekend, which is Fri & Sat for me, but looks like you've already got things working...
What's interesting is that it crashes on creating a window in Gentoo, but works fine when I compile it in Ubuntu. I'll have to look into that. (It does explain why I wasn't getting anywhere earlier. Some of my changes might have worked in Ubuntu :( )
It does throw a compilation error in GSDeviceSDL::Create, when it tries to compare a *Display to an *SDL_Window. I just commented out the codeblock that starts:
if(m_window == wnd->GetDisplay())
for the moment to get it to compile. And I ran ./configure --disable-audio in the SDL folder to get a proper config file. We'll have to come up with a better solution on that front.
I also noticed a mistake in the SDL codeblocks project that I'll fix shortly. (Namely, it's not naming the generated library correctly.)
It is definitely still randomly crashing. I observed one in the start of Mana Khemia in ExpandCLUT64_T32_I8. Something tells me alignment issues will be bugging us for a while...

Revision 4358

GSdx: window management should be redone next.

Revision 4359

pcsx2 i18n:
* Translate more stuff in various place
* Fix issue with pot generation on linux namely empty string & quote in asm
* add missing key on generate_pot script. Note: it also updates the po files
with latest pot modification
* regenerate new pot & po files.
Translator note: previous Tertiary pot miss half of the strings.
Note: I replace boot2 injection with fast boot.
A big thanks to weimingzhi and whistler for the feedback

Revision 4360

cmake: disable gsdx compilation. I need to port sdl first.

Revision 4361

Consistency update for r4356:
Clear all settings now deletes the RunWizard entry in both install modes.

Revision 4362

Memcard Manager:
- Suspend emulation when opening the manager. Avoids all kinds of file access
permission trouble.
<rama2> this has the semaphore issue discussed yesterday
<rama2> but for now this falls under "bad user behavior" and it doesn't cause issues even if triggered
<rama2> so whatever :p
^ Basically users can cause a suspend with opening the manager while emulation runs, then hit resume in the PCSX2 menu and the manager will still think it is suspended. Doesn't cause any trouble though now but it might some day.

Revision 4363

Removed an old hack for resumes from suspended states that caused GS plugins to
open twice.
This should help with occasional crashes when pressing F9 or when configuring
the GS plugin while emulation runs. (Thanks for helping with this, Jake :) )

Revision 4364

Made 2 spamming logs go to DbgCon and fixed a few compiler warnings.
And commit some wrong files, too! ><
Great, the TLB map entries were a bit annoying :p

Revision 4365


Revision 4366

GSdx: Correct the sdl library output name, and add sdl to the main codeblocks

Revision 4367

Couple clarifications and fixed warnings.

Revision 4368

SDL: Add a separate linux config file, so we don't have to keep switching it
between Linux and Windows when building.

Revision 4369

GSdx: A bit more work on the Linux dialog box.
So many updates while I was sleeping :)
Hmm, we were trying to add an additional backbuffer to GSdx (and smooth out the framerates somewhat, especially with vsync enabled).
Any ideas how to go about this by chance? :p
@gabest:My weekend is Friday & Saturday. Add that to the fact that you mentioned that GSdx was working in Linux, and a few commits on it were inevitable. ^_^
With the dialog box, I've just basically hooked up all the check boxes (That I'd put in, anyways. I seem to recall that I hadn't added all the controls yet.). Of course, the functions they call are all stubbed out in Linux, so I'll have to stick some code in to handle an ini file for GSdx.
The commit before this one should make it easier to switch between working on the windows and linux side, since now we won't have to worry about SDL_config.h so much.
Of course, now my built in network card on my motherboard seems like it's acting up a bit, so I'll have to tangle with that before I get back to coding. Fortunately, I can connect to wifi; I just never got around to setting it up in Linux...
(Got my network card working again, btw, though I better install wifi drivers in case that happens again...)
I'm just a bit worried about diverging from the original SDL source code too much. It makes updating it harder.
ramapcsx2: You could try BackBufferCount of presentation parameters at device creation. Currently, dx9 is set to the default (1) with flipping, which is effectively double buffering, while dx11 is set to 2.
I agree, but I figure if their configuration file overwrites SDL_config.h normally, my making changes to it shouldn't be too much of an issue. ^_^
I'm not particularly planning on diverging more from sdl's trunk. I might try to get it to compile with audio enabled at some point, though.
Arcum, some note on my previous patch to remove aligned instruction from sse (do not have access to the forum due to web restriction).
I did not change some float store in xbyak, you could also try to remove the -fpmath=sse options (did not try these 2). I think the remaining aligned sse instructions are the one generated by GCC (which must be aligned except GCC bugs...).
Anyway, I try to test mana khemia yesterday and it crash in random place in the code. I'm not sure it is sse related.
If there was a better debugger on linux... is there? Why is it so hard to show the fauling instruction when it happens? And maybe it could print access violation reading or writing address X.
I'd normally use gdb rather then the debugger built in to codeblocks, but it's still a pain.
The main problem is that the crashes we're dealing with here are SIGSEGV signals, and the nature of memory management in pcsx2 causes it to generate a lot of these anyways, which it intercepts, and then changes permissions on the area of memory in question.
In the debugger, it stops on every one of these. You can tell it to ignore them, but then it'll ignore the actual crash as well. You can usually tell at a glance if it was a real crash or not, though.
What I generally do is "gdb ./pcsx2-dbg" to start the debugger, then type "run". I type "c" to continue if it's a false alarm. Just hitting enter repeats the last instruction, and once I see one that looks like a real crash, I type "bt" which does a backtrace.
It's a pain, but it works. If I'm lucky enough for my debugging not to need me to look at SIGSEGV signals, I can type "handle SIGSEGV nostop" at the beginning, and it'll automatically keep going. If you type help in gdb, it'll give you a bunch of information about commands you can use[1].
I also do use console statements a good deal, which is why knowing that SDL_Log works for printing things in GSdx is nice.
[1] And there's a manual here for gdb:
I do the same on my side. Just to faster a little the startup process.
1/ handle SIGSEGV nostop
2/ run
3/ ctrl C (the best is to hit before the real sigsegv :) )
4/ handle SIGSEGV stop
5/ continue until the real sigsegv.
One great feature of gdb is record of instructions (unfortunately I failed to use it, I guess it was/is too experimental). It allows to execute them in reverse order.
That or you could set a breakpoint. Savestates are useful, too; if you know where a crash is, savestate right before it, and you can play it over and over again. (And as an additional bonus, you end up memorizing cheesy lines of dialogue...)
And gdb does have a key buffer, so if you hold enter down for a minute, it'll treat that as pressing enter on the next dozen or so times it stops.
> The main problem is that the crashes we're dealing with here are SIGSEGV signals, and the nature of memory management in pcsx2 causes it to generate a lot of these anyways, which it intercepts, and then changes permissions on the area of memory in question.
That's why I miss those first/second-chance exceptions. The debugger should only break if the app cannot handle it. I'll poke around with gdb this evening :P
When I change the X11 function in zzogl I got some random issue because it was not thread safe (for example the title bar update). See:
It might worth to investigate it => XInitThreads, XLockDisplay() and XUnlockDisplay(). What do you think ?
Arcum, I think I have found the issue with SDL_VIDEO_DRIVER_X11_DYNAMIC feature and plugins pads.
All x11 libs are replaced by a fonction pointer (XAutoRepeatOn(...) { pXAutoRepeatOn = NULL; // default value }. The pointer value is controlled by function SDL_X11_UnloadSymbols/SDL_X11_LoadSymbols which search the address of the symbol in the x11 libs.
The SDL_X11_LoadSymbols is call during the init of the video subsystem (SDL_INIT_VIDEO). I guess the pad and GSdx are in 2 differents threads. I try to init the video too in the pad. As expected the pointer is correctly initialized and it did not crash anymore on the XAutoRepeat. Now I'm not sure it is correct...
Yesterday I was trying to find crashes inside gsdx, I made a state, reloaded it, tried to enter the mentioned gdb commands, but every time it exited without ever stopping inside gsdx. Then I discovered that the crash was happening not always at the same place, but rather after the same amount of frames rendered. Loading a state causes gsdx the frame counter set to 5000, and that last fatal sigfault arrived at 6133 (in that particular case), what I had done in the game during that time did not change the outcome. As the next step I put "return" to the first line of every single entry call to the gs plugin and the same thing happened again.

Revision 4370

3rdparty wxwidget: Backport a fix from wx2.9. It allows to translate the
"broswe" string in some places
Note: on linux the string does not appear (current directory instead).

Revision 4371

* Update zh_CN
* copy zh_CN to zh_SG. zh_TW to zh_MO and zh_HK.
Thanks a bunch for caring about the translations :p
Your welcome. At least I could say that I improve the userfriendlyness of PCSX2 :)
Well, you know... You can improve it more by removing all this registry crap ;P
well you know... You can wipe out windows from your pc and use a real OS :p
Registry crap stays.

Revision 4372

- Fixed an assert in the first time wizard and added a note about the
- Removed some more Console messages
- Changed the SIF struct "free" function to "sif_free" to avoid confusing the
debug malloc libs

Revision 4373

cmake: WIP to build sdl and GSdx
Note: for the moment, I force FORCE_INTERNAL_SDL to false to disable the compilation.

Revision 4374

Various translations related fixes and removed another log.

Revision 4375

de_DE translation files by yours truly.
It's based on the older system that didn't have a pcsx2_Devel.pot but it should
be fine.

Revision 4376

GSdx: another example why unions are not portable, this even fails between vc
x86 and x64, m_vm8 is placed at offset 0, m_vm16/m_vm32 at offset 8 of the anon
Now I wonder how types like __m128 do not break.
Hm, maybe because every member fills out the whole length, and the default packing isn't larger that 16 bytes. But what if it was 32 bytes?

Revision 4377

* Add a language detection fallback. The purpose is to use a nearly identical
language when the requested one is not translated.
Rational: it would reduce translation burden and avoid the cloning of po files
which will be difficult to maintain properly.
* Delete previous cloning of some chineses locales
Hmm...seems like every Release builds from this revision onwards won't run (up to 4387).
It compiles fine, but it just won't run; 4376 is the last one running fine.
Every build is a clean build.
I'm on Win7 SP1, with 'Location' set to Singapore and 'Format' set to English (Singapore), if that has anything to do with it.
I'll try to wipe the .ini files and registry, and see what gives.
No dice.
Tried building the Devel and Debug builds too, and those didn't run either before & after the registry entry & .ini files are deleted.
Using VS2008, btw.
What is your locale setting exactly. English or singapore (chinese?)... Can you print me the log file.
The system locale is literally 'English (Singapore)' on Win7, with another is 'Chinese (Simplified, Singapore)'.
And there's no log file whatsoever.
When I double-clicked pcsx2.exe, it just showed up for awhile in Task Manager and then closed itself; didn't show a window or anything.
Sorry for the late response; been working on a backlog.
Btw, what I meant 'with another' in system locale above is the only other option for Singapore is that, 'Chinese (Simplified, Singapore)', but what I set on my system is the 'English (Singapore)' one.
And if you were asking about PCSX2's locale, even with the .ini files deleted I couldn't run PCSX2, thus even the first-time wizard didn't show up.
It seems like a segmentation fault. Do you know the canonical name. Otherwise try the version 4376, open pcsx2 (try with or without --firstwiz) and send me the log. It must tell somewhere the local is used. For example.
Applying operating system default language...
Loading language translation databases for 'Chinese (Traditional)' [zh_TW]
Oh will you be able to generate a backtrace in the debugger. I do not have windows unfortunately.
AH, right, the debuggger...didn't think about that one.
I'll try running this rev from IDE, and if there's nothing then I'll just recompile 4376 and post the log here.
Unhandled exception at 0x01107cbe in pcsx2.exe: 0xC0000005: Access violation reading location 0x00000000.
And here's the call stack :
pcsx2.exe!__tmainCRTStartup() Line 578 + 0x1d bytes
pcsx2.exe!WinMain(HINSTANCE__ * hInstance=0x00f70000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00347272, int nCmdShow=1) Line 38 + 0x19 bytes
pcsx2.exe!wxEntry(HINSTANCE__ * hInstance=0x00f70000, HINSTANCE__ * __formal=0x00000000, HINSTANCE__ * __formal=0x00000000, int nCmdShow=1) Line 387 + 0xb bytes
pcsx2.exe!wxEntry(int & argc=1, wchar_t * * argv=0x00961550) Line 232 + 0xe bytes
pcsx2.exe!wxEntryReal(int & argc=, wchar_t * * argv=0x00961550) Line 448 + 0xd bytes
pcsx2.exe!Pcsx2App::OnInit() Line 420 + 0x28 bytes
pcsx2.exe!i18n_SetLanguage(wxLanguage wxLangId=wxLANGUAGE_DEFAULT, const wxString & langCode={...}) Line 196
pcsx2.exe borked on that last call.
Just compiled 4376, ran the wizard, and if I set the locale to 'System default', it showed this :
PCSX2 0.9.7.r4374 - compiled on Mar 5 2011
Savestate version: 0x9a010000
Host Machine Init:
Operating System = Microsoft Windows 7 Home Premium Edition Service Pack 1 (build 7601), 64-bit
Physical RAM = 4095 MB
CPU name = Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz
Vendor/Model = GenuineIntel (stepping 0B)
CPU speed = 3.010 ghz (2 logical threads)
x86PType = Standard OEM
x86Flags = bfebfbff 0000e3fd
x86EFlags = 20000000
x86 Features Detected:
Plugins shutdown successfully.
Invalid language identifier (wxID=0)
Reserving memory for recompilers...
Loading plugins...
Binding GS : C:\pcsx2\plugins\GSdx-SSE2.dll
Windows 6.1.7601 (Service Pack 1 1.0)
ATI Radeon HD 5700 Series (
Binding PAD : C:\pcsx2\plugins\LilyPad.dll
Binding SPU2 : C:\pcsx2\plugins\SPU2-X.dll
Binding CDVD : C:\pcsx2\plugins\cdvdGigaherz.dll
Binding USB : C:\pcsx2\plugins\USBnull.dll
Binding FW : C:\pcsx2\plugins\FWnull.dll
Binding DEV9 : C:\pcsx2\plugins\DEV9null.dll
Plugins loaded successfully.
(GameDB) 8962 games on record (loaded in 311ms)
Thanks very much. I found the issue. Your locale is not supported
>> Invalid language identifier (wxID=0)
Could you confirm that the following patch fix your issue. Thanks for your help.
Index: pcsx2.snapshot-4384/pcsx2/gui/i18n.cpp
--- pcsx2.snapshot-4384.orig/pcsx2/gui/i18n.cpp
+++ pcsx2.snapshot-4384/pcsx2/gui/i18n.cpp
@@ -193,10 +193,12 @@
const wxLanguageInfo* info = wxLocale::GetLanguageInfo(wxLangId);
- // Check if you can load a similar language
- wxLanguage LangId_fallback = i18n_FallbackToAnotherLang((wxLanguage)info->Language);
- if (LangId_fallback != (wxLanguage)info->Language)
- info = wxLocale::GetLanguageInfo(LangId_fallback);
+ // Check if you can load a similar language in case the current one is not yet provided
+ if (info) {
+ wxLanguage LangId_fallback = i18n_FallbackToAnotherLang((wxLanguage)info->Language);
+ if (LangId_fallback != (wxLanguage)info->Language)
+ info = wxLocale::GetLanguageInfo(LangId_fallback);
+ }
// note: language canonical name mismatch probably means wxWidgets version changed since
// the user's ini file was provided. Missing/invalid ID probably means the same thing.
Yep, that one made it start just fine. =)
Cool. I commit it.

Revision 4378

i18n: regenerates po&pot

Revision 4379

i18n: add a missing default case statement ...

Revision 4380

GSdx: the x64 ABI on windows is not so nice after all.
Saving and restoring xmm6-xmm15 for each scanline is too much overhead. The also requires stack alignment and one register to save esp. Even more overhead.
... and no absolute addressing because displacement is still 32 bit at most, every pointer needs one gpr, what a PITA.
Any boost on x64 mode?
Cannot tell until it's actually working, the output looks still broken. That makes pixel tests fail or succeed differently.
If I just return from the scanline drawing without doing anything and compare that, then it's faster about 10-20% percent, but if I also add the extra prologue/epilogue code... well, let's hope the rest is fast enough to compensate it.
I've never had any problems, then again my system might just be too fast for me to notice. My spec if your interested is:
Windows 7, AMD Athlon II Quad Core (x64).
More detail here: https://docs.google.com/uc?id=0B7XEqelNSvg9MzA4MWI1NTUtNWNkNy00MDY2LTgzMDgtYzk1YjQ1MjVlNGM0&export=download&authkey=CP2omIcJ&hl=en_GB
Is a "Piriform Speccy" Snapshot
sorry 4 the off-topic but i'm curious: gabest, did you look the problems assigned to you at the issues section? i believe at least 1 of them is fixed, the ICC one, and about the others? any idea of what may be happening?
I never go there, it's so depressing. And I don't really have time to add more d3d hacks.
wait, is that how the issue system works!? I thought that developers would just click a check-box or something to say they're going to deal with it, Google is dumb for not doing it like that.
better donate than importune devteam ;)
importune? did you miswrite that or is it simply a term I have not yet learnt
It's a term you haven't encountered yet.
oh, well I haven't done any of that sort of stuff yet (don't plan to either). Once I finally get the hang of c and c++ I plan to just look for the solution myself and then post it here for someone to add to trunk.
hey gabest11 or other member project Visual studios 2008 broken GSDX compilation
And solution here for update project vc2008
you add missing new files not exist on project vs2008 (only update 2010 project)
Necesary add
- GSVertexTrace.x86.cpp
- GSSetupPrimCodeGenerator.x86.cpp
- GSDrawScanlineCodeGenerator.x86.cpp
And compilation work again ;)
Thanks for you job

Revision 4381

cmake: sdl and gsdx (experimental)
Note: pad plugins crash when linked with sdl 1.3.

Revision 4382

GSdx: fixing the vs2008 project

Revision 4383

GSdx: ... and codeblocks.
Can't build on Linux:
[ 44%] Building CXX object plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/Profile.cpp.o
[ 44%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/Counters.cpp.o
[ 44%] Building CXX object plugins/spu2-x/src/CMakeFiles/spu2x.dir/SndOut_Portaudio.cpp.o
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:34: error: ISO C++ forbids declaration of ‘PaStreamCallbackTimeInfo’ with no type
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:34: error: expected ‘,’ or ‘...’ before ‘*’ token
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:76: error: ISO C++ forbids declaration of ‘PaStreamCallbackTimeInfo’ with no type
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:76: error: expected ‘,’ or ‘...’ before ‘*’ token
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In member function ‘virtual s32 Portaudio::Init()’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:115: error: ‘Pa_GetDeviceCount’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:119: error: expected initializer before ‘*’ token
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:121: error: ‘apiinfo’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:141: error: ‘Pa_GetHostApiCount’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:143: error: expected initializer before ‘*’ token
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:144: error: ‘apiinfo’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:170: error: ‘PaStreamParameters’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:170: error: expected ‘;’ before ‘outParams’
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:185: error: ‘outParams’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:153: warning: unused variable ‘infoPtr’
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:205: error: invalid conversion from ‘int (*)(const void*, void*, long unsigned int, int)’ to ‘long unsigned int’
/usr/include/portaudio.h:355: error: too few arguments to function ‘PaError Pa_OpenDefaultStream(PortAudioStream**, int, int, PaSampleFormat, double, long unsigned int, long unsigned int, int (*)(void*, void*, long unsigned int, PaTimestamp, void*), void*)’
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:205: error: at this point in file
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In member function ‘virtual void Portaudio::Close()’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:234: error: ‘Pa_IsStreamActive’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In member function ‘virtual int Portaudio::GetEmptySampleCount()’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:270: error: ‘Pa_GetStreamWriteAvailable’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In member function ‘virtual void Portaudio::SetApiSettings(wxString)’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:305: error: ‘paInDevelopment’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:306: error: ‘paDirectSound’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:307: error: ‘paMME’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:308: error: ‘paASIO’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:309: error: ‘paSoundManager’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:310: error: ‘paCoreAudio’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:311: error: ‘paOSS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:312: error: ‘paALSA’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:313: error: ‘paAL’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:314: error: ‘paBeOS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:315: error: ‘paWDMKS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:316: error: ‘paJACK’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:317: error: ‘paWASAPI’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:318: error: ‘paAudioScienceHPI’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In member function ‘virtual void Portaudio::WriteSettings() const’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:326: error: ‘paInDevelopment’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:327: error: ‘paDirectSound’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:328: error: ‘paMME’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:329: error: ‘paASIO’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:330: error: ‘paSoundManager’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:331: error: ‘paCoreAudio’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:332: error: ‘paOSS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:333: error: ‘paALSA’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:334: error: ‘paAL’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:335: error: ‘paBeOS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:336: error: ‘paWDMKS’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:337: error: ‘paJACK’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:338: error: ‘paWASAPI’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:339: error: ‘paAudioScienceHPI’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: At global scope:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:354: error: ISO C++ forbids declaration of ‘PaStreamCallbackTimeInfo’ with no type
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:354: error: expected ‘,’ or ‘...’ before ‘*’ token
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp: In function ‘int PaLinuxCallback(const void*, void*, long unsigned int, int)’:
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:358: error: ‘timeInfo’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:358: error: ‘statusFlags’ was not declared in this scope
/home/wingnux/pcsx2-read-only/plugins/spu2-x/src/SndOut_Portaudio.cpp:358: error: ‘userData’ was not declared in this scope
make[2]: *** [plugins/spu2-x/src/CMakeFiles/spu2x.dir/SndOut_Portaudio.cpp.o] Error 1
make[1]: *** [plugins/spu2-x/src/CMakeFiles/spu2x.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 44%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/GameDatabase.cpp.o
[ 44%] Building CXX object plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/rasterfont.cpp.o
[ 96%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/Linux/LnxKeyCodes.cpp.o
Linking CXX executable ../bin/pcsx2
[ 96%] Built target pcsx2
make: *** [all] Error 2
wingnux, which gcc version do you have, 4.6?
Note: I need to check for this gsdx new files too.
Note: 4.6 also broke inline in zzogl.
Can you told me also your portaudio version. Ubuntu -> dpkg -l | grep -i portaudio
[email protected]:~/pcsx2-read-only$ dpkg -l | grep -i portaudio
ii libportaudio-dev 18.1-7.1 Portable audio I/O - development files
ii libportaudio0 18.1-7.1 Portable audio I/O - shared library
ii libportaudio2 19+svn20100802-0ubuntu1 Portable audio I/O - shared library
rc libportaudiocpp0 19+svn20100802-0ubuntu1 Portable audio I/O C++ bindings - shared library
[email protected]:~/pcsx2-read-only$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
try to replace libportaudio-dev with portaudio19-dev
It worked, thank you very much!
GSdx wasn't built tough.
Ok, I will improve the cmake detection.
To build GSdx, you need to add the following -DFORCE_INTERNAL_SDL=TRUE (well I maybe forget a security to not compile it because it is too much experimental) However it would not compile the pad plugins.
Everything built fine, including "libGSdx.so" but it doesn't show up on the GS drop-down list.
Check the log, it may say something about missing functions. I got that before adding the new cpp files to the codeblocks project.
Btw, I find it strange that gcc can link binaries without everything in place. Is there a switch to make that a linker error?
The gsdx plugin fails for me (Visual Studio 2008 SP1 Professional) when i start I try to change to it in pcsx2.
[wx] Failed to load shared library 'e:\Program Files (x86)\PCSX2 0.9.7\Plugins\gsdx-sse4-r4384.dll' (error 126: the specified module could not be found.)
Path: e:\Program Files (x86)\PCSX2 0.9.7\Plugins\gsdx-sse4-r4384.dll
File is not a valid dynamic library.
Some kinda plugin failure: e:\Program Files (x86)\PCSX2 0.9.7\Plugins\gsdx-sse4-r4384.dll
Here are the compiler warnings (No errors though)
.\GSState.cpp(559) : warning C4389: '==' : signed/unsigned mismatch
.\GSRendererSW.cpp(419) : warning C4244: '=' : conversion from 'const int' to 'uint16', possible loss of data
.\GSRendererSW.cpp(420) : warning C4244: '=' : conversion from 'const int' to 'uint16', possible loss of data
.\GSRendererSW.cpp(445) : warning C4244: '=' : conversion from 'const int' to 'uint16', possible loss of data
.\GSRendererSW.cpp(446) : warning C4244: '=' : conversion from 'const int' to 'uint16', possible loss of data
.\GSLocalMemory.cpp(1312) : warning C4244: '=' : conversion from 'uint32' to 'uint16', possible loss of data
.\GSLocalMemory.cpp(1329) : warning C4244: '=' : conversion from 'uint32' to 'uint8', possible loss of data
.\GSLocalMemory.cpp(1346) : warning C4244: '=' : conversion from 'uint32' to 'uint8', possible loss of data
.\GSLocalMemory.cpp(1363) : warning C4244: '=' : conversion from 'uint32' to 'uint8', possible loss of data
.\GSLocalMemory.cpp(1380) : warning C4244: '=' : conversion from 'uint32' to 'uint8', possible loss of data
.\GSLocalMemory.cpp(1397) : warning C4244: '=' : conversion from 'uint32' to 'uint8', possible loss of data
e:\development\project source\pcsx2\plugins\gsdx\baseclasses\wxutil.cpp(420) : warning C4706: assignment within conditional expression
e:\development\project source\pcsx2\plugins\gsdx\gsutil.cpp(357) : warning C4701: potentially uninitialized local variable 'hr' used
e:\development\project source\pcsx2\plugins\gsdx\baseclasses\schedule.cpp(120) : warning C4706: assignment within conditional expression
e:\development\project source\pcsx2\plugins\gsdx\baseclasses\outputq.cpp(366) : warning C4701: potentially uninitialized local variable 'ppacket' used
e:\development\project source\pcsx2\plugins\gsdx\baseclasses\outputq.cpp(312) : warning C4701: potentially uninitialized local variable 'lNumberToSend' used
e:\development\project source\pcsx2\plugins\gsdx\baseclasses\transip.cpp(772) : warning C4701: potentially uninitialized local variable 'Actual' used
Gabest, here's the log:
/home/wingnux/pcsx2-read-only/3rdparty/SoundTouch/RateTransposer.cpp: In static member function ‘static void* soundtouch::RateTransposer::operator new(size_t)’:
/home/wingnux/pcsx2-read-only/3rdparty/SoundTouch/RateTransposer.cpp:112: warning: ‘operator new’ must not return NULL unless it is declared ‘throw()’ (or -fcheck-new is in effect)
[ 6%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_compat.c.o
[ 6%] [ 6%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_error.c.o
Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/CheckedStaticBox.cpp.o
[ 6%] Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/TDStretch.cpp.o
[ 6%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_fatal.c.o
I take a shower and then I fix cmake :) Actually some symbols are undefined (for example gtk,glib). Maybe to *ease* plugins.
[email protected]: How do you start pcsx2? Is SDL.dll in the current working directory?
Cmake fix in r4385 for impatient guy ;)
@gabest, here an extract of the linker manual.
Allows or disallows undefined symbols in shared libraries. This switch is similar to --no-undefined except that it determines the behaviour when the
undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled.
The default behaviour is to report errors for any undefined symbols referenced in shared libraries if the linker is being used to create an executable, but
to allow them if the linker is being used to create a shared library.
The reasons for allowing undefined symbol references in shared libraries specified at link time are that:
o A shared library specified at link time may not be the same as the one that is available at load time, so the symbol might actually be resolvable at
load time.
o There are some operating systems, eg BeOS and HPPA, where undefined symbols in shared libraries are normal.
The BeOS kernel for example patches shared libraries at load time to select whichever function is most appropriate for the current architecture. This
is used, for example, to dynamically select an appropriate memset function.
I don't see SDL.dll inside my PCSX2 install directory, but it is at E:/Development/Project Source/PCSX2/bin/ (My source code directory I use to compile)

Revision 4384

GameDB: Just adding some games and correcting some typos for now.

Revision 4385

* add new cpp files for GSdx
* Ensure V2 API include files of portaudio
Merci, Gregory! =)
GSdx still doesn't show up on the plugin selection list.
/home/wingnux/pcsx2-read-only/3rdparty/SoundTouch/FIRFilter.cpp: In static member function ‘static void* soundtouch::FIRFilter::operator new(size_t)’:
/home/wingnux/pcsx2-read-only/3rdparty/SoundTouch/FIRFilter.cpp:226: warning: ‘operator new’ must not return NULL unless it is declared ‘throw()’ (or -fcheck-new is in effect)
[ 4%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_compat.c.o
[ 5%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_error.c.o
[ 5%] [ 6%] Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/RateTransposer.cpp.o
Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/SoundTouch.cpp.o
[ 6%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_fatal.c.o
Look at the console or emuLog.txt. Check that all library are linked. ldd libGSdx.so
You can also give the output of:
nm -uC bin/plugins/libGSdx.so| grep -vi glib | grep -vi gtk | grep -vi cxxabi
Here they are:
PCSX2 0.9.7.r0 - compiled on Mar 2 2011
Savestate version: 0x9a010000
Host Machine Init:
Operating System = Linux 2.6.35-22-generic i686
Physical RAM = 2010 MB
CPU name = AMD Athlon(tm) II X2 245 Processor
Vendor/Model = AuthenticAMD (stepping 02)
CPU speed = 3.187 ghz (2 logical threads)
x86PType = Standard OEM
x86Flags = 178bfbff 00802009
x86EFlags = efd3fbff
x86 Features Detected:
MMX2 .. 3DNOW .. 3DNOW2.. SSE4a
Installing POSIX SIGSEGV handler...
Reserving memory for recompilers...
Loading plugins...
Binding GS : /home/wingnux/jogos/pcsx2/plugins/libzzogl.so
Binding PAD : /home/wingnux/jogos/pcsx2/plugins/libzeropad.so
Binding SPU2 : /home/wingnux/jogos/pcsx2/plugins/libspu2x.so
Binding CDVD : /home/wingnux/jogos/pcsx2/plugins/libCDVDlinuz.so
Binding USB : /home/wingnux/jogos/pcsx2/plugins/libUSBnull.so
Binding FW : /home/wingnux/jogos/pcsx2/plugins/libFWnull.so
Binding DEV9 : /home/wingnux/jogos/pcsx2/plugins/libdev9null.so
Plugins loaded successfully.
(GameDB) 9077 games on record (loaded in 279ms)
[wx] /home/wingnux/jogos/pcsx2/plugins/libGSdx.so: undefined symbol: PULSEAUDIO_bootstrap
Path: /home/wingnux/jogos/pcsx2/plugins/libGSdx.so
File is not a valid dynamic library.
Some kinda plugin failure: /home/wingnux/jogos/pcsx2/plugins/libGSdx.so
[email protected]:~/jogos/pcsx2/plugins$ ldd libGSdx.so
linux-gate.so.1 => (0x00f4a000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00380000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x0017e000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00197000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00110000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00bcd000)
libm.so.6 => /lib/libm.so.6 (0x00cca000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00120000)
libpthread.so.0 => /lib/libpthread.so.0 (0x0013c000)
libc.so.6 => /lib/libc.so.6 (0x00cf0000)
libuuid.so.1 => /lib/libuuid.so.1 (0x00b9f000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00156000)
libdl.so.2 => /lib/libdl.so.2 (0x00170000)
/lib/ld-linux.so.2 (0x00baf000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00ec9000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00174000)
Hum it is an issue with SDL.
Do not know why you have the symbol PULSEAUDIO_bootstrap. Sound is normally disabled !
[email protected]:~/pcsx2-read-only/bin/plugins$ nm -uC libGSdx.so| grep -vi glib | grep -vi gtk | grep -vi cxxabi
nm: libGSdx.so: no symbols
Can you try this patch (it removes completely the remaining audio stuff)
--- pcsx2.snapshot-4384.orig/3rdparty/SDL-1.3.0-5387/CMakeLists.txt
+++ pcsx2.snapshot-4384/3rdparty/SDL-1.3.0-5387/CMakeLists.txt
@@ -118,23 +118,23 @@
- "${SDL_ROOT}/src/audio/SDL_audio.c"
- "${SDL_ROOT}/src/audio/SDL_audio_c.h"
- "${SDL_ROOT}/src/audio/SDL_audiocvt.c"
- "${SDL_ROOT}/src/audio/SDL_audiodev.c"
- "${SDL_ROOT}/src/audio/SDL_audiodev_c.h"
- "${SDL_ROOT}/src/audio/SDL_audiomem.h"
- "${SDL_ROOT}/src/audio/SDL_audiotypecvt.c"
- "${SDL_ROOT}/src/audio/SDL_mixer.c"
- "${SDL_ROOT}/src/audio/SDL_mixer_m68k.c"
- "${SDL_ROOT}/src/audio/SDL_mixer_m68k.h"
- "${SDL_ROOT}/src/audio/SDL_mixer_MMX.c"
- "${SDL_ROOT}/src/audio/SDL_mixer_MMX.h"
- "${SDL_ROOT}/src/audio/SDL_mixer_MMX_VC.c"
- "${SDL_ROOT}/src/audio/SDL_mixer_MMX_VC.h"
- "${SDL_ROOT}/src/audio/SDL_sysaudio.h"
- "${SDL_ROOT}/src/audio/SDL_wave.c"
- "${SDL_ROOT}/src/audio/SDL_wave.h"
+ # "${SDL_ROOT}/src/audio/SDL_audio.c"
+ # "${SDL_ROOT}/src/audio/SDL_audio_c.h"
+ # "${SDL_ROOT}/src/audio/SDL_audiocvt.c"
+ # "${SDL_ROOT}/src/audio/SDL_audiodev.c"
+ # "${SDL_ROOT}/src/audio/SDL_audiodev_c.h"
+ # "${SDL_ROOT}/src/audio/SDL_audiomem.h"
+ # "${SDL_ROOT}/src/audio/SDL_audiotypecvt.c"
+ # "${SDL_ROOT}/src/audio/SDL_mixer.c"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_m68k.c"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_m68k.h"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_MMX.c"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_MMX.h"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_MMX_VC.c"
+ # "${SDL_ROOT}/src/audio/SDL_mixer_MMX_VC.h"
+ # "${SDL_ROOT}/src/audio/SDL_sysaudio.h"
+ # "${SDL_ROOT}/src/audio/SDL_wave.c"
+ # "${SDL_ROOT}/src/audio/SDL_wave.h"
@@ -253,8 +253,8 @@
#re deeply nestedfiles that may need some platform specific logic to determine inclusion
- "${SDL_ROOT}/src/audio/dummy/SDL_dummyaudio.c"
- "${SDL_ROOT}/src/audio/dummy/SDL_dummyaudio.h"
+ # "${SDL_ROOT}/src/audio/dummy/SDL_dummyaudio.c"
+ # "${SDL_ROOT}/src/audio/dummy/SDL_dummyaudio.h"
I don't know how to apply this patch, can you tell me what should I do?
Just edit the file 3rdparty/SDL-1.3.0-5387/CMakeLists.txt
and comemnt (add #) line with audio.
Otherwise cd svn_trunk_pcsx2 ; patch -p1 < the_super_patch
Applied the patch, still didn't work:
"[wx] /home/wingnux/pcsx2-read-only/bin/plugins/libGSdx.so: undefined symbol: SDL_AudioQuit
Path: /home/wingnux/pcsx2-read-only/bin/plugins/libGSdx.so
File is not a valid dynamic library.
Some kinda plugin failure: /home/wingnux/pcsx2-read-only/bin/plugins/libGSdx.so"
[email protected]:~/pcsx2-read-only$ ./errorlog.sh
[ 6%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL.c.o
[ 6%] Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/AlignedMalloc.cpp.o
[ 7%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_compat.c.o
[ 7%] Building C object 3rdparty/SDL-1.3.0-5387/CMakeFiles/pcsx2_SDL.dir/src/SDL_error.c.o
[ 7%] Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/mmx_optimized.cpp.o
[ 7%] Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/sse_optimized.cpp.o
[ 7%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/3dnow.cpp.o
the "dx" part of that plugin-name just gives quite an odd feeling in linux, but that is just shallowness i guess ;)
GSdx11? That even has x11 in it :P
wingnux, can you clean all cmake generated files.
1/ Clean everythings (svn status (must be empty delete at least ? files)
2/ try without the patch (svn revert <your_file>)
3/ If not ok, clean bis
4/ try with the patch.
Maybe you can blend the 2 name, GSdlX11 :p
Thenks for your helo, Gregory, it works now without having to apply the patch. I was using a clean enviroment but I'd completely forgotten about the .svn folder and files! :P My bad!
Euh do not delete the .svn folder (except if you need desperately disk space). It contains the svn meta data. If you delete it, svn command will not work anymore. Anyway it is good for me :)
hi, i'am tuxgamer from the forums.pcsx2.net.
how to compile Gsdx, i just update svn, and try it:
[[email protected]_2010_Spring pcsx2-svn]$ make Gsdx
make: *** No rule to make target `Gsdx'. Stop.
i can compile pcsx2, and other plugin, but not Gsdx
make G<tab> -> make GSdx (do not forget to add the cmake option -DFORCE_INTERNAL_SDL=TRUE)
Note: GSdx is highly experimental and will crash in a few minutes.
thanks for the reply.
i just saw some nice change in svn, updated again.
hmm,with adding that option, now i can compile GSdx now, but i can not compile onepad and zeropad plugins.
trying with NULLpad plugins, running the game.
Got pop up error message:
/home/ai/Game/pcsx2-svn/common/src/Utilities/Linux/LnxHostSys.cpp(57) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: MTGS
Condition: false
Message: Unhandled page fault @ 0x0000007c
trying to click YES to stop the Emulation, but somehow, it suggest to go Plugins directori setting, press Ok in Plugins directori setting window, it's just make Pcsx2 freeze.
I have to Ctrl+C in Console to terminate the program.
ps: can i discuss this in forum "Linux - Compile and Support" ?
Yes you can. However we never said that it will work :p
Onepad and zeropad are not compatible with the current sdl version in 3rdparty [0]. Unfortunately GSdx crash every 100 seconds. It is not playable.
[0] I potentially have a fix but I do not want to introduce a regression on pad for nothings (GSdx is not yet usable).
After addtional thought, I updated the trunk with a nice ifdef. Now you can build both pad and GSdx in the same time. However it did not fix GSdx crashes.
yeah, that's fine by me.
ijust want to try GSdx, if that doesn't work, i will wait again...
i like to see svn, if there's something interesting, i will try it.
thanks for the help. ^_^
hmmm, Zeropad plugins give me error too, i have to wait now...
Opening plugins...
Opening GS
Opening PAD
/home/ai/Game/pcsx2-svn/common/src/Utilities/Linux/LnxHostSys.cpp(57) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: EE Core
Condition: false
Message: Unhandled page fault @ 0x00000000
thanks. ^_^
Hum, this issue must be fixed with latest commit. Could you please check it. I only test onepad (zeropad must behave the same)
okey, update svn to the latest.
compile it again, teted with Zeropad, still got error, opening Zeropad plugins config, it killed pcsx2.
try with Onepad, it still the same error like in Zeropad, when i try to configure, it killed pcsx2 instantly.
thanks. ^_^
Well I did not test to configure it ;) If you have some free time, could you send me a gdb backtrace with onepad.
i need to configure it, so i can use my PS2 DualShock Gamepad. ^_^
gdb backtrace? you mean error window that just pop up with option Ignore, No and Yes?
i run pcsx2, try to configure it, it just killed.
take a look at emulog, nothing showed there.
but, if i just run pcsx2 without configure Onepad, i get this error message in emulog:
Opening plugins...
Opening GS
Opening PAD
/home/ai/Game/pcsx2-svn/common/src/Utilities/Linux/LnxHostSys.cpp(57) : assertion failed:
Function: void SysPageFaultSignalFilter(int, siginfo_t*, void*)
Thread: EE Core
Condition: false
Message: Unhandled page fault @ 0x00000000
Hum, be sure to clean all previous build (CMakeFiles/ directories) and redo a build of everything.
If you have the trace (which function call who before the crash) send it to me. It is include in the popup error but sometimes it does not work ! It is not exactly a gdb backtrace but it would enough.
i'am always using clean svn, i mean, i download svn to pcsx2-radonly folder, then copy from pcsx2-readonly folder to pcsx2-svn folder.
i do that everytime i update pcsx2-readonly folder, so i always have fresh and clean pcsx2-svn folder.
and when i copy pcsx2-readonly folder to pcsx2-svn folder, before compile it.
hmm, i saw strace, but nothing showup in popup error.
or i need option to make debug more verbose?

Revision 4386

New feature!
There's a new option in the GS window configuration that allows a "managed
This new option will dynamically toggle Vsync based on the current frame rate.
If the game runs at full speed, it turns Vsync on. If it drops below full speed,
Vsync is turned off.
This effectively allows Vsync to be enabled in most games while avoiding the
huge performance penalty
it usually causes whenever the FPS drop below full speed.
Note that the feature currently only works nicely with GSdx DX10/11 HW
The other renderers and plugins will either ignore the Vsync switches or they'll
show an
annoying black frame on each switch.
And I'm sorry for the extra text that would need translations.
Also the toggle logic code is sloppy :p
Wow! Cool feature! Thanks, rama
It is a really a good idea.
What are the advantage of vsync for PCSX2. And what is it doing actually? I know vsync (general pc hardware) it the uploads of the framebuffer to the monitor during the vertical refresh of the monitor. Is it the same. I'm curious about the compatibility with a PAL game (50Hz) and any flat screen (60Hz).
Oh and for the translation. For the moment adding or removing translation is fine, specially the last one :p But changing text is more painful.
Personally I do not like to redo a jobs 2 or 3 times. I feel like it is a waste of time.
Yeah, I know.
I just felt that for consistency, we should decide on how we call "full screen" or "vsync".
2 different versions on the same gui panel doesn't look very professional :p
Vsync works on the 3D api level and basically forces a wait until the display is done drawing the last frame.
It indeed works best in NTSC games with a TFT display of 60Hz (120Hz could also work nicely).
If limiting is enabled, PCSX2's own limiter will do some soft limiting and Vsync will smooth the rest out. The result is a non lagging and smooth update.
This doesn't work quite as well in 50Hz PAL games but I felt there still was an improvement.
I own a BenQ XL2410T which runs at 120Hz. I hope this doesn't cause issues for me given that PS2 games don't run at 120FPS :p
Haven't really found any good reason to have Vsync enabled at 120Hz much anyway imho
Good feature!
wow now this will really help with screen tearing
Try it anyway, will ya? Should work nicely at 120Hz, too.
You'll always get a less jerky screen update with it on, no matter the refresh rate.
wow nice idea! never thought about that... Always forget if your framerate drops below your vsync it drops the frame rate to half ;p
Thanks for the nice comments guys, hope this is useful for you too :)
Using triple buffering should remove the need for this functionality. It allows to use VSync with a much lower performance hit, and the FPS halving when below 60 FPS disappears.
Could you consider adding simple Triple Buffering with Vsync? (unless it's already there, I haven't checked)
With your solution, it seems unless the game runs full speed, you'll get some screen tearing :(
Triple buffering won't help paranoid ppl that hate the thought of frames being sent at uneven intervals.
It might help with the slowdowns tho:
[tech rant few will care about]
The problem with plain vsync is, if all frames are "slightly" late (even 1% late), they will all end up having an extra frame in the middle (effectively halfing the frame rate), but if you have a queue of 2-3 frames, then those small delays would be accumulated (in the best case, a game running at 99% speed might be able to draw 60 game-frames in 61 real-frames, which means 60/61=98% speed, still slower than it should, but not 50% like no queueing), I just dont' know how much would triple buffering help.
[/tech rant few will care about]
great idea!!! well done :):):)
Comment by project member ramapcsx2, Mar 03
This doesn't work quite as well in 50Hz PAL games but I felt there still was an improvement.
Could you clarify why this occurs in 50Hz Pal games?
because if you got a 50hz game, but your display is 60hz regardless, then as far as the computer is concerned, it's like if it was a 60hz game running slower at 50hz: the frames don't "fit" cleanly into the 60hz vsync intervals, and you end up adding more pauses than desired in between.
You can probably set your screen to a refresh rate of 50 Hz to avoid this. Even on my laptop it's possible by adding a custom resolution setting in the NVIDIA Control Panel.
Useful to watch PAL and film video too (at 24 fps, set refresh rate to 48 or 72 Hz).
Thank you for clarifying the 50Hz issue.
One small note I've noticed that the added code utilizes:
gsRegionMode == Region_NTSC as a condition and then an
else for other regions (AppMain.cpp).
According to some sources on the net, pal games with
an 60hz option actually output an ntsc signal, if selected,
so I assume we don't have to worry about cases where an
pal game is forced to 60Hz, in it's selection menu,
since the ManagedVsync is deals with both cases differently.
Note: not sure about SECAM...

Revision 4387

A few fixes for some situations I didn't consider.

Revision 4388

i18n: update chineses translations
Where can i download it?
Well I do not know how to process for the compiled version. I do not want to put them for the moment (take too much space) in the svn because it is not stable.
On linux it is automatically compiled. But I do not know if it possible on windows. You can still use poedit to compile the po file and puts the result in the langs directory. -> Langs/zh_TW/pcsx2_Main.mo
On Windows it's currently not compiling any po's automatically.
We could start putting them in now though, so we get a bit of feedback :)
Rama, When you said "putting them" you deals with the mo file (result compilaton of po)? If yes, I can either puts them in svn or in the download section.
I agree with you feedback will be nice.

Revision 4389

* allow to translate the about box
* Fix a crash when wx did not support the default locale
Thanks for taking the time on the crash, greg.
it is always good when we can translate a place that we normally cant, congratulations.

Revision 4390

i18n:forgot one string in the aboutbox

Revision 4391

pcsx2 gui:
* Fix log folder path selection.
* half fix the plugin folder path selection. Ie the use default selection.
However the register setting must be saved after the path updates.

Revision 4392

pcsx2 gui: (will love review and big test)
* Really save the reg-setting (ie the plugigns folder path)
It saves settings just fine; tested by deleting PCSX2 entries in the registry and then starting PCSX2.
What's a CustomDocumentsFolder, though?
The value is the same as Install_Dir.
Anyway, here's the list of entries that's saved when starting a fresh PCSX2 "installation" :

Revision 4393

i18n: upload portuguese and turkish translation
There are now 2 /trunk/locales/pt_BR/pcsx2_devel.po files, one named pcsx2_devel.po and the other called pcsx2_Devel.po ('D'/'d'). The more recent one seems to be pcsx2_devel.po . Windows files system is case-INsensitive, so that creates an issue when checking out.
Please delete (or rename) one of them.
Yeah, in Windows it caused TortoiseSVN to 'merge' the files (pcsx2_Devel.po & pcsx2_devel.po), creating one pcsx2_Devel.po file.
And then it also created two different file entries in the 'entries' file for both files, effectively made TortoiseSVN thinks that pcsx2_devel.po file is always missing.
Thanks, however one silly question. Is it window that does not properly support the case or svn tool ?
It's just that Windows are case-insensitive to file names; pcsx2_Devel.po & pcsx2_devel.po will be considered the same file.
TortoiseSVN itself is case-sensitive by design, which is why it went haywire when it detects only the pcsx2_Devel.po file.
Because even when I chose to revert the 'changes', TortoiseSVN will try to 'restore' the 'deleted' pcsx2_devel.po file, but Windows effectively changed the name back to pcsx2_Devel.po, effectively rendering TortoiseSVN having a bit of a brain fart.

Revision 4394

onepad, zeropad: init the sdl video subsystem (sdl 1.3).
cmake: allow to compile pad with sdl 1.3
That strange I did not write any mention on GSdx! I think it did not understand that the video subsystem control the input...
Come on guys, keep the bashing out of the code comments.

Revision 4395

microVU: minor changes
nice, good to see cotton again ;)
Hello, Recently I'm geting problems downloading latest revisions using
svn. Here's the error info I'm getting. Any help will be appreciated.
A pcsx2-read-only\locales\pt_BR\pcsx2_Tertiary.po
A pcsx2-read-only\locales\pt_BR\pcsx2_Iconized.po
A pcsx2-read-only\locales\pt_BR\pcsx2_Main.po
A pcsx2-read-only\locales\pt_BR\pcsx2_Devel.po
A pcsx2-read-only\locales\pt_BR\pcsx2_devel.po
svn: In directory 'pcsx2-read-only\locales\pt_BR'
svn: Cannot open file 'pcsx2-read-only\locales\pt_BR\.svn\tmp\text-base\
pcsx2_devel.po.svn-base': File not found.

Revision 4396

Menu: recent-ISO-list (dynamic list with automatic menu IDs) was clashing with
other fixed menu IDs (specifically, the first item on the recent ISOs list got
an "automatic" id of 100 (decimal) which happened to clash with multitap 2 menu
item. Result: when clicking multitap2 menu item, the first iso gets selected
instead - multitap2 menu was b0rked).
Solution: reserve 100 IDs for the recent ISO list and use them.

Revision 4397

Probably a mistake file name (newer file with same file name [except for lower-
case 'd'] exists)
Main reason for this rename is that it checking out on windows was broken. Windows doesn't support case-sensitive file names, so it aborted at the middle of check-out because of file names conflicts.
Did you do a move? You move the wrong one :)
Ok I restore the good one. And remove the others. Thanks
Wasn't sure, so just renamed one of them. Figured out you'll fix it soon ;)
Yes, it was better to do it. In the week day I have some difficulty to access my computer. Anyway next time I will be cautious.

Revision 4398

i18n: properly fix the mess of case-sensitive
+1 for fixing problems with svn on Windows.

Revision 4399

i18n: * add poedit metadata after generating the pot files. It seems to be
useful after all :p

Revision 4400

i18n: Use a big in D in the code too... Probably impact only linux user

Revision 4401

1. Removed Exclusive-mode checkbox from GS-window-panel (wasn't working anyway).
2. Removed vsync from presets.
1. the exclusive-full-screen checkbox isn't connected to anything, AppConfig
doesn't store this value, and the (GSsetExclusive) API is never used from PCSX2
(but seem to be supported by GSdx).
2. Now both vsync and auto-vsync are excluded from the presets (both never
grayed out and never affected by the presets)

Revision 4402

microVU: Merge some changes I did in the ReorderingMTGS branch with trunk.

Revision 4403

microVU: Fix constant recompilation problem in Street Fighter EX3
I think the last 2 mvu commits did something good to the speed...
the r4395 minor changes revision is a small optimization but i wasn't sure if it was noticeable so didn't mention it.
the revision before this shouldn't effect speed since its unused code.
This current revision does effect speed but only for the games that had the bug which this revision fixes (street fighter ex3 and driving emotion type-s, possibly others)
Good job :)

Revision 4404

GSdx: optimized the triangle setup of the rasterizer a bit, while it isn't the
bottle-neck of drawing, it can still add a few percent to the fps.
this changes affects only SW render o both?
It's for SW only. DrawTriangle can still consume 1/4 of time for large batches of small triangles, only a few pixels each.
nice work gabest, great to see improvements :D
In before a negative from roo in 3...2...1...
Anyway, nice to see performance improvements for the SW renderer.
Does this affect specific GSdx optimizations (SSE2, SSSE3 or SSE4) or an overall speed up?
Overall, in scenes where many tiny triangles are drawn at once. I'm mostly using the horse of SoC for testing, in prev build it took 26.x million ticks, now about 22.x, of which 8 is spent if I just call an empty DrawScanline (the "pixel shader" of the sw renderer). The starting blob of aura for laura is another good one, it puts 34.5k triangles into the vertex buffer at once, 31 million ticks total, 13 when running empty. You can guess the fps if you divide 3GHz with these numbers, including the time of all other drawings of course, but if nothing else is drawn that means 96 fps. Then let's I can reduce the triangle setup by another 6 million somehow, then it will be 120 fps. Most games however do not use such complex models, or if they do there are other things to slow down the frame rate, the effect of optimizing this part is a bit limited.
Somehow that reminds me of TWIMTBP games that render unseen triangles that Nvidia cards don't have a problem with but often stumbles AMD cards.
Btw, something tells me gabest loves his VS2010 too much. =b
2 linking errors on VS2008.
One from GSdx :
GPUDrawScanlineCodeGenerator.obj : error LNK2001: unresolved external symbol ___xgetbv
One from pcsx2 :
x86emitter.lib(cpudetect.obj) : error LNK2001: unresolved external symbol ___xgetbv
Try SP1.
...that might be it.
I usually use VS2008 on my desktop; currently on my laptop, in which I just installed VS2008 (it only had VS2010).
Have to get the SP1 later; hefty download.
Thanks for the tip.
drop 2008 and congrats gabest for the optimization.
It's not like people use VS2008 only to compile PCSX2.
Besides, ZZOgl still doesn't compile properly on VS2010.
Gabest, Arcum, I maybe found the reason for the unexpected crash on linux.
I test only mana khemia, but all crash occured on instruction like push; mov something into the stack. I'm nearly sure that we have a stack overflow. (at the crash time $ebp-$esp ~~ 4k). If I'm correct by default linux (kernel) have a stack of 4k, it might still (it was possible a long time ago) be possible to recompile with a 8k kernel.
I do not know how we can reduce the stack usage of GSdx. I try to remove the forceinline (keep only some mandatory in .h file) without real success.
Well that might be the big one actually.
It is definitively a stack issue. I have found a magical command to change the stack size on linux.
Show current size
# ulimit -s
Set bigger size
# ulimit -s 32768
With this change I go a little further. Now it is crashing on the pad. Seem to be an issue with _IO_vfprintf_internal (surely SDL related)
Stack size should not be OS controlled, at least on windows you can set it on thread creation or it's a linker setting for the process, there is also a pthread_attr_setstacksize function.
But that 4k sounds way too small for anything. Stack is not alloceted in one piece, rather in pages, and the overflow (or underflow if you want) is trapped by an exception handler to commit more pages until it reaches the maximum size, which is 1 MB on windows by default.
Since you said it was about 4k, which equals the page size, you might just ran into that exception, normally the handler should add more space then and resume execution, unless it really hit the maximum.
Yes you are right. I mix kernel stack constraint and the user-space stack, sorry. Did you change the maximum size on windows ? On linux it seems to be 8MB which is already quiete big. Anyway the more the merrier ;) With 32MB GSdx seem to work better.
I set the limit before the compilation of PCSX2. Maybe gcc query the value and use it at the link stage. I do not know. I would do some test later.
Everything is compiled with the default 1 MB. I don't know about the linux kernel too much :P
I don't have time to play with it right now, but the setrlimit command looks promising:
Basically, if you include <sys/resource.h>, and have:
rlimit limit;
Then if you call
int err = getrlimit(RLIMIT_STACK, &limit);
limit.rlim_cur is the stacks soft limit, and limit.rlim_max is the hard limit. You can then fiddle with the values, and then do this to change them:
err = setrlimit(RLIMIT_STACK, &limit);
Haven't played with it too much yet, though.
I try to use the function without success. I put the call in the Pcsx2App::OnInit() function. But I think it is already too late.
I download the source of my shell to look at the ulimit built-in. Actually it is only a wrapper to the getrlimit/setrlimit functions. So it must work.
I think I found more interesting info. It seems there is a stack leak ! Honestly I do not know it is possible.
Everytime SysMtgsThread::ExecuteTaskInThread() calls GSgifTransfer* (check only the P3) functions, there is leak of 8 bytes ! Because ExecuteTaskInThread never ending it uses all the stack, just a matter of time.
If a function did not clean up the stack properly ret would jump back to the wrong place, since eip is on top.
I think I will make some comparaison with zzogl.
The strange things is after the call of the function, there is an esp allocation (minus 8):
0x80aa0e4 <SysMtgsThread::ExecuteTaskInThread()+898> mov %edx,0x4(%esp) 0x80aa0e8 <SysMtgsThread::ExecuteTaskInThread()+902> mov %eax,(%esp) 0x80aa0eb <SysMtgsThread::ExecuteTaskInThread()+905> call *%ecx 0x80aa0ed <SysMtgsThread::ExecuteTaskInThread()+907> sub $0x8,%esp
Extract of zzogl:
00074842 <GSgifTransfer2>:
7485a: c9 leave
7485b: c2 08 00 ret $0x8
Extract of gsdx
00b5ac5 <GSgifTransfer2>:
b5ae6: c9 leave
b5ae7: c3 ret
There is somethings wrongs with the interface between pcsx2 and gsdx
I do not know what is the proper way to fix it.
1/ include PS2Edefs.h, probably not possible
2/ add a stdcall attribute to the EXPORT_C macro. The easiest solution.
"ret 8" is fastcall, at least on windows it would mean that.
No, wait, with __stdcall function cleans the stack, too :P That might just be the problem then.
Actually function are defined PS2Edefs.h with CALLBACK macro which is stdcall. I try stdcall, and I successfully start mana khemia and play one big (5 minute) battles without any crashes.

Revision 4405

GUI cleanups
1. "backup save-states" removed from the MCD manager and added to the system
menu (checkbox) just below "Save State".
2. removed multitap 1/2 from the config menu (now only available on MCD manager
- this setting doesn't affect pads anyway).
3. Following rama's advice, vsync and auto-vsync are now both forced to off for
all presets (and grayed-out when using presets).
//2. removed multitap 1/2 from the config menu (now only available on MCD //manager
//- this setting doesn't affect pads anyway).
What tha hell? You need to enable multitap in both the emulator and the controller plugin to be able to utilize it in games that make use of more than 2 controllers, didn't need to be removed.
And better rename the option "Backup existing save state" or something, currently it doesn't exactly what it's doing.
Ok, I wasn't aware of the fact that it should be enabled for multiple pads. In that case, it should be on the menu as well. I'll do that soon.
About the "save-state-backup" renaming, it can be improved. for starters, it can probably have the original tooltip. Other than that, the main issue is that it's completely unrelated to the memory card manager, so it was removed from there. If it's left at the menu, then it can't be too long (but probably still be ok is slightly longer than now).
Thanks for the comment.
Better remove the multitap option from the memory card dialog and leave only the one in the Config menu. When the menu option is enabled the multitap memorycards should get enabled automatically anyway, what's actually being enabled is the multi-tap as a whole, not just the cards but both pads and memcards at same time like the real multi-tap device would.
Yes, that sounds better. Controlling the same option from two different places is usually unwanted as it can (and did) create inconsistent behavior when changing them at one place and expecting them changed at the other place (both places were changing the exact same configuration).
I got an idea for the new option name, just make it a simple "Backup Save".
It's got the tooltip and it'll be in a menu full of savestates anyway.
Or quick save to go with something that users will immediately recognize.

Revision 4406

Memory card manager: fixes and improvements:
1. Bugfix: when multitap 1 was disabled, multitap 2 slots were not showing at
all on dialog load (were showing only after disable+enable of MT2).
2. Bugfix: when multitap 1 was disabled and refreshing the list, multitap 2
slots were showing (the disabled) multitap 1 slots,
3. Improvement: the "Slot" column title is renamed to "PS2 Location", and now
contains a proper name instead of an unuseful number.
4. MCD manager is now resizable (though the mcd list only gets resized
horizontally for now, but I did make it slightly higher to allow the maximum 8
slots without vertical scroll - on my system)
That doesn't exactly look clearer to me just... has more words :p
The major thing is the two bug fixes. Without them, the manager is unable to do anything at all with multitap2 slots 2,3,4 (when multitap 1 was disabled).
The names instead of numbers is just because the numbers had no meaning at the list (while internally they do have meaning, and it's now expressed in words also at the list).
And also, it's a preparation for hopefully custom file names, where you want to know at what ps2-slot you insert a specific file, and the file name doesn't necessarily represent the slot it's inserted into because you can move the files between slots, and you want to keep the file name unmodified for each file (e.g "Multitap 2 slot 4": "GOW2-chapters-1-to-6.ps2").
I see no reason why not make the name translatable :)

Revision 4407

GSdx: still working on the rasterizer, would be nice to add some avx code there,
but it's just so unfitting for anything.
Dunno what's causing it but in Kingdom Hearts 1 (SCES-50967) there's a minor bug in the HP/MP bars. Nothing major but I thought you might want to know anyway.
The description: piece of the curve is not smooth like the rest.
Checking... The line drawing was modified a bit to be faster, after I noticed how lame the fight transition in FFX is done. Texture mapped lines are drawn from the center of the screen in circles for a blur/zoom-in effect. That slowed it down a lot.
It's that special transition only, in the introduction, in zanarkand.
Could you upload a picture of the bug? Which renderer was it?
Here you go gabest
The renderer is DirectX10 in Software mode with 3 threads.
If you look at Donald's HP/MP bar you'll see what I'm on about.
BTW it's not always on/only Donald's HP/MP bar. It also seems to be random in when it occurs because sometimes I don't see any problems at all.
Never tried Hardware mode so for all I know it could be PCSX2's core or the game itself. In any case it's not major enough to stop me playing.
On another note I'd like to express my thanks to you all for building an emu that achieved something that not even my PS2 was able to (even though it should've as it was part of the storyline), in KH1 my PS2 would crash on the final cutscene where the trees popped out of the ground, PCSX2 did not so thank you very much enabling me to see the rest of that scene.
The PCSX2 forum has a developer section where we track our current work.
It's members / devs only, so feel free to drop by ;)
(The GSdx Linux crashing is discussed there for example, complete with logs and stuff.)
Any idea what that could be on the sky? How does the original look like?
There it is. Only appears if the mipmap levels are used. Level 0 is empty.
SotC does a lot of tricks to exploit the PS2 hardware as best as possible.
This could be one of the many sky layers or some blending effect, dunno.
gabest, Eliot_cougar from the PCSX2 forum ( http://forums.pcsx2.net/User-eliot-cougar ) has a SoTC specific GSdx patch which prevents the sky from over-glowing. The patch didn't make it into GSdx, but I'm sure he'll be glad to share his thoughts with you about it.
He did publish his code modifications somewhere on the SoTC thread ( http://forums.pcsx2.net/Thread-Shadow-of-the-Colossus--4737 ) but AFAIK the latest patch was not publish in source form.
Might be worth talking to him.
This is not a d3d problem. There is simply a dark cloud over the canyon which only shows up when mipmap levels are used instead of the regular level 0 texture. They knew it is always inthe distance and did not bother drawing the highest detailed level texture which I always use currently.

Revision 4408

Fix for Justice League Heroes not going ingame.
nice^^ ty
now if only the game would work correctly xD
which is prolly never gonna happen... then again I could've said the same thing about Star Ocean 3 ^^
Nothing else broken so far :p
Nothing should be broken, hopefully only fixed :P
I was only comparing nloop to 8 qwc on that code, so if the nloop was 400, 8 was my constant, 8 qw would transfer, however if the available size was less than 8 (which justice league was doing), it would cause errors :P
game fix +1.

Revision 4409

Moved the "Print CDVD info" menu item to console logs.

Revision 4410

Memory cards manager: bugfixes (all of them when multitap 1 is disabled) +
better internal terminology:
Port (used only for presentation): actual PS2 port: 1-based index (1 or 2 or
multitap X port Y, whrere X is 1/2 and Y is 1/2/3/4 )
list-view-index: the running index (0-based) on the MCD viewable list (first
always 0, last is always <num-items-on-the-list>-1).
Slot: pcsx2 internal slot representation. the slots are always fixed as follows:
slot 0: port 1 (or multitap 1 port 1 if multitap 1 is enabled)
slot 1: port 2 (or multitap 2 port 1 if multitap 2 is enabled)
slots 2,3,4: multitap 1: remaining 3 ports
slots 5,6,7: multitap 2: remaining 3 ports
The terms view-index and slot were used interchangeably (and always called
'slot'), and this was causing many bugs when multitap 1 is disabled (because on
that specific case the view index doesn't align with the slot - because the
multitap 1 items are not on the list). It should now be easier to follow the
code and further modify it.
Good job. Seems to have taken care of the remaining issues.
making the strings translatable can be better as "Port"/"Multitap" are normal English words rather than some Abbreviations.
_("Port-%u or Multitap-%u-Port-1")
_(" Multitap-%u-Port-%u")
weimingzhi, I don't understand if you're happy with the change or if you're suggesting a better approach (at which case, please describe it again)...
not really "a better approach", just some minor stuff.
Replace this:
case McdColS_PortSlot:
if (!it.IsMultitapSlot())
return pxsFmt(L"Port-%u or Multitap-%u-Port-1", it.GetMtapPort()+1, it.GetMtapPort()+1);
return pxsFmt(L" Multitap-%u-Port-%u", it.GetMtapPort()+1, it.GetMtapSlot()+1);
case McdColS_PortSlot:
if (!it.IsMultitapSlot())
return pxsFmt(_("Port-%u or Multitap-%u-Port-1"), it.GetMtapPort()+1, it.GetMtapPort()+1);
return pxsFmt(_(" Multitap-%u-Port-%u"), it.GetMtapPort()+1, it.GetMtapSlot()+1);
Ahh, yes, thanks. I wasn't paying too much attention to what gets translated so far because these are still partial changes and the texts are not yet final. It will be properly translatable soon. Thanks again.

Revision 4411

SPU2-X: moving some code out of a header.

Revision 4412

microVU: Minor changes/cleanups
Other speed improvements you're not letting us know ?
nah not this time :p

Revision 4413

Add an extern for the Linux side of things...
weird my code compiled w/o that on msvc, probably because i haven't clean+rebuild.
neways i'm still cleaning up mVU so i'll fix that on the windows side as well.
It's actually possible that it might compile properly on Windows regardless. I've seen times before where the code compiled fine in Windows, but was missing an extern that really ought to have been there (and that Linux wanted).
(And I wrapped Linux ifdefs around it because I didn't have a chance to test the change in Windows, and the oddest things can break Windows builds occasionally...)

Revision 4414

GSdx: Set up a new gsdx-linux-dev branch to play with.
This way we can do things like add a bunch of debug messages, disable alignment, disable __forceinlines, etc... for the purposes of debugging without worrying about slowing down or breaking GSdx on Windows.
I thought this might be easier, since we already have at least two patches we're fiddling with...
Is it possible to run gsdx using intel gma 950 on linux ? Because I can t run pcsx2 on linux.

Revision 4415

microVU: more cleanups (mostly just change pointers to references)
Both mVUclear and mVUblockFetch are declared as static and have externs in microVu.h. Linux also needs <algorithm> included in microVu.h.
I figured I'd leave it up to you if you wanted those functions to be externs or static...
is gcc fine with just leaving out the static/extern keyword completely from the function prototypes?
the only reason i put them in there was because i didn't want gcc to complain.
If you have a function prototype without the extern keyword, it treats it as if the extern keyword is there. The main thing is just that if you have a function that's static, it doesn't like it if you have a prototype in a header for that function. It will let you get away with it if you have the static keyword on the prototype, though. It's mainly because it figures you are trying to give it two contradictory scopes, and gets confused.

Revision 4416

GSdx-Linux-dev: Disable most __forceinlines for now.
I think my patch can be reverted :p
See last comment of r4404. Unfortunately I do not know how to fix it!
I might be interesting to keep the 2 forces inlines. And remove the standard forceinline in debug.
Well, debug build does not inline anything, even forced.
To be honest I was surprised, normally it need some optimization (ie at least O1) to inline function. If you disable all forceinline, the code did not link, so it inline some functions.

Revision 4417

microVU: fix gcc compilation (probably)

Revision 4418

gsdx-linux-dev: use stdcall attribute which fixes several crashes
Looks good. Once the forums are back up, I'll check it against my list. And I'll probably revert the __forceinline patch. For that matter, since this commit has no chance of affecting Windows, we can send it straight to trunk; I just thought it'd take longer to figure out the crashing bug... ^_^
Well, I've tested with all the crashes I remember and they were gone. Atelier Iris 1 had minor graphical issues, but that's a different matter...
So Linux has a working GSdx software implementation now?
Mostly. There's still a crash in Ico, and it still needs most of the configuration rigged up. Also, I need to figure out why it crashes in Gentoo but works in Ubuntu. (and see if that's still the case, for that matter.)

Revision 4419

GSdx: using mipmap levels (only per batch, no tri-linear) and a couple of small
changes, including the stdcall fix for linux.
The mipmap on/off key is "insert", I hope nothing else is assigned to it already.
Good change.
1. I understand it only works in software renderer? Any chance to somehow allow mipmaps also on HW renderer?
2. Didn't test it much, but on PES2011(PAL) using mipmaps seem to introduce some faint vertical lines (beyond smoothing and reducing aliasing).
Here are screenshots:
without mipmaps: http://www.imagebanana.com/view/iev7zzcl/PES2011PALnomipmap.png.jpg
with mipmaps: http://www.imagebanana.com/view/tvou3oxw/PES2011PALyesmipmap.png.jpg
HW has higher resolution to hide aliasing, but it would be possible to even do tri-linear filtering with pixel shaders for native resolution.
I think the lines you are seeing are the result of dithering.
Virtua Tennis looks pretty bad without interpolating the levels, the change is at the third of the court.
Cool stuff! curious to see how the ratchet games look with this :)
Very fixed :p
Would be cool to have this in the HW renderers as well :)
Some textures looks too flat to me. It really could use a trilinear filter.
The big thing is that these mipmap errors are mostly gone now.
There's more games with severe mipmap issues like that, going to test them these days :)
Gabest: My missus thanks you greatly for this :P
Yea, but it's all fake, I'm still not satisfied with it. But just hacked in the LOD = log2(q) << L + K formula into the per pixel processing in assembly, the hard part is still ahead, applying clamp/repeat on u/v and sampling two textures using that small set of xmm regs x86 can offer.
Nice job! I was hoping for some form of mipmap support and at least this shows you're working on it! Hoping for the best :)

Revision 4420

GUI: added an event for panels to use to inform the configuration dialog that
the configuration has changed by means other than the user directly editing
Cheers :)

Revision 4421

GSdx: just a typo again
On VS2008 GSdx doesn't compile (not sure if this specific commit broke it). This is the error message (repeating many times because it's at an .h file):
\pcsx2\trunk\plugins\gsdx\GSVector.h(3703) : error C3861: '_mm_blendv_ps': identifier not found
Sorry, VS2008 express.
Sorry, final summary for VS2008 express:
On "Devel" build, GSdx fails to build with the following error repeating many times:
pcsx2\trunk\plugins\gsdx\GSVector.h(3703) : error C3861: '_mm_blendv_ps': identifier not found
On "Release SSE4" build, , GSdx fails to build with the following error repeating many times:
pcsx2\trunk\plugins\gsdx\GSVector.h(2661) : error C3861: '_mm_testz_ps': identifier not found
Try a new revision, blendv is SSE4, forgot to move it inside the ifdef.
Hm, vtestps is apparently not the same thing as ptest

Revision 4422

gsdx: really close the windows when closing/shutdown emulation
Note: Only impact linux

Revision 4423

Memory cards manager: allow custom file names (create/rename/copy), still
without assigning arbitrary MCD files at the folder. TODO: 1. allow assigning
arbitrary files at the folder. 2. GUI cleanups (text alignment on some messages,
MCD list vertical stretch..) 3. code cleanups (remove all commented/unused
This is a relatively big change of the MCD manager, so I'd appreciate feedback
(functionality, translations, bugs, etc).
didn't look at the code yet far too invested in pokemon atm but sounds awsum^^
Very good, but i have a problem, when i enter the MC Manager it shows no memory card, so i have to click the refresh button to see the loaded memories.
anyways i think it's a very nice change.
Thanks. This is strange. I only changed the way cards are displayed. Not when to display them..m
Before you click refresh, is the MCD area completely empty? or does it shows the ports names but without cards in them?
Can you please show me screenshots of before and after you click refresh? and also similar two screenshot from an earlier revision that didn't have this bug?
Thanks in advance.
OK, rama helped me reproduce it. It'll get fixed. thanks for the report.

Revision 4424

GSdx: the usual fixes for gcc.
There is a warning for the usage of offsetof. GCC is sooo annoying.
ICO is still crashing in the intro, but Persona 4 runs nice.
Yeah, I saw that. This page gives the general gist of what it's about:
In the meantime, adding -Wno-invalid-offsetof to our list of compiler flags will suppress it.
Nah Persona 4 runs nice but there are Battles with some Monsters that have Reflections and it slow down the Emulation
Some Monsters have no Reflections so there are no Problems and there are no Slowdowns
Same with Persona 3 =)
Yeah, I did some testing and the various crashes I'd noted were gone. The dialog boxes in Atelier Iris 1 had lines above all the text and sometimes totally covering the text, but otherwise things seemed to be working all right.
This change fixed the compilation error with VS2008 express for "Devel" (_mm_blendv_ps not missing anymore)
but on "Realease SSE4" it still fails to build with the same message it had before:
GSVector.h(2661) : error C3861: '_mm_testz_ps': identifier not found
[email protected]: That's D3D, isn't? We are talking about crashes of linux now.
arcum42: But why GSVertexSW is not a POD? It has GSVector4s in it, GSVector4 has only simple types, and no virtuals in either class.
Gabest can you give me a small favor? Could you update copyright header of these files:
./GSVector.h: *No copyright* UNKNOWN
./stdafx.cpp: *No copyright* UNKNOWN
./stdafx.h: *No copyright* UNKNOWN
./resource.h: *No copyright* UNKNOWN
./xbyak/xbyak_mnemonic.h: *No copyright* UNKNOWN
./xbyak/xbyak_bin2hex.h: *No copyright* UNKNOWN
./xbyak/xbyak_util.h: *No copyright* UNKNOWN
./xbyak/xbyak.h: *No copyright* UNKNOWN
Thanks you very much.

Revision 4425

Linux compilation fixes.
One of these bizarre quirks in gcc is that in the (flag)?x:y; construct, x & y have to be the same variable type...
Hmmm... what exactly breaks before your change? (I looked at the change and didn't understand what was wrong...)
oh.. ok, thx :)
MSVC doesn't like that either.
np. I've gotten to know most of the little things that break gcc pretty well... ^_^
On that case, I'm happy it's only these small changes :)
Cool you're keeping the gcc port usable.
Also, what didn't work with the anonymous event?
It gave the following error:
/usr/local/src/pcsx2/pcsx2/gui/Panels/MemoryCardListPanel.cpp: In member function ‘void Panels::MemoryCardListPanel_Simple::OnRenameFile(wxCommandEvent&)’:
/usr/local/src/pcsx2/pcsx2/gui/Panels/MemoryCardListPanel.cpp:859: error: no matching function for call to ‘Panels::MemoryCardListPanel_Simple::AddPendingEvent(wxCommandEvent)’
/usr/include/wx-2.8/wx/event.h:2405: note: candidates are: void wxEvtHandler::AddPendingEvent(wxEvent&)"
I might have been able to cast it, but this seemed easier, since I knew it worked in other areas of the code...
Interesting... thanks.
"One of these bizarre quirks in gcc is that in the (flag)?x:y; construct, x & y have to be the same variable type..."
That's not a bizarre quirk. That's a safety requirement. Otherwise both variables would have to be upcasted (behind the scene) to the larger type for the same reason why "int a = sub(int a, byte l)" can't return byte.

Revision 4426

GSdx: one more fix for vs2008.
That did the trick. Thanks :)

Revision 4427

i18n: news string for translators.

Revision 4428

GSdx: When mipmapping is on, LOD is calculated per pixel, it isn't used for
anything, but it's there. I cannot really measure any significant slowdown, but
rest of the fun is yet to come.
Rest of the fun?.. Yeah, keep'em coming... I'm getting a new PC today so I'll be testing every revision...
I'm getting a crash with this GSdx build when using software renderer on XP32/SP3 (E8400, SSE4.1 GSdx build).
PES2011: menus work OK, crash is when actual 3D stuff starts (when starting a match).
Yep, crashes in sw mode when mipmaps are used.
I suppose it's a < SSE5 issue again. (Using an E8400 here, so SSE4)
How to turn mimpmaps on? I hit Insert in SW mode and nothing happens...
They're enabled by default if you switch to sw. Hitting the insert key will toggle them off.
Most games don't seem to be affected by this implementation though.
Copy-pasted the avx version of the log2 code, oops :P
Ah, right, just about when I'm going to ask about why the new mipmapping didn't seem to affect anything; only tried it on FM5 and the world map of AT2, though.
Btw, gabest, SP1 did fix the compilation issue with VS2008 I mentioned a few revisions back; thanks.
The mip mapping will only work in software mode and on games that use LoD, such as the ratchet and clank games.
thanks for the explination.
I can adjust the mip bais on nvidia cards so it's not such a biggy but if I couldn't I'de probably prefer to disable it.
I assume it's a ps2 thing though and nothing to do with hardware acceleration from the sounds of it.
And @ roo.. whatever your nick is (sorry it's cut off).
You gots to stop putting neg's on these just because you're mad about something.
Seriously dude it's not cool.
Regarding slowdowns, didn't notice anything significant.
On FM4 opening cutscene, where wanzers attacking a base, it dips under 40fps when the explosions due to the missiles hitting the tanks show up, but that's perfectly normal.
Most other times, it's 50+ fps.
I set the SW mode to use 2 threads, because this CPU has 4 logical threads and I thought the EE and SPU should get its own threads.
...unless I'm very mistaken; open for correction, though. =b
Turbo Boost did kick in when in-game, though.
Usually around 2.7~2.8 GHz (maxes @2.9 GHz, but that's rarely); checked with CPUID 1.57, so idk if that's really accurate or not.
Btw, any suggestions what other games beside PES or R&C series that uses LoD?
I don't own those games.
Just wanna know if this rev's changes would crash on my system too.
In any case, can't wait for those fun things. ;)
That psrlw instruction makes things really difficult here. It would be just too easy if I could shift the texture coordinates by their own level individually. I'm thinking of cheating a bit and using the lod of the first in a 4 pixel group.
Can someone just ban roo already. All these stupid negatives that have nothing at all to do with the commit are really starting to get annoying.
Bloody kid, he needs a bloody lesson...
Working on it
Hacks section cannot be enabled in the recent Gsdx versions... I really need that half-pixel offset hack, but can't enable it in gsdx.ini...
I was curious if roo had an username on the forums. Looks to me like he does...
Looks like he was complaining about the same prob I was some time ago, tex alignment issues.
Which effect alot of game not just that one, it's pretty obvious though.
And I know we've talked about it in the past and there had been attempts made.
I'm personally interested in any kind of fixes though, I ain't gonna keep bothering someone every time I post about it lol.
It's rude...
"I'm thinking of cheating a bit and using the lod of the first in a 4 pixel group."
Sounds like a good solution to me ;).
Should be faster and better looking at the same time, for the games that it effects.
I got huge slowdowns in battle in Tales of Legendia, this is a game that can only be played in sw mode, i got normally +44fps (with speedhacks and frameskip) thats playable enough (59fps in town so it was very playable), but now it goes down to 9fps in battle, i'm not really sure if this is the cause but R4406 and R4407 worked fine.
Thanks for your hard work.
Sorry I meant R4404 and R4407.
I'm going to test other revs to see when the slowdowns started.
Just tested a bunch of other games, and it turned out Shadow of Colossus is also one of the games that crashed on SW mode.
It didn't crash on 4426, ran beautifully on wtflol ~10fps. =b
I didn't see much differences when toggling mipmapping on & off, though.
Is it possible to put a notification on the console window or GS window to indicate whether mipmapping is on or off aside from graphical cues?
Just tested SotC on r4444 in Software mode... Works fine, looks fine, has some water glitch... Does not crash as far as I played it...

Revision 4429

Swedish translation files by pg... .
Thanks a bunch :)
I was planning to do it tonight. Thanks.
Anyway I will update everything(pot and others po). I think we can begin to ship mo file in the bin/Langs folder for windows users. However I do not know if the MS installer will copy the full directory or if it need an update.
The installer will need an update.
We'll do that sooner or later :p

Revision 4430

* refresh pot and po files. Pot includes poedit meta-data
* upload chinese and brazilian
* Provide mo file for Windows user. You can select your language during the
first time wizard (pcsx2 --forcewiz). Test and feedback are welcome
The first time wizard (with language selector) also shows up if you "clear all settings" ( config > clear all settings ).
I did a quick test and after deleting the 2 old pcsx2 ini files it worked like a charm.
Looking good! :)

Revision 4431

Updates for most new strings for de_DE.
Left out the new memory card manager strings as they're changing yet :p
Good work.
Please can you ban this [email protected] moron.
Whoever he is he's making a mess and disinformation
on recent updates of pcsx2 by adding -1 notes to all of the updates.
WTF is wrong with this dude. Get yourself a girlfriend or something.
i don't need gf, i just need a fix for my game.
your game works you're just too much of an arse to see that software renderer works wonders and looks exactly like on the ps2
We can't ban single users, unfortunately.
We could disable code comments altogether, but we won't let the kid get his way.
Btw, high time I visit dammartin en goële in ile de france again :>
i am not a kid i am 21 years old and you?
Age doesn't matter much; you're acting like a 6-year old, whining about your broken toy.
Honestly, buy a japanese ps2 -> http://www.play-asia.com/paOS-13-71-o-49-en-70-2ee2.html or go to ebay or whatever...
Or go annoying Sony Corporation because of the region locking.
no i am just a SRT's fan who can't play with glitches or mecha pixelated
Then buy a PS2 for only max. 50 euro on ebay!
In a way, the PCSX2 dev team has contributed something towards a greener world, because they've made one person not to sit the whole day playing SRT on his PC because of the PIXELATED MECHAS FTL; carbon footprint reduction yay!
Check it out, totally unplayable:
lol seriously..
Build yourself a mecha and go outside to play..
Lol,playing video games... what a child... Wait a sec. we all play video games. :P
somebody could tell gabest to remove the small changes/fixes he did to robot taisen? so this way he will suffer more. ;)
@roo: Dude. I have heaps of my games broken. And am I complaining as much as you?
No, of course not. Just wait like the rest of us. Stop giving the team a hard time :(
I said before [email protected] was gonna be our resident -1, guess I wasn't wrong xD
Guys, please make PCSX2 100% perfect except for his game, make it 100% unplayable...that would be awwwesome :D
Wow, who is this rookod jack-ass? Giving negative marks on an entire page of revisions? For no good reason other than "fix my game?" What a douche... you're game can't and won't be fixed so easily. It takes time and lots of little fixes. Get over it your ignorant pinhead.
I can't believe Google still hasn't implemented some form of moderation that doesn't involve shutting comments off altogether.
roo If you want something so minor fixed so badly then learn C, download the PCSX2 source and fix it your damn self you arrogant a*****e. The team that builds PCSX2 are not your slaves and deserve respect for the effort they are putting (out of their own free time I might add) to build a PS2 Emulator of such good quality.
Guys, stop giving roo (I don't care if his full e-mail addy is 'rookod' or 'rooser') a hard time...I'm afraid the next time he posts a reply here it'd be from his parents... *hides on closet* *runs to Narnia w00t*
To the Dev team- Is there no way to contact google about this issue and give you the ability to ban this guy or to shut off his review scores ?
Well you can issue a formal complaint about an user who is abusing comments in an open source CVS. It depends how throughout would be Google, but the results can vary from warning from local police to few months on parole for a continual abuse.
All your comments are useless for me,they don't help me to fix my game...except maybe Gregory.Instead you blame me,explain me the cause of his graphical issues on my game ...thanks...
I've reported him to Microsoft (as he has a hotmail account). We'll wait and see what'll happen. Warning from the local police would be nice.
1) PCSX2 is a free application. The PCSX2 developers (who work on PCSX2 in their spare time) have no obligation whatsoever to do any work on the project. This includes working on a fix for your game. Be patient, and show some damn respect for the developers.
2) Giving negatives to all commits (which is very rude) is not how you should be communicating with the developers. First, you investigate the issue yourself. Which revision did the game stop working (if it ever worked)? Trying different emulator setting might help too. If all this fails, you can submit a new issue to the issues tracker (providing it hasn't been reported already).
3) If you are dead set on running the game on PCSX2, use an older version until the issue is fixed?
4) We are not blaming you for the issue itself, we are blaming you for spamming negative reviews on all commits.
Sorry for the white knighting, but stuff like this really gets on my nerves.
He won't read sentences containing more than 10 words, unless it has 'Super Robot Taisen' in it somewhere.
The kid still thinks someone will tell him the magic fix for his game.
sad panda is SAD

Revision 4432

Changed "Suspend" to "Pause", as per request.
I suppose youll be wanting "Savestate" changed to "Snapshot" next too ;p

Revision 4433

MCD manager: refinements and improvements:
1. automatic apply of create/delete/copy/rename without the annoying "do this
and that" dialogs.
2. auto-eject/insert mcd after mcd changes (useful especially when replacing one
enabled-and-used card with another).
3. double-click/enter a line at the list invokes rename/create
4. only disabled ports are gray (easier to look at - previously: also empty)
5. when creating a new card, enter (at the name selection box) is enough to
6. list now stretched properly with the page.
7. Automatic creation of mcd file when opening the manager and a card is enabled
but doesn't exist (easier to manage, would've been created on boot anyway).
8. as a result, now properly handles initial post-install/setup state.
9. auto eject/insert of mcd now displays at the console (also for loadstate, if
Really nice work :)
it'd nicer if I'm able to just load another memcard file without renaming or deleting the current configured one ;)
weimingzhi, yes, it will be nicer indeed. Soon :)

Revision 4434

Changing some default layout spacings for the memcard manager.
Prolly still not final :p

Revision 4435

MCD auto-eject (loadstate, mcd manager): Added maximum timeout.
- Before: The card was reinserted after it was accessed X times (X is 128).
- After: We add another timeout limit: if card was accessed at least Y times and
since then Z ms have elapsed, reinsert.
- Previous limit still stays.
Currently, X stays 128, Y is set to 2 times, and Z is set to 1800ms (if a game
polls the card once a sec, it will see it reinserted on the 5th access = 4s
after the initial access).
Y and Z might need some fine tunning and testing with more games.
erm.. Z is currently set to 2800ms. The rest of the text is correct.
Yep, works nicely alright :)
Suikoden 5 showed the missing memcard dialog 2 times, saw the memcard again at the 3rd attempt (21 polls only, lol).
The values are fine and don't need any tweaking.
See ICO, which has enough time to change its menu from missing card to card present state.

Revision 4436

Fix the timestretch "Reset Defaults" Button to actually work (Winodws. Linux
already works, I think.)

Revision 4437

Fix for Ratchet & Clank TLB Misses, turns out the whole hammering DMAs to see
when things finish are more cycle tight than i imagined, now we have no delay
for the last QW
On it.
Okay, this fixed the TLB misses in my Ratchet copy. :)
nice work :)
I own all 4 of the PS2 games so I'm happy to know that when I do eventually play them on PCSX2 they won't have whatever problem this caused B4.
But does it fix super robot wars?
Yes, I think it might have filtered a few more superdeformed robot pixels there!
@Rama: A Ratchet Copy? :P
Yeh Rachet copy, its called Ratshit and Clunk :P
Gabest: Where in hungry do you live again? *Sets up nuke*:P
And why is Ratchet & Clank s**t?
Could be Ref's personal hate game?
Though nope, that title would go to FFX for sure :D
Sorry, you seemed to miss understand me, Wagnard said A Ratchet copy, so i was making out it was a rip off with a similar name, rather than a direct "copy" :P Best stupid name i could come up with :(
And for the record, R&C rule!
ah, fair enough :)
Gabest:it doesn't fix SRT unfortunately,i am going to hang myself.
[email protected] "Just do it!"

Revision 4438

FF12 Ingame menu fix - MFIFO games generally compare VIF TADR to SPR MADR to
find out when it's finished, copying part packets from SPR can be a hazard in
this scenario, so we're making sure now that the whole packet has gone over
before MFIFO VIF/GIF resumes.
If this fixes the GPU bottleneck in the menu, its a great improvement!
Sorry to dissapoint you, it doesnt :P it fixes a hang recently introduced.
Hang/crash fixes always +1 =D

Revision 4439

*cough* you didn't see that
Voodoomonkeys? :p
Must have been!
good work :)
What has been seen cannot be unseen!

Revision 4440

GSdx: (almost) complete mipmapping support, if the min/mag filter differs then
bilinear is used.

Revision 4441

GSdx: forgot to remove something...

Revision 4442

GSdx: one more thing to remove...
Shadow of Colossus doesn't crash anymore on SW mode.
wait, there are still bugs :P
Looks great! :)
I think it still has some instability issues though.
- Switching between SW/HW modes (F9) can crash sometimes.
- Once, after playing for a while, it 'sort of' hanged in SW mode: system became 99% non-responsive - including the mouse cursor, was only able to kill the process after few minutes. Not sure if it's GSdx(SSE4.1)/driver(nvidia gtx260)/system(XP32/SP3/E8400) fault, however my system is quite stable otherwise, no OC, etc.
However, it does looks great. Thanks :)
Well, still a start nonetheless. =b
I got a similar hang one time on linux. It was a while loop on some triangle stuff. (do not remember exactly)
Something like that.
while (1)
if (top < bottom) (or the contrary :p)
go out.
At the hang top was -2*10^9. I will check tonigh if I can found the exact place.
It was on function DrawTriangleSection called by DrawTriangle.
hm, top is an integer
I think top kinda overflow and become negative before entering the loop (or memory corruption somewhere). Unfortunately it was not a debug build. It was on Mana khemia. Note my CPU is OC and all cores are loaded to 100% (boinc). So it could be an unrelated issue.
GDB Tip: you can attach/plug gdb to a running process. I do not know if it possible to do it on windows. Could be useful if Avih can reproduce it easily.
Hmmm... Not sure I'll be able to catch it (didn't try to reproduce, thankfully), and even if I do succeed, the system practically hanged. Not sure it'll work.. but if anyone got an idea how, I'm willing to try.
Hum, I will try to reproduce it. On linux it does not hang the system, either it is not the same bug or the scheduler is far better (fair). Probably the later because xp is very old.

Revision 4443

GSdx: commit, commit, commit, that happens if you code in assembly.

Revision 4444

GSdx: ... at 6am. (4444 get!)
+1 for the hardwork and late hours put in working on this :)
Lol...once he's on firah it's like commit frenzy.
Get some proper rest, dude. =b
congratulations on r4444 :P
Giving a positive here, it's a consolodated positive for the past few commits :P good job!
Update to a GPU plugin always gives a +1.
I dream about 2x in Software :)
this is a incredible! You don´t rest
you revisions is very greats
"GSDX: The return of gabest11" makes me happy...
Mipmapping in Ratchet and Clank is mostly accurate now. A few odd textures pop in and out a bit sudden yet but the general impression is much better :)
It's bit expensive in this game though, 18FPS with and 24FPS without mipmapping.
In other games that use the feature less, there's next to no speed difference.
Still, my Core i5 @3.5GHz with 4 rendering threads is not enough for Ratchet and Clank in Software mode...
I guess, mipmapping feature should be implemented in Hardware mode too... And some more game will be playable...
BTW, Software mode in Shadow of the Colossus has some pink/green artifacts on the water edges (e.g. on the temple balcony)... Some texture filtering glitch, I guess...
For me, its not great, always the same issues...I don't understand the +1 review score.
I don't understand why you haven't hanged yourself either.
lol this time he did a neutral one to not ban him? xD
suluh because its for see your stupid comment and they can't ban me but if you want,i can give a negative review <<
"suluh because its for see your stupid comment and they can't ban me"
dont speak so soon roo.
'Stupid comment'?
Wasn't it you who commented you're gonna hang yourself a few revisions back because it still didn't 'fix' your game?
ye i make a depression because my game is not yet fixed,its too hard.The devs are going to kill me.
make me a dev for just 1 sec please xD
Tales of Vesperia crash on battles now an weird text appear on the console, it seems that i'm unable to turn midmaps off, it will be useful to see the midmaps status somewhere and to have alternative to turn it off.
Not tales of vespertia, the crash was on Tales of legendia, sorry i got a lot of tales of games, so i mixed up the names.

Revision 4445

Stopped the TLB miss log spam in release builds. Freezing gui's aren't so nice
Better. Just :)

Revision 4446

FireWire: Improved Null emulation to help games like Silent Scope 2 and Unreal
Tournament (possibly Time Splitters 2) etc boot.
Games that never worked before now boot - this is the best kind of improvement, deserves +10.
Time Splitters 2 theoretically working sounds realy good :D
Unreal Tournament confirmed working . :)
Good job guys !!!
Good job working this out :)
fantastic work :)
nice fixes Rune Viking Warlord (also need to set gsdx to native or pcsx2 will crash)
Whoa, this is nice...
You can never know what games at least try to talk to the firewire hardware at some point.
Refraction made it so that some basic communication now works, which should make most games happy.

Revision 4447

Memory card manager: should be functionally complete. Feedback will be
Major new: insert-from/remove-to file system files.
New: context menu and buttons for the new functionality (including copy which
was only available via drag and drop).
Mod: slight text changes (finally should be ready for translations).
Mod: slight cleanup of functionality:
- 'Copy' changed to 'Duplicate', and can be invoked on any card, or via drag and
drop to an empty port.
- drag and drop of cards: from a port to the filesystem = eject card (not swap).
- drag and drop of cards: from the filesystem to a port = insert the card to the
While it's functionally complete (I hope), I'm not 100% happy with the GUI.
Better GUI would have been 2 separate lists (ps2 ports, unused cards) and cards
can be moved between the lists. However, creating another list control, laying
it out and handling the interactions between the two lists would have been a
headache (even more than it already was). The major case which is hampered by
the combined list is when the user has many cards on the filesystem, and he
wants to insert it to a port, but the ports are way up the list so a scroll is
required. This case is handled by the "Insert card" button which is available
for any card on the filesystem (prompts the user to select a target port).
Let me know what you think.
I probably need to remove some (most?) of the console messages...
Testing tomorrow.
Btw, if a user has 321 memory cards and can't move one from slot 123 to slot 1, he's doing it wrong :p
if it works fine, let it be and let's see 0.9.8 finally. ;)
a little food for thought, how about trying to implement the bigger cards that are 16, 32 and 64 MB. Would be useful for hardcore gamers that have 30+ games on 1 memory card with data like SOTETs Battle Trophies on the other.
gb2985: Has been in for ages. Check "create new card" ;)
what would be nice is an option to use the host-fs (folder on the pc) to store the individual save files, but with the work that would be involved to get it working (not to mention compatibility issues) makes it not so appealing :)
anyways good work so far gui is looking good.
good job :)
another minor thing: the space for the "Card: " string is too short... I translated it into something 8 English characters wide however only half of the string is shown there.
weimingzhi, This is interesting. There is no space reserved for "Card:", it's just layed out in a row together with the rest of the buttons, and should occupy exactly the amount of space required to contain the text (same goes for the buttons sizes BTW).
It shouldn't be the case, but maybe somehow with translations the text is replaces after the space was reserved for the original text. Anyway, I'll look into it. Thanks.
ramapcsx2: thx 4 pointing that out, I've only ever created the cards via the PS2 menu so I didn't know - should've looked more carefully really, sorry.
Something I'm finding annoying is that I can't select which Memory card goes to which slot, if it's already implemented then please tell me how, otherwise could you add that at some point?
I did not know that the memcard size can be increased. Very interesting!
Another idea will be to have different memcards by serial like savestates. I do not know if it possible.
gb2985: That's what happened in this commit :p
gregory: We could add that but it'd be easy to make user errors with that, so dunno :p
Also as a note, be careful with large memory cards, some games refuse to boot with them, generally those that came out in the early playstation 2 life when only 8mb cards existed.
No I mean like double clicking on a slot and then selecting from a list of available memory cards with the new card text box at top.something like this:
if the card don't exist then auto create it.
gb2985, I'm not quite sure I understand what you're saying:
- "Something I'm finding annoying is that I can't select which Memory card goes to which slot".
You can drag and drop any card into any port. Alternatively, you can click on an unused card and then click "Insert", which will let you choose what port you want it inserted into.
- "like double clicking on a slot and then selecting from a list of available memory cards".
Currently double clicking on a card will invoke the "rename card" dialog. Currently double clicking an empty slot will invoke the "create new card" dialog.
Your suggestion of double clicking a port to invoke a dialog called "choose a file that goes into this port" is interesting, but brings few questions:
1. Isn't it faster as it is right now to just drag and drop any card to the port you want?
2. Does your suggested dialog shows only unused cards? or all of the cards at this folder?
3. Should your suggested dialog include extra file info (size, formatted, created date, etc)?
If you think I didn't understand one of your comments, then please restate them as follows:
1. Currently when I'm doing <ABC> it does <XXX>.
2. I prefer that when I do <ABC> it does <YYY> instead of <XXX>.
3. I think my suggestion can improve the current state because <ZZZ>.
This way it would be easier to follow your suggestions, and you'll get better replies.
Rename: Can be made to behave like a file manager does (click wait a second then click again for quick rename).
a) I didn't know could drag from explorer into the MC Manager
b) That way does not prevent the same card being used for multiple slots
2: Unused cards only - upon selection put the name in the text-box. "Use" button checks if card is being used 1st before creating/selecting the card:
if (mc == MCNONE) { /* creation code */ }
if (mc == MCUSED) { alert("Already being used"); }
else { /* selection code */ } // mc: 0 = select, 1 = used (MCUSED), 2 = create & select (MCNONE)
3: If including File info then should be optional
4: Perhaps when there's nothing left could implement tree based with name format being something like "HEADING-H-NAME" where "-H-" would indicate children whilst remaining backward compatible.
You can't drag from explorer. You can drag only within the list itself. You see all the cards at the memory-cards-folder on that list. They're either assigned to a port, or appear at the bottom of the list under [-- Unused cards --].
Renaming like in explorer (one click to select, another click to rename) is not easy to do right now. So, maybe in the future, but not now.
I still don't see how is your suggestion (assuming I understood it correctly) is better than just dragging an unused card (at the list) to a port (at the list).
Can you describe a scenario where your suggestion is faster/better/more-robust than the current implementation? Also, please state why it's better (this is something I seem to miss so far).
Oh, seems I misunderstood how it worked, in that case the way it is fine.
This would be a case of me being a total idiot, then again would make the default dialogue load faster if it only had to load the names of cards being used (I can only see this being good for people who use a large number of memory cards though).
If you tried the new mcd manager and didn't understand what to do there or how it works, then maybe it's not intuitive enough, which possibly needs improvement. Any suggestions?
that's interesting I've always used the 32mb cards and never had any boot problems with games. but if that's the case maybe there should be a delay insert option so the game could boot up first before inserting the mc (I'm not sure that would get around the game actually reading the mc though)
I think the GUI is ok, I think alot of people forgot its there since its never been functional in the older pcsx2 versions :),
I was wondering if/what the hotkey is for swamping the mc when in-game, would be nice just to have to press (ie: Home to change mc port and Page Down / Page up to cycle through available memcards in game)
Well.. there's no technical issue with hotswapping stuff (savestate slots, mem cards, etc). Only issue is that it probably needs OSD to be really useful. Without OSD, you're pretty much in the dark with regards to the current state...
in pcsx2 most hotkeys only post to the console (for example when you press (F2) for savestate selection it says in the log), F3, F9 are more examples
> Selected savestate slot 1
then when loading (F3)
Loading savestate from slot 2...
filename: ...\sstates\SLUS-20804 (A9C82AB9).00.p2s
same thing could be done with the memcards, "
> Selected Memory Card slot 1
Inserted Memory Card into slot 1...
filename: ...\memcards\Mcd-Multitap1-Slot02.ps2
An OSD would be nice but it seems like alot more work involved but if it's implemented could use the osd for other things too like savestates, fps, memcards, gs settings, ..(sorta like dolphins OSD)
Yeah, we wish we had an OSD. Not many dx coders around though ;)
Regarding the memcard sizes:
Anything not 8MB might cause a few odd games to behave badly when trying to save to it.
(Currently I know of exactly one: Star Ocean 3 refuses to install battle trophy data on 64MB cards.)
I'm not quite sure with pcsx2 and gsdx but I don't think it would be too hard gabest would just need to add a var to put a string in the top left corner that pcsx2 could send some text to and a timer to erase/clear it.. I messed with a d3d9 proxy dll before that I had to modify so I could have my other program send text to the dll and that would display it over the game
(it was actually for japanese games, text would be translated and automatically added back into the game with the translated text)
but gsdx is alot more advanced ...or maybe no one asked gabest for an osd :)
I only misunderstood how it worked because I was an idiot and thought it was still the same as when I last tried it which was a few months ago, never realized more functionality had been packed in since then (as I said I was an idiot). Live an Learn :D
We'll get there with the OSD, I think it can be useful.
gb2985, well.. s**t happens. No worries ;)

Revision 4448

FireWire: Probably should increase the version number too

Revision 4449

GSdx: the TEX1.LCM == 1 mode was still unfinished, the field in PES 2011 for
Street Fighter EX3 didn't like this, it's pretty much flickery and some bad textures in 3D now. was fine in r4444
Is that in hardware and software modes? Or just in software?
Could you post a screenshot of before and after? :)
Uh... only software and only using mipmap toggle of course :p
r4449 and r4444 with mipmap (looking fine), without it looks fine:
Lol so the stripe effect has transferred from pest to sf3ex :p

Revision 4450

MCD manager:
1. A card at a can be dragged from a port and dropped at any empty area of the
list to eject it (previously: only to an existing list line).
2. "Card:" label should fit to text size also on translation (possibly a
wxWidgets bug, seem to be bypassed now).
TODO: remove the many console messages when it's considered stable.

Revision 4451

- Toggling mipmapping prints a message to console now. Easier to test this way
Btw Gabest:
The whole keyblock isn't used by anything in PCSX2, I believe.
So you could use Del, Home, End, PgUp and PgDn still ;)
Ah, finally. =b
The broken bush textures plague hardware rendering as well.
Only mipmap support can fix that ;)
Mipmaps also fixed a ton of textures in the Tomb Raider games:
Check the pictures on the wall, very disturbing in motion :p
That shadow looks a bit wrong there.

Revision 4452

Forced MTGS to obey the max queued frames limit even when the frame limiter is
Fixes games becoming unresponsive to input commands in software rendering.

Revision 4453

MCD manager: remove port-status and related button/context-menu.
- Following rama's suggestion, and because cards can now be easily
ejected/inserted, there's no more need for enabling/disabling the port. It also
makes it easier to use (less configuration), and resembles the real PS2
counterpart more closely (a card can either be used or not used and that's it).
- For consistency, the MCD manager now automatically ejects cards which are
"disabled" (Note: multitap cards can still be internally enabled when MT is
disabled, but they not used because MT is disabled).

Revision 4454

GSdx: I've mixed up the bits of TEX1.MMIN, sfex looks nice again.
I can still see a few problems, why is it so hard :P
It's never easy :p
Now this is interesting, RGBAQ is called with Q = 0.0f, and later this selects the wrong texture level. The lod formula is log2(1/Q) << L + K, or -log2(Q) << L + K to not divide by zero. So it's basically infinite << L + K, which means the smallest mip texture, however the one needs to be used in this case is level 0, I can see that the rest is just memory garbage.
gsuser 3.4.4:
MIPMAP (LOD Value Specification) + Texel Coordinate System: Possible (Fixed value in each primitive)
MIPMAP (Q Linear Interpolation) + Texel Coordinate System: Impossible
gsuser 7.1 / RGBAQ: The Q value is not only used for calculating texture coordinates but also as the parameter to decide the LOD
Sooo, I should forget about interpolating Q when FST == 1, but still don't know how to get a meaningful LOD for each primitive. A triangle has three vertices, each its own Q, if interpolation isn't done, which one to use? And what if all of them are 0? :P
FST && !LCM might be an illegal combination and this game is wrong by passing zero Q. That's the only solution I can think of.
shouldn't matter about vertices positions
3 vertices the same would mean the triangle/s are drawn but not seen
2 vertices the same would mean a line is seen instead
end of the day it's the games problem if it can't pass triangles that will be seen
I think "fixed value" actually means TEX1.L and TEX1.K and not Q. If FST is set I also set LCM and that just works. Ratchet and Clank used this strange setup for the menu, it also needed proper LOD rounding in a few places, like Q = 0.8 should select level 1, because level 0 is mostly unintalized, simply not uploaded to the GS.
I meant "LOD = 0.8" there.

Revision 4455

GSdx: please test mipmapping again...
Well, my Tales of Legendia it still crashing on battles with the weird log messages, i hope you find some time to look what it is, it started to fail after r4419 so i guess it the midmapping but it fails even when its off, so i can't be sure.
(same error with hacks / no hacks)
r4407 works fine (few glitches)
maybe i'll just post an issue and wait, because i don't want to be annoying roo clone and i certainly dont want to be banned jeje.
as i said r4407 works so it's not like i'm unable to play the game.
Keep on the good work.
jsnorie, did you try recent pcsx2.exe with gsdx 4407? also worth trying the other way around. Since both pcsx2 and gsdx have changed recently in a way which affects compatibility, you should isolate your tests.
If you already did that and verified that this is a gsdx only issue, then fine.
I also saw this error message once recently, but couldn't reproduce it. Tried looking for it at the code but didn't get too far. FWIW, my impression was also that it was a gsdx issue, but it's still just a hunch.
I can confirm issues with Tales of Legendia, i tested gsdx r4407 with new pcsx2 (r4455) and it works fine), when using the recent gsdx it will cause the game to crash in battle with that weird console msg (so its most likely a gs related issue), also this game only works in software mode so that makes sense with all the changes done to software mode lately....
Really this game always had horrible issues with gsdx and you need to use a older highly modified gsdx to get it to even work in hardware mode without it killing your pc.
I'd like to make a suggestion about the thread box in gsdx.
Since PCSX2 detects the number of cores GSDX should auto limit the number of threads to 1 less then the number of cores. Prevents idiots like me accidentally slowing down PCSX2 and only realizing days later the cause was the number of threads being too high.
That used to be true in the past, when gsdx run wild without using events, but now if pcsx2 does not use 100% of its own thread then it may leave some to the second thread of gsdx.
Legendia overallocates the texture cache, just ran it, can't say more yet.
I have an AMD Quad Core and I still managed to slow down FF12 by setting the number of threads to 4 instead of 3 (went from 45+ on average to 20+ average)
GSDX works best with 2-3 threads (me and gabest had this conversation previously :P) however you only have 4 cores, so you are letting gsdx take over the pcsx2 thread, so the emulator will slow down, this isnt a bug.
So AMD 6-cores are best choice for software mode?
If you want "best", an intel chip would be best as it can take advantage of SSSE3 and SSE4, both of which are used in optimizations in the emulator and gsdx
Intel has a 6 core, too :P
Wiki lists 8 and 10 core xeons in 2011 Q2, can't wait for those to come down to mainstream cpus.
That will be a beast :D
Since a few revs a blending effect in Breath of Fire 5 looks wrong.
I can provide dumps if needed :)
Oh, and it's wrong even with mipmaps disabled. It doesn't affect it (maybe SSE 4 only again..).
avi and konaj i've been testing TOL with different combinations of pcsx2/gsdx(sw mode DX9, DX11, SDL), with same results gsdx r4407 and below worked fine, r4419+ got battle slowdowns and r4444+ got battle crashes.
gabest11, just for curiosity, is it possible a "disable fog" hack? some games get fps slowdowns in areas with lots of fog. I just saw that hack in another emulator, but it seems that ps2 can be veeeery tricky.
Yep, something with fog or smoke from a fire, even in mostly 2D sprites game like AT2, can bring down SW mode to its knees.
It's usually 50~60fps, even in battles.
But once there are smokes, even on cutscenes, the GS shot up to 100% and fps went down to 40~45 fps.
Caveat emptor : it's being run on an i5-520M (2.4GHz TB-ed to ~2.8GHz; 3 threads for GSdx).
How to Enable/Disable mipmapping please?
'Insert' key.
I tried Insert already but no changes in graphics and no messages in console window too.
I'm using Dx10 Software mode, and SSE2 dll.
Does it work in some specific games only?
[email protected]: TOL does something awful that even the sw renderer cannot handle well, tiny chunks of the screen are addressed as 1024x1024 textures, but every time only the top left part is used. It iterates through the whole screen and eventually gsdx cannot allocate enough memory. On the real hardware texture pages are fetched into the cache only when needed, with real page fault handlers trapping the reads, that would be too slow for us.
@[email protected] : The effect is only visible on some games, and unless you're using a revision prior to 4451, the messages should be in the console window; I just compiled this rev and the mipmapping messages are there.
I'm using r4463 and the message do not appear, any ideas?
I just compiled that rev with both VS2008 and VS2010 under a clean build, and the message still shows.
The message shows only when you already have a game loaded, and mipmapping works only in SW mode.
The message appears in ALL the games? or message appears only if the game have mipmap support?
I deleted gsdx.ini file.. and I changed controller plugin to SSSPSX and it worked.. I then changed controller plugin to LilyPad again and it still works.
Thank you.
Only Insert key in the keypad area works.
Yes, it should appear in all games.
In any case, didn't realize it has to be the one in the keypad set, because I tested it on a laptop. =b
I didn't have to delete any .ini files or switching controller plugins to get it to work, though.
Holy sh#t !!))
Gabest !!)) Your recent work on mipmapping has fixed ground textures garbage problems in Ace Combat 4 & 5 games !!!)) So the problem was unimplemented mipmapping before ))
Thank you VERY much, our GFX Lord !!!))
P.S. - will it ever work in HW mode ?)))
Wow, then it may have even fixed super robot wars :D
Big Mutha Truckers has some pattern in the road and the environment flickers and even dissapears at times with mipmapping.
SRT isn't fixed <<
shadowladyngemu: I don't have that game and cannot find it anywhere :(
I can upload a dump or GSdump somewhere if you want :P
Ford Mustang Racing is also broken with mipmapping, it does like the opposite and breaks the trees and the road a little and stuff :p
The details of automatic mipmap address calculation isn't explained in gsuser, it seems that when the texture is non-rectangular the height is extended to make it square and only after that follows the next level in the gs memory. This may break other games, but let's hope it is the correct way to do it.

Revision 4456

Fix a crash when creating memory cards in Linux. Change the warnings when
compiling GSdx in Linux to be a little less annoying.
Ouch... thanks :)
np. At least the reason why it was crashing turned out to be pretty straightforward.
Though when it was telling me about my new, unformatted memory card, I did find myself wishing for a format button. :)
Agreed :)
If someone has docs about how to format a memory card, I might take it. However, since games know how to format cards anyway, I'd say it not critical ;)

Revision 4457

GSdx: sse2 code path still had a little mipmapping bug, tales of legendia does
not crash anymore, added a hack for suikoden tactics
Mipmapping has improved a bit in the last rev, forgot to mention that.
And also:
Since a few revs a blending effect in Breath of Fire 5 looks wrong.
I can provide dumps if needed :)
Suikoden Tactics is hackfixed successfully.
I forgot about that, but at the beginning of the game it appeared correctly.
This is right in the beginning :p
Which build and renderer do you use?
I get it with SSE2 and SSE4 builds, renderer is software (DX10).
In hardware it's fine as it always was :)
(I can't see your pics, google docs says "Page not Available".)
What does minimaping do?
It was set to this access level:
"Anyone with the link
Anyone who has the link can access. No sign-in required."
Changed it to "Public", now it works from a different computer, too.
Software or hardware, it looks the same here, could be some avx code again?
[email protected]: Pixels being further are sampled from a pre-generated lower resolution texture, tri-linear blends the two adjacent texture levels for a smooth transition between them. First pic google finds: http://www.shinvision.com/wp-content/uploads/2009/06/mipmapping-egz.png
Gabest, will there be mipmapping in Hardware mode anytime soon?.. Is it a hard task to do right now?..
Definitely looks right for you. Tried to compile for SSE4 yet? :p
Yea, tried SSE2 and SSE4. I'm going to try it on my notebook, that only has SSE4.
eliotfur: Need to bind all 7 textures and modify the pixel shader to select the right one according to the LOD. I'm not sure if textures can be organized into an array for indexed access, else it would be quite painful to do.
Pseudonym spoke of a redesigned texture cache using something called "texture sheets". Would that work for smth? :p
Save states tricked me, it's bad if I play from the start.
more hack code (note: from my test the FFX one is not necessary and causing problems):
the original website with these code are distributing GPL-violating hacked builds (and ripped off my submitted translation before the translations go to public beta!) so I'm not going to post it.

Revision 4458

MCD manager: should be final.
1. Restored multitap 1/2 checkboxes to the main menu.
2. Console messages now appear only on apply and only for active cards.
3. Shorter confirmation message for "duplicate card".

Revision 4459

GSdx: BoF DQ fixed
I get these 2 errors in VS2008 when trying to compile this revision:
GPUDrawScanlineCodeGenerator.obj : error LNK2001: unresolved external symbol ___xgetbv
PCSX2\bin\plugins\GSdx-SSE4.dll : fatal error LNK1120: 1 unresolved externals
Update your VS2008 to SP1.
I also had the same problem with previous revs with VS2008, but installing its SP1 fixed it.
Fix confirmed working :)
still no fix for roo :(
Any kind of fix for him is the mental institute.
I got one of these hangs again, in HW rendering mode (didn't switch to SW at all). I don't think it's related to your recent work but it did happen with latest gsdx.
After this hang (probably around 30s where the system was 100% non-responsive), there was a screen refresh, and then another similar 10s hang, and then it resumed.
After it resumed, I got some trash textures. I changed something at the plugin settings (alpha correction from on to off or vice versa), and then the textures got good again and everything else was normal.
Game is Pinball hall of fame: Williams collection (SLUS 215.89).
Image of trash textures: http://i52.tinypic.com/2z7fmtl.jpg
Also at the issue of trash textures (but without hangs that I noticed), it does happen in few other games. E.g. Tomb raider legends (image 1: http://i55.tinypic.com/2ibhl3n.jpg , image 2: http://i54.tinypic.com/13zzazk.jpg ). At this game other than the overlay trash texture (which changes completely with every frame of moving the camera) the rest of the underlying 3d seem to be 100% OK. Also, Metal gear solid 3 also has an issue of trash textures on some stages, but most noticably at some of the water scenes.
Don't know if these issues are related (they do seem related to me though), but just thought of uploading some screenshots for the record, maybe u can do something about it.
Holy sh#t !!))
Gabest !!)) Your recent work on mipmapping has fixed ground textures garbage problems in Ace Combat 4 & 5 games !!!)) So the problem was unimplemented mipmapping before ))
Thank you VERY much, our GFX Lord !!!))
P.S. - will it ever work in HW mode ?)))

Revision 4460

MCD manager: enable the "create new card" button/context menu also when no item
is selected and for the [-- Unused cards --] item.
Awesome, thanks for adding this promptly :p
WOW! Very good! Thanks for this=D

Revision 4461

Save-state: 1. Added load from backup. 2. Removed save/load "Other..." (not
connected to anything anyway)

Revision 4462

Save-state: gracefully handle state load/save when the VM isn't at a valid state
(was crashing on load state before running anything if a bios savestate existed)

Revision 4463

Patch by pseudonim: Disable the state load/save menus when no active VM.

Revision 4464

Save-state: Shift-F3 now loads the backup save (if exists)
Thanks a lot!

Revision 4465

* update the i18n pot script to also compile locale
* Upload some languages, then update everythings
Translator note: I plan to updload translation every 2/3 weeks. It does not
worth it for very few string changes. Tell me if you prefer more frequent update
every 2 weeks is fine.
any time is fine for me ;)
btw, maybe someone should tell the guys from Emucr to update the translation files (they still package the old files from 0.9.6) - I don't know how to add comments there :(
every 2/3 weeks sounds reasonable to be. Thanks and good work!

Revision 4466

Committing changes to the MSVC 2010 build system as posted in issue #977 .
Thanks for this nice patch, debian.micove :)
Yep, this makes ZZOgl compiles nicely in VS2010.
There is 1 other suggestion thing that I forgot to mention. ZZOgl needs cg.dll and cgGL.dll or PCSX2 complains. I always forget to copy them from the Virtual Machine when I'm done and notice when the "ZZOgl invalid plugin" messages spam me hehe but since I really don't use the plugin in Windows it does not affect me that much.
Adding a PostBuild event (ensures version used at runtime and build time match) to copy cg.dll and cgGL.dll from:
$(CG_BIN_PATH) for Win32
$(CG_BIN64_PATH) for x64
to the $(OUTDIR) directory if those file are newer would be nice.
Adding those DLL to the svn binary directory, svn 3rdparty directory or making the user get those files themselves (like now) are also some possible alternatives but they do not guarantee that the build time and runtime versions match.
the cg files are part of the nvidia pack, im unsure on the distribution rules for that, so it's best just to get that from nvidia's site.
Yeah the license section 2.1.1 file says:
2.1.1 Rights. Customer may use, reproduce, distribute, publicly display
and publicly perform the SOFTWARE.
Since the files will not be modified or rented and just distributed it should be fine. Nvidia reps have clarified this before for a similar clause included in their video drivers.

Revision 4467

MCD manager: console print fix when creating a card without assigning it to a

Revision 4468

Adding avih to the list of coders and a special mention for Jake :p
...not 'avihal'? =b
nahh, gmail doesn't allow 4 chars names.. so.. that's the next minimum ;)
Thanks rama :)
lol...'grats on your 'borgification' to the PCSX2 team then...and Jake too...
Still No Shadowlady in beta testers list?

Revision 4469

Minor change:
Removed unused items from the menus (patches and some debug items). Those will
be implemented later.

Revision 4470

Various console log changes. Made it a bit more colorful, too :)
I've begun to make Hungarian translation of PCSX2.
I've translated some strings and I've wanted to check them how to display in the emulator. I've got these error messages:
Loading language translation databases for 'Hungarian' [hu_HU]
pcsx2_Main not found -- translation dictionary may be incomplete.
pcsx2_Iconized not found -- translation dictionary may be incomplete.
pcsx2_Tertiary not found -- translation dictionary may be incomplete.
SetLanguage: Requested translation is not implemented yet.
Depends if you use linux or windows ;)
For windows:
1/ copy pot template to po (pcsx2_Main.pot -> pcsx2_Main.po)
2/ translate them with poedit. Normally poedit automatically compile them into .mo files.
3/ Copy the .mo files into bin/Langs/hu_HU/
By the way look at the wiki there is lots of informations

Revision 4471

[wiki] some compilation note for fedora users + how to install translation

Revision 4472

i18n: Add new fallback for language
swedish fi -> swedish
portuguese -> brazilian portuguese
"sv_FI" fallbacks to "sv_SE".
Tested and working.
Thank you.

Revision 4473

GameDB: Updates...
What games were changed? google code doesn't show diff because the file is too big..
You can take a look using the "Show log" command of tsvn.
It's pretty intuitive to use :)
I presume i need to use Access to edit this? I tried using open office, but it made a hash of it when it saved lol. Reason i say this, Age of Empires 2 still needs a patch which isnt in there, so i wanted to add it.
You best edit the locally checked out file with a good text editor, then hit commit.
refraction the database file is just a text file using a custom syntax similar to ini files.

Revision 4474

Created branch for stable release 0.9.8
Thanks for taking care of this :)
Btw people:
This doesn't mean a release is getting closer (or does it)!
whin this version will be ready for action
Ill take a wild guess and say when its ready and deemed stable.

Revision 4475

Removed the mVU "MinMax" speedhack. It wasn't very useful and broke a few games.
Did it break every game/ was it never useful? Otherwise I don't see why it should be removed.
Colin it broke a lot of games and was a mild speedup. In general the ratio of games broken to speedup % was too high, so we decided its just better to remove it.
I mean, if the devs think so I won't argue. I just personally can't understand removing a feature that could be helpful in certain cases.
KISS principle, look it up ;)
I think if it was useful at all, regardless of how many games it broke, it should be kept.
Because it could be set for use on those specific games that have no issue with it.
A per game ini/cmd line setup type of deal, the user would be responsible for that...
I think you might as well keep it if it indeed provide any sort of speed up on any game.
KISS doesn't really apply. If this isn't interfering with anything it's not overcomplicating anything. However, it absolutely does have a use in some very specific circumstances. Removing it serves no purpose other than a useless commit.
If keeping it simple is the best reason you can come up with I've gotta put this one on negative. I just have no idea what benefits you could see from removing this.
Just as a curiosity, what games that benefit from this hack without it being broken?
Useless and harmful hack.
Team decides it needs to go, so it goes.
End of story :)
It's not like I'm going to put it back in and make another commit lol I'm just saying the team should focus on something useful.
Hardly see how you have a say on what is useful and what's not. Disabling a speed hack didn't take much effort for them I assure you ;)
Try checking out the official forums sometime and take note of all the people who report broken games with all of their speed hacks turned on. It takes effort to sort through those as well so simplifying that also allows the devs to focus more on the actual problems/features.
Who says I have a say? My point is that instead of removing features because they usually aren't helpful is a waste of time. Did it take a long time? No. But why bother? There was a warning next to it telling people it did damage... completely silly to remove the feature.
Only the option was removed, the hack itself is just disabled. You could compile with the hack enabled, or make it an ini option if you sooo want to use it.
@Colin :
It's also completely silly to mull over something that has unnoticeable speed-up but often breaks emulation.
That's why I asked if there are any games that benefits (noticeably) from that hack without breaking.
Had you brought with yourself a list of those games then you might've had a decent argument.
I don't play pcsx2 anymore. My argument is that removing features that may be helpful is not how a project, any project, should be handled.
If I can enable it via .ini that would be good. But then why remove it at all? Simply putting "This breaks most games" should have sufficed.

Revision 4476

Changed the gamefixes panel text to include a note about being automatically
applied by default.

Revision 4477

1. presets: mVU flag hack moved from preset #3 to preset #2 (preset #3 now only
changes ee cycle rate to 1 click).
2. Selecting ISO from the list when current source is plugin: menu now updates
properly (previously: would stay at plugin).

Revision 4478

Renamed "Enable Patches" into "Automatic Gamefixes" to make it very clear what
the option does.
Good :)
nice, sure does fit :)

Revision 4479

Testing svn merge by bringing the new branch up to date (hopefully).

Revision 4480

First round of installer fixes.

Revision 4481

Whops :p
I was half-expecting it to be under a questionable folder name. =b
The pcsx2_Iconized.pot template doesn't contain the translatable strings. If I could get the English text I can paste the lines but getting an English pcsx2_Iconized.po file could make my work easier.
Please, help me where I can find the English strings for pcsx2_Iconized.
@kispis, you need to read the code, you have the file and line number. I'm not sure but I think poedit can automatically lookup it for you (not sure but try to look some context option)

Revision 4482

Fallbacks for all WX-listed German locales.

Revision 4483

Changed plugin API back to system locale for paths since only two plugins
(lilypad and spu2-x) were specifically expecting UTF-8 and handling it correctly
and breaking them is easier than fixing all the others for now.
What a nightmare :p

Revision 4484

Missed some SPU2-X and all zzogl code in the last commit.
Fixed assumption that all paths received from pcsx2 end in the path separator.
Hum, linux side must probably be fixed too ! I will try to do it tonight.
I think there's no "linux side" this time, the code should just all more or less work. And how many linux users have anything but ASCII in their home dir's name, really?
For the ascii/utf8, I do not know.
It was more on the change string -> wxstring (zzogl). I'm not sure Linux/Conf.cpp is correct. Besides I'm affraid that it will create some inizzogl-pg.ini file instead of ini/zzogl-pg.ini
Ah, it's probably not correct. I forgot about source files that are
in the VS project.
Aren't even.

Revision 4485

1. Portable mode: Fixed (for real!).
2. Game database: now always loads from pcsx2 folder (was using cwd)
Portable mode: folders and file names at the ini now always saved relative in
portable mode -> pcsx2 folder can be moved around, renamed, etc, and everything
keeps running as normal.
Note: last elf/iso folder paths are kept absolute at the ini, and so are the
last/recent iso file names. This is to allow moving pcsx2 folder around without
needing to select them again. The case of putting the ISO files inside the pcsx2
folder and expecting it to work when moving the folder around is still not
solved for now (but the iso can always be selected manually). Maybe will get
fixed soon.
Reminder: to run in portable mode, create an empty file named "portable.ini" at
the pcsx2.exe folder.
small note: this works for a new ini file but still doesn't convert properly from normal install to portable mode (the folders stay absolute). This will also work soon.
to fix portable iso mode why not just create a global variable at startup such as %PCSX2% which can be deleted upon exiting (in the case of process killing it will be overwritten at next start up). Then use that variable to detect a portable address.

Revision 4486

Remove a compiled library which somehow got committed.

Revision 4487

And another

Revision 4488

Fixed inconsistent newlines / added as many svn:eol-style=native properties as I
could without killing myself.
Please set up auto-props in your svn client.

Revision 4489

Portable mode: standard install can now be converted to portable.
Note: All files outside of pcsx2.exe folder (e.g. snapshots, memcards, bios,
saved states, etc at "my documents" folder) are NOT copied automatically to the
pcsx2 relative folders. So, if converting from standard install to portable and
you want to keep those files, you have to copy them manually.
Bottom line: if portable mode is preferred/required, it's best to start in
portable. This way no files are ever written outside of pcsx2.exe main folder
(at least, that's how it should work).
Also, worth noting that the pcsx2 path can now contain non-English characters (following pseudonym's recent changes). However, only new pcsx2.exe with new plugins support it.
(Old pcsx2 with new plugins, or new pcsx2 with old plugins will only work at paths which contain only English characters).
Well done! This should keep a lot of people (me included) happy :)
However i was hoping for a method of having the choice on the first time run wizard.
yeah, having the choice at the first run wizard would be the best way to go, even though great work and +1 for the effort.
Nice. I kinda missed having everything inside the pcsx2 folder :D
FWIW, I think that a portable mode should be done via a zip file (which includes the portable.ini file), and a normal install via an installer. People who need portable mode should be able to use the zip.
If we want an proper "installer" for portable mode, we might as well use something like the framework of portableapps.com .
The change from current installer to a portable installer might be quite big to handle. And it's much more than just creating the portable.ini file. We need to make sure it's installed at a place which "supports" portable install (e.g. not at "program files"). we need to handle shortcuts, menus, etc. It's not as simple as it might seem.

Revision 4490

linux compilation fix

Revision 4491

Recent Iso list: 1. Iso that don't exist are grayed out at the menu. 2. in
portable mode, Iso files are saved as relative if they're inside pcsx2 folder,
or in parallel to it.
"in parallel to it" means inside a parallel folder to pcsx2's folder.
nice one, i was thinking maybe it would be useful to have the ability to clear the recent iso list as well no?
chuuey, for now, you can just delete them at inis/pcsx2_ui.ini file ;)
ah yeah ;) thanks :)
Avih for information, you cannot use directly wxFileName in argument of ini entry when it is expect a wxFileName reference. Do not ask me why ;) but gcc is not happy.
RecentIsoList.cpp:227:108: error: no matching function for call to ‘IniInterface::Entry(FastFormatUnicode&, wxFileName, wxFileName, bool)’
IniInterface.h:54:15: note: virtual void IniInterface::Entry(const wxString&, wxFileName&, wxFileName, bool)
Note I *fixed* it in r4492

Revision 4492

linux compilation fix
grrrr... keep doing those. Maybe one day I'll be able to expect gcc errors.. or not.
Thanks anyway.
Ok, I understand why. The prototype for the file name is wxFileName& value (not const). It's not const because it's a derived class for both saving and loading data, and on the loading sub class it changes the variable, although on the save class (our case) it doesn't but still cannot be const due to the parent class.
So, anonymous varialble is not an l-value, so cannot be passed as non-const.
MS compiler probably recognizes that implicitly it's a const (no code changes it for that call), so it doesn't error. Nice optimization.

Revision 4493

* realign debian package with latest change of the trunk (mostly translations)
* hardcode 0.9.8 in the create tarball script
on the official page there is no official 0.9.7 and here they think about a 0.9.8
0.9.7 was a secret release :p
Actually, 0.9.7 is the name of the beta toward the real release 0.9.8. So there are official 0.9.7 but there are all beta
what do you want to archieve for the 0.9.8 to be official and finished? without bugs

Revision 4494

GSdx: only minor changes
Btw, there was one triangle vertex wrongly indexed before (1 << j should have been j << 1), I'm still wondering why it didn't make any visible graphics errors.
You fixed DX11 software rendering mode for 'Champions Return to Arms' :)
And by fixed i mean that the log window of pcsx2 has tons of "[email protected]#$"
entries, but it does not crash anymore after the 2nd one :P
PS: it might also have been fixed with r4498, im not sure
Well, it only doesn't crash anymore. It's still very wrong emulation somewhere, in hw and sw alike.

Revision 4495

GSdx: I always forgot to comment this out
I can't for the life of me get any of these gsdx revisions to show up in the plugin selection screen. Last one that worked was 4288 (SSE4).
jfre1, you probably need SDL.dll in your PCSX2 directory.
Ah there we go, that did the job. Thankyou :).

Revision 4496

First time wizard (both portable and install modes):
1. Create inis and bios folder before then can be accessed (e.g. configure
plugins, open the bios folder via "open in explorer").
2. Small fix for the "open in explorer" error dialog if a folder doesn't exist
(path text was sometimes cut off)
3. Default base directory (AppRoot() - used for plugins/themes/langs) is now the
pcsx2.exe folder and not CWD (probably only affects developers, but still
I love you xD
Hmm.. so listen.. what do you do tonight? :P
Is that a proposition? <3 :P
Just teasing. Tonight's occupied already :P
aww man :(
You might want to check if 3. works with commandline stuff ;)

Revision 4497

GSdx: Added CRC hackfix for Tenchu games and Sly Cooper 2/3. Changed Sonic
Unleashed's hack so it works for all stages (at least all the ones I tried :p)
and added the PAL version to it.
GameDB: Updates...
The hackfix for Sly 2/3 has problems but still much better than it used to be for hardware rendering.
Still need CRCs for tenchu games if anyone has some not incuded, notably the Tenchu PAL ones.
Is there any way to properly implement CRC hackfix for Shadow of the Colossus?.. I'm tired to recompile, update and send my modded plugin to a lot of people...
The main idea is to break execution of the GifREG FRAME only(!!!) in the exact place if TEX0.TBP0==0x3fc0
I don't know how to implement it through CRC hackfixes... That's how I did that in GSState.cpp:
template<int i> void GSState::GIFRegHandlerFRAME(const GIFReg* r)
if(PRIM->CTXT == i && r->FRAME != m_env.CTXT[i].FRAME)
if((m_env.CTXT[i].FRAME.u32[0] ^ r->FRAME.u32[0]) & 0x3f3f01ff) // FBP FBW PSM
m_env.CTXT[i].offset.fb = m_mem.GetOffset(r->FRAME.Block(), r->FRAME.FBW, r->FRAME.PSM);
m_env.CTXT[i].offset.zb = m_mem.GetOffset(m_env.CTXT[i].ZBUF.Block(), r->FRAME.FBW, m_env.CTXT[i].ZBUF.PSM);
m_env.CTXT[i].offset.fzb = m_mem.GetPixelOffset4(r->FRAME, m_env.CTXT[i].ZBUF);
if (m_context->TEX0.TBP0==0x3fc0) { //0x3fc0 disables SotC overbrightening
m_env.CTXT[i].FRAME = (GSVector4i)r->FRAME;
m_env.CTXT[i].FRAME.FBMSK = GSVector4i::store(GSVector4i::load((int)m_env.CTXT[i].FRAME.FBMSK).eq8(GSVector4i::xffffffff()));
CRC of Traditional Chinese version of Tenchu: Fatal Shadows:

Revision 4498

GSdx: Replaced a few divs with something more obscure in DrawTriangle, it shares
necessary calculations with the triangle setup for tile based rasterization
(http://drdobbs.com/article/print?articleId=217200602). AVX already has half the
floating point capacity of larrabee, but I'm still thinking how to do this
efficiently. We could take advantage of the block organized GS memory at last.
Thanks for yourwork gabest the recents revs you added gave bleach blade battler 2 a little boost.
Btw do you know why this game seems to kill the GS so much in hardware mode? because this game run better on software mode :/
Too many texture uploads or state changes usually. D3D likes big batches of triangles all having the same attributes, but it isn't always the case for ps2 games.
I suppose this game draws just tons of dots around the geometry to create that cell shade effect. Other cell shade like games do the same thing and are also slow.
So, I don't know in which commit it happened, since I only compiled recent ones, but there seems to be a bug (GPU or MainFrame) that happens when you suspend a game, then change some settings (sometimes any, but more when you change the GsDx renderer) that prevents the GPU window to reopen.
Simply suspend emulation mess with the GPU renderer settings, apply, then resume the emulation and the emulator resumes the game with the sounds being played and the game works normally, but without the Gsdx window.
I cannot pinpoint the revision when it exactly happened, unfortunately. :(
PS: +1 for GPU improvements
Try this, suspend, config, resume, suspend, resume. On the second resume the window appears! GSopen is called after closing the config dialog, but not when you click resume the first time, it sees that the plugin is already open and skips showing the window.
Thanks for the idea. Works fine. :)
Thanks for the explanation gabest.

Revision 4499

Minor fix for managed Vsync.