PCSX2 Documentation/Google Code svn repository comments archive 1500 to 1999

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 1500

Shit I'm commit-spamming again. >_<
Fixed a "omgf"-class bug, which just happened to work while using ISOs because
of a shared variable which wasn't meant to be shared.
And more cleanups.
i'm spamming in the rev 1500 which happens to be spam? how ironic
no ironic would be if giga's commit note was about spamming and that nobody should ever do something as cruel as such and there you spamm that would be ironic...
i win then :P
i'm joking please don't ban me :c
ironic would be getting a warning with spam bacause of spamming
no that's called "Cause and Action" ^^
Irony is the outcome of an event being opposite to and in satire of the expected outcome.
The irony is nobody seems to know the true meaning of irony, but keep using it :P
true Oo
refraction said it all, or did he?

Revision 1501

Fixed the crashing with blockdumps. It was the "iso file format" lib I took from
So I axed the compressed iso (Z/BZ2) format reading, as part of fixing it.
Anyone needing it can still use CDVDiso.
Forgot to say, blockdump setting is actually saved. just wasnt' showing up in the menu after displaying the window!
Good call. Anything else than LZO is stupid anyways because it easily makes the cpu the bottleneck for little gain in compression.

Revision 1502

Bugfixed thread affinity restoration during CpuSpeed detection; pcsx2 should use
all your cores properly again. :)
sounds like pcsx2 should have been a bit slower on previous revs... Oo *testing*
compiling this rev makes VC++ 2008 say
"4>Projekt : error PRJ0002 : Fehler "31" wurde von "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe" zurückgegeben.
That's the manifest generator, and the error means it's probably crashing due to some corrupted database or object file information. A full rebuild should resolve it.
... or there is something that reads the exe as soon as it is linked but before the manifest file is appended, it happens to me a lot when aqtime reloads the profiled module.
Just wondering, anybody was able to profile PCSX2 (Release build) under
AQtime?? I only succeeded profiling it with the debug build with all
recompilers off -_-
Properly do you say:
Can't get it, still one core kept going 100% while running BIOS on pcsx2-r1550.

Revision 1503

Fixed Linux again. Still don't have time to actually implement adding the new
features yet in Linux. (Likely won't till next week or later)

Revision 1504

Minor code conformity cleanups and svn properties settings for new cdvd code.
on the wx side of things I'll remove all the win32 specific code and end up converting most or all of the filename code to wxString, wxFileName, and wx's built in directory contents enumerators.

Revision 1505

wxgui: Added plugin selection dialog (complete with plugin enumeration and an
exceedingly fancy progress bar), fixed some menus, added isofile recent lists,
and lots more stuff is correctly saved and loaded from the configuration file.
* Dev note: Re-enabled USE_STL in wxWidgets since that's required to ensure
thread safety.
Beh, just noticed I accidentally added Linux/HostGui.cpp, which isn't needed. I'll remove it later on my next commit, whenever that is. ;)
Further info, since this branch is very nearly to the point where it'll be usable:
The Settings dialog box is now correctly bound to the Config->Settings menu. Go to the Plugins panel to see some fanciness. The branch should build and run fine under Windows and in Debug build target. Linux is broken at the moment, and I haven't tested devel or release targets lately.
Ok, just tested Devel targets, works fine here. Yay. I'll probably re-fix linux tomorrow. I'm sure GCC hates no less than 27.3% of my new code. >_<
Great job Jake :) I don't think people realize how much work this is or how much better it is from the older GUI but we do! I'll test it asap keep it up ;)
I dont yet :( been too lazy to try it :P definately looking forward to it though!
Few crashes here and there, and it seems to hate enumerating zerogs.
Else its looking very nice already :)
This is great work! I like it way more than older one.
wow looking marvelous already!!!
seriously good job and the "run" menu is perfect^^
feels comfy cozy already XD

Revision 1506

Linux: Implemented the gui side of the new built in ISO loading functions in

Revision 1507

wxgui: fixed up linux size (and omg it was easy for once!)
Hey, isn't it the power of wxW ? :D

Revision 1508

Switched from vs2008 to NSIS for creating the installer.
Not final version, but putting it here as backup
Instructions in the txt
congratulations for changing to nsis krakatos, surely you are going to use lzma with solid compression? :)
Since the file is fast to compile, and there is the option to do that automatically, for every setup we're going with the one that takes the least amount of space. Bandwidth is precious after all
But yes, it's LZMA solid for now XD. And looks like it will be for the foreseeable future
[quote]Bandwidth is precious after all
But yes, it's LZMA solid for now XD. And looks like it will be for the foreseeable future[/quote]
for me bandwith is really precious, i'm on 56 kbps here.
good you are going to use lzma with solid, really nice. Thanks for the answer.
I think I need to clarify. Each time, I'm going to try all the compression methods and choose the one which gives me the smaller installer.
That way, we'll always have the smallest possible installer
oh, good idea, i understand now, thanks for the info. :)

Revision 1509

Made the EE recompiler 64-bit constant buffer (was called a "stack" despite not
being used as one) reuse recent constants rather than duplicating for every
instance, resulting in less recompiler resets (e.g. espgaluda resetting every
couple of seconds).
This revision makes character in God Hand (NTSC) flicker every second (Gene keeps appear & disappear).
I guess it has nothing to do with Gdsx, also the previous revision ran perfectly fine with same game.
Please can you have a look
My specs:
T9300 2.6Ghz
9800 GTX - 1GB
Vista Home 32 bit
Are you sure it is this revision? Would be very strange if it was.
I am sure because I follow all pcsx2 revisions.
Since this revision, character in God Hand keeps flickering, the previous revision I tried was r1504 and it does not have the problem! Correct me if I am wrong, but r1506, r1507, r1508 only affect GUIs, so r1509 must cause the issue.
I also tried with/without Speed Hacks, Native Solution. The issue still persists
I am running in DX10 Hardware btw
Confirmed, investigating the bug.

Revision 1510

Remove some messages from release builds, switch some remaining printf to
Console::Status and remove a layer of bloat when checking if an iso image is

Revision 1511

Start improving the CDVD interface. Change the internal ISO interface to use it.
I will later work on getting the typical plugins to support these new functions.
I have tried to also update the linux side, but I can't compile or test it so it
might not work properly.

Revision 1512

Tiny "Whoops".

Revision 1513

Now that having internal CDVD interfaces is easy, I added a NODISC interface,
with a menu option to run the BIOS with no disc.
I wonder if there will be any good for PCSX2 to go x64.... However good news here :")
Been done b4. No good came of it.

Revision 1514

Some fixes and cleanups. Now the File->Run* options won't reset the emulation,
so it might be possible to swap discs properly from nodisc, iso or whatever cdvd
plugin has been selected (to switch between iso/cdvdplugin/nodisc, it's
necessary to use the file menu options, as run->execute will not update the
active cdvd interface).
Why not have a "Eject CD/DVD" function from the file menu in the same way that psx (the ps1 emulator) does it? And have cd/dvd changing done via that method. Just an idea.
Eject should be in the cdvd plugin rather than the emulator itself, else things could get quite confusing and the emulator may not be able to remount the dvd if you swap.
@refraction: good point :")

Revision 1515

Debug message slipped in.

Revision 1516

Linux: Added the new menu options, and cdvd/bios running doesn't reset the
emulator on Linux, either.

Revision 1517

SPU2-X: Just the version update

Revision 1518

Fixed broken blockdumping in last change.
Added the possibility for plugins supporting getBuffer2 to return -2, meaning
"still busy".

Revision 1519


Revision 1520

Cleaned up Disk Type detection code, when workign with CDs, which in turn fixes
CD-based games booting (as far as I can tell).
Eh message should say "Cleaned up Disk Type detection code, and fixed detection of CDs" or something like that :P

Revision 1521

SPU2-X: Tagged public release v1.2
Am I wrong or SPU-X uses intrinsic memcpy routines instead of optimized ones? And if so why not to use optimized ones?

Revision 1522

Just a tiny cleanup, nothing interesting.

Revision 1523

Tweak for recompiler resets, helps a bit against the stalls when those happen.

Revision 1524

Cleaner version of the EE reset optimisation, there's no particular reason not
to skip these steps every time so there's no need for a second function.

Revision 1525

Give more information about the active disk even in Release builds.
Remove unnecessary re-checks at startup, so the cdvd info only shows up once
(and every time the plugin notifies of a disk change).
Add a condition to print which shouldn't be printing always.
Add a little "hack" to Mechacon command 0x80 ... will get rid of it later if it
doesn't help.

Revision 1526

Plugin interface / GSdx changes that binds the GSdx vsync option to the pcsx2
This patch by matsuri makes playing with vsync a lot nicer, so thanks for that
one ;)
Note: For now its directx 10 only, due to dx9 needing a swapchain reset..
Very Nice, DX10 vsync always was buggy and could limit games itself incorect
yeah in wild arms 3 every time for me -.-
really nice
Yep, now it works much better.

Revision 1527

Silence a stupid compiler warning, fix the layer1 detection code, and remove the
hack I added before, as it does no good.
Loading via CDVD Plugin does not work anymore on Vista x64. Last working version ist r1503 :-(
I code in Vista x64 and it works just fine here... which plugin do you use?
Also, please don't rate down a revision for something which it did NOT break. If 1504 broke it, then rate 1504 down, not this one!
I doubt 1504 broke it anyway, since it has no functional code changes. He probably hasn't tested every revision.
no, I have not testet all revisions but it isn't working anymore in:
sorry, but I could not test r1504-r1512
I tried Shadow of the Colossus and God of War 2.
i tried a plain new configured pcsx2-r1528 and cdvdiso.dll and various other plugins, but no success! No iso-file is loading. :-(
it locks here:
DvdRead: Reading Sector 263(8 Blocks of Size 2064) at Speed=4x
DvdRead: Reading Sector 809(2 Blocks of Size 2064) at Speed=4x
in Release 1503 it continues as follows:
DvdRead: Reading Sector 263(8 Blocks of Size 2064) at Speed=4x
DvdRead: Reading Sector 809(2 Blocks of Size 2064) at Speed=4x
PAL Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 50.0 fps
DvdRead: Reading Sector 811(1 Blocks of Size 2064) at Speed=4x

Revision 1528

Matsuri sent me a cleanup of his previous patch. No changes in functionality.
bool is not allowed in PS2Edefs.h. It's not compatible with extern "C", and thus cannot be compiled by non-C++ plugins. We'll need to revert back to int (but the rest of the code cleanus can stay, since bool<->int implicit conversions will be sufficient)
Oh... well not hard to undo :P

Revision 1529

wxgui: Fixed crash-on-exit problem in Release builds and made the console logger
thread-safe (uses messages instead of direct wxFrame method invocations).

Revision 1530

wxgui: minor code cleanups.

Revision 1531

Remove the bool from the GS exports, as Jake said.
Didn't know we have to support C plugins, so I didn't take that into consideration.
Well done.
I fixed the code for allowing users to resize initial windowed mode window via gsdx.ini file (for the custom sizes) or via the settings dialog. It also doubles as more comfortable way to switch between fullscreen and windowed mode. I think it'll be better to separate refresh rate setting from resolution but it takes much more effort to do so. Though it looks nicer with checkboxed window mode:
Here is the changes:
PS: GSdx.rc file is now 9 999 bytes )))
There is no default selection in resolutions list in that code but it can be easily added.
For example 800x600 as default (I beleive most systems support it):
GPUSettingsDlg.cpp / GSSettingsDlg.cpp
if(CComPtr<IDirect3D9> d3d = Direct3DCreate9(D3D_SDK_VERSION))
uint32 w = theApp.GetConfig("ModeWidth", 800);
uint32 h = theApp.GetConfig("ModeHeight", 600);
uint32 hz = theApp.GetConfig("ModeRefreshRate", 60);
Maybe open a new issue, its better for sharing patches and stuff ;)
Is it OK to use issues for this? If so I'll move there. ^_^
How does the user know which combination of width x height x refresh rate are valid?
... and setting the window size isn't really good, since it includes the non-client area, still not the selected resultion, as before.
>How does the user know which combination of width x height x refresh rate are valid?
If user going to manually edit configuration files he is certainly must know what he is doing, doesn't he?
And about setting the window size - I don't implied that it's precise setting. It's just a base idea for keeping same window size between program sessions. If you know the better realization I'll be only happy.
Yes, the ini can be edited even now, but that does not mean it should be.
DirectX enumerates the exact modes it supports, it's not something freely editable.
For 800x600, it might be avaliable today, but not tomorrow, and many lcdtv's are very picky, there are only a few modes they can display.
If you really want to set exact window size, there are system config calls that can query the caption and border size, it's annoying to calculate precisely but not impossible.
It can be edited but it's totally useless - in windowed mode (all the time I have talked about it) it doesn't really counts.
As for fullscreen mode I agree - it's not something that users must meddle with. But so I didn't change the configuration dialog that's why most users don't see any differences.
BTW 800x600 is just for setting selected item in the list it doesn't change current resolution if there are no selection. ;)
>> If you really want to set exact window size, there are system config calls that can query the caption and border size, it's annoying to calculate precisely but not impossible.
... or you can just use Windows' built in API for converting a client window size into a framed window size (you give it a client window size + the GetWindowLong() of the window's flags, and it returns the calculated size). I forget the name offhand. I can look it up.
AdjustWindowRect, found it
BTW I had already opened issue for this so if you don't mind let's continue discussion on the topic there:

Revision 1532

wxgui [Linux]: Updated project files, fixed docking logic.
Oops forgot about all my docking logs. Ah well, guess now's a good time to benchmark console performance anyway. :)

Revision 1533

Fix flickering characters in god hand from r1509.
Odd. What happened here? :p
EErec const/liveness bug. The _eeGetConstReg() function has additional optimization logic that fails on these particular instructions, likely because of malformed settings in the incomprehensible BSCpropagate table.
You make it sound as if you didn't like the awesome eeRec! (lol)

Revision 1534

GSdx: just squeezing a few more fps.
It seems previous bug with incorrect display of numbers in Persona 3 FES is no more. *happy*
But the one I had failed to mention earlier - graphical garbage in some scenes is still here:
Maybe it's possible to fix too?
And thanks again for you hard work!
I only ever reached the first fight, but that was normal.
Please make a .gs.
It looks like part of a game - trying to press Shift+F8 in margin of half of second from dynamic scene. ^_____^
OK here is the result of completing quest for the one garbage bug:
And one more result in a different fight:
Did you have any speed hacks on?
Strange but in two frames it cannot finish drawing the scene, only the characters are there.
2x cycle rate. EE is all. VU is except max/min. VU cycle stealing is on "moderate speedup".
It seems without the cycle stealing and status flag hack the problem still persist but become apparent on much rarer occasions.
Yeah that looks like VIF texture corruption to me. Most likely not the fault of gsdx.
Maybe, but this corruption was not seen in build 1384 for example so I thought that it might be related to gsdx.
And to next part - I have found one more strangeness. It looks like pale white lines grid in some scenes: http://img132.imageshack.us/img132/5895/gsdx20090718042123.jpg
Looks more like post processing issues to me, how does it look with gsdx in software mode?
The only thing it could be (which Persona uses) is Path3 masking, most likely the same change which caused problems with one of the Star Wars games. Probably going to remove that anyways.
nah, persona games are nice, no evil frame buffer tricks, it's just that with some settings vsync arrives more often than it should.
the other glitch, the thin lines, are probably the result of upscaling.

Revision 1535

wxgui: Optimizations and improvements to the console logger's threading model.

Revision 1536

wxgui: various cleanups.

Revision 1537

wxgui: Whee, a basic file browser dialog for Run Iso. Eventually it *will* do
something more than log the result. >_<

Revision 1538

GSdx: added ltrapper's modifications.
I don't know when did it happens but F5 doesn't work anymore.
Are you using an older pcsx2 build?
Ooops! So that was the reason...Tnanks
By the way in Xenosaga III loading sreen is broken in hardware like this:
It happend somewhere after 1376
So the changes are finally made it to the build. In spite of a bit misaligned controls in dialog box (look in issue 316 thread) it makes me happy. It was really annoying to manually resize the window each time.
very positive, just hope garbage in the upper left corner on FFX in the intro and the half bottom missing in hardware of Dropship can be fixed.
yeah FFX has a very similar garbage in the intro when tidus starts climbing the rocks when the camera changes (top edge of the screen), maybe it's related, the problem exists for some weeks now, i actually thought it was related with the emu itself since there are already a lot of graphical problems in FFX because of it
the FFX problem started at r1439, r1426 is fine.
hey gabest, i noticed that with r1479 (dx10) the messed up shadows in Ico are removed but with newer revisions they are present...would it be possible to do the same with shadow of the colossus and remove the glitchy shadows completely? i believe ico and sotc use the same game engine and they both have the glitchy shadow problem...i tried r1479 (dx10) with sotc but the shadows are still there so whatever was changed seemed to only effect Ico...

Revision 1539

* Console now uses a fixed-width font by default
* Core PCSX2 memory structures (VTLB and Recompilers) are allocated on startup.
* Added some more gui/ini/startup mess.
I would like to test the new GUI, what changes need to be done in the source?
Just make a new checkout directory pointing to the URL of the branch, in this case http://pcsx2.googlecode.com/svn/branches/wxgui/
nice progress speed jake!!!
sry for the double post
will it be possible to change the theme of the gui?
The icons and backgrounds will be changeable via theme. The window frames are not.

Revision 1540

microVU: Work in progress stuff... (no functional change)
Just interestig, what this WIP about? :p
First few lines from /trunk/pcsx2/x86/microVU_Alloc.inl:
// Reg Alloc
I think the comment makes it pretty clear.

Revision 1541

microVU: cleanup (removed old mmx vi reg caching)

Revision 1542

microVU: more work in progress stuff...

Revision 1543

- Added *.MDF Disc Images to the "Run ISO" file browser.
I'm not entirely sure if theres any file system differences between .mdf and
.iso (couldn't find much info on it); but all my .mdf files are working as-is
with gigaherz's code, so I think compatibility should be fine.
- Moved "Run ISO" menu option above "Run BIOS" since users will run ISO's more
often than the bios xD
- More work in progress stuff... hopefully I finish within the next few days.
congratulations on this change cottonvibes, since ppl use formats like .mdf, .bin or .ccd more often than .iso usually this make it as a nice and indeed useful add-on. :)
There was an opensource project mdf2iso that allowed conversion of mdf to iso, so I guess they are not exactly the same thing.
it could be similar to dolphin
Yay, regalloc :>
Hope it works out and doesn't clutter too much ;)
can't wait for new allor funcs in mvu :P
Hi there,
you might want to have a look at libmirage (http://cdemu.sourceforge.net/pkg_libmirage.php) since it lets you access a lot of image formats. It's the central image access library for the cdemu optical disc emulator (something like the equivalent of dtools on linux).
I'm just wondering if register allocation will make a posible huge speedup for mVU.
Cotton, i'm interesting what should bring new mVU changes?
Comment by ntcong.it, Today (18 minutes ago)
I'm just wondering if register allocation will make a posible huge speedup for mVU.
Speedup IS RegAlloc's only reason for existing. Huge or small is what we don't know yet.
Hi there,
you might want to have a look at libmirage (http://cdemu.sourceforge.net/pkg_libmirage.php) since it lets you access a lot of image formats. It's the central image access library for the cdemu optical disc emulator (something like the equivalent of dtools on linux).
I have been looking a bit through the libMirage docs. It doesn't look too complicated to use but, it kinda annoys me that it requires GLib to compile. I dont' know if libMirage and GLib would bot compile fine under VisualC++ 2008, and I would rather avoid adding another external library to the project.
I wouldn't blame anyone if they decide to use it, but I think this kind of implementation should be left out of the core project and, if anyone really wants it, implemented into an external plugin.
Hm forgot to separate what's quote from wht's my text ... oh well too late for it XD
well I don't know what advantage there's in using the new built in option "Run Iso" instead of an external plugin first.
Anyway, both seems to work fine for me.
about the mVU changes:
Been working on implementing some smart regalloc into mVU.
regalloc (register allocation) is basically an idea to keep values in registers as long as possible, to eliminate writes/reads from memory (which is slower).
I have no idea if this will be a speedup or not. But I was planning to rewrite my upper opcodes in a neater format anyways, and since i was going to do that, then i decided i might as well implement regalloc while i'm at it =D

Revision 1544

wxgui: Added more functionality to configuration dialogs and more options are
saved to ini.
eager to see this in main trunk soon:)
Its all coming together.Looking forward to see it complete.

Revision 1545

microVU: more W.I.P. regAlloc stuff (upper opcodes are using my regAlloc class
but are set to flush every opcode so speedwise this commit should be slower (or
the same as before)
Once I rewrite my lower opcodes to use regAlloc, I can remove all the flushes.

Revision 1546

- Fixed Micro Program Logging (broke it on my last commit)
- More regAlloc work
- Big Cleanup, deleted about a thousand lines of obsolete code.
Always good to see improvement on microVU.
I have a general question concerning the different processing units. As far as I know the PS2 has 5 PUs: the R5900, the 2 VUs, the GS and the IOP / R3000.
Which is the PU that does the "most work"?
I'm asking because the microVU rewrite of the VU recompiler implicates that current emulation is suboptimal. Also does Jake work on the R3000air recompiler. I wonder because the R3000 / IOP seems to be the slowest PU inside the PS2, so why bothering rewriting the recompiler for that component?
VU recompiler rewrite was more for maintainability and compatibility than for speed. The old SuperVU was pretty efficient on whole, but had a handful of fundamental compatibility issues that were going to be neigh impossible to fix within the context of the way the recompiler was written. It also left no room for potentially threading the system.
The R3000a is for most intents a purposes a simpler version of the R5900. Most of the core instructions are implemented similarly (with the exception of the R5900 having 64-bit sign extension on all the 32-bit instructions). The goal is to be able to re-use the first-pass interpreter and bulk of the regalloc code being written for the R3000a for a rewrite of the R5900. Also, while the R3000 is the least intensive of the PS2 cpus it also has by far the least efficient implementation, so there should still be an easily noticeable improvement in speed once the new R3000a recompiler is finished.
(Having two branches to maintain is killing me tho,s o I'm trying desperately to get wxgui working so I can get myself down to one branch)
Thanks Jake!
I see, so microVU is basically a rewrite because of superVU's design flaws that can't be easily fixed (without major hacks). Do I understand it correctly that current VU impl doesn't support any threading?
I know that the GS impl support multi-core systems and I was assuming that for multi-core systems the two VU recompiler could be mapped to different cores. Is this even true? Or is there some kind of sync issue between the two VUs which makes it impossible (in the current state) to run them on different cores?
Also, does that mean that with microVU it will be possible to utilize >=dual-core systems properly? (e.g. each VU recompiler spawning two threads, so each core of a quad-core system has work to do).
Anyway, I'm really looking forward to the wxgui since I'm primary a linux user. :)
Currently using pcsx2 on WinXP though since the OpenGL plugin (ZZogl) is a lot slower than GSdx. Plus ATI's fglrx driver on linux isn't on a par with the Windows driver. I'd very much like to see Zeydlitz and zerofrog join forces once zero returns (I think he's pretty much inactive at the moment).
Threading the VUs is tricky because of sync issues with the R5900 and DMAC components of the EEcore. There are a handful of hardware registers which are shared between the devices that need locks or copies to protect them from corruption. There are also other sync points and branch conditionals that need to react appropriately based on the state of the VU1 microprogram execution status. I did some preliminary experimentation and got the VU1 running *mostly* threaded, but not yet stable (most games ran, but with severe geometic errors).
Ultimately the benefits of threaded vU1 will be minimal for most games. Only games that make heavy use of the VU1 will really benefit -- but those are currently some of the slower games to emulate, so it should be worthwhile.
>Only games that make heavy use of the VU1 will really benefit
Could you please name a few?

Revision 1547

- More regalloc work/fixes
- Implemented some untested SSE4.1 optimizations (can't test since don't have
sse4.1 cpu)
- Added an SSE4 instruction to the legacy emitter (just a wrapper to the new
emitter function).
Note: Currently tri-ace fix and logical min-max code (thing that mad DaZ safe to
use) is broken with mVU. Will fix later.
Great job! Looking forward to SSE4 and 4.1 improvements
WOuld like to add that KH and Kh2 are buggy with mvu
KH1 has SPS
KH2 has weird slowdowns caused by random things, like equipping too many abilities or items.
Completely fixed by disabling mvu.
Makotech: can you find out where it was broken (im sure it worked at some point) and submit an issue.
Excuse my curiosity, but what the difference between opCase3 & opCase4 ?
source /trunk/pcsx2/x86/microVU_Upper.inl
opCase3 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }
opCase4 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }

Revision 1548

Did a bit of cleanup on the new iso code, mainly so we're using the Console
functions for messages.
And, yes, I'm back from my vacation. Looks like no one broke Linux while I was gone, too, which is nice...
And that isoDetect code was bugging me with how repetitive it was, so I refactored it.
The filereading code bugs me a bit, too, with the Linux and Windows sections being totally different. I'll have to see if there's a crossplatform way to do it when I have more time available.
Probably does not matter much with an iso, but readTrack and getBuffer are there to make readTrack non-blocking.
Does linux have anything similar to overlapped io of windows? It just fits here so nice as if it was designed to.
The current iso code implementation doesn't even enable asynchronous (overlapped) file access when it opens the stream, so the code is pretty much functionally equivalent to using the ANSI C file streams anyway. That is, you could #if 0 the win32 version and have both win32 and linux use the generic version and it'll work fine.
While I doubt overlapped i/o would be beneficial for reading isos (most read operations will be pulled from the internal cache management, and CDVD block sizes are a bit small for efficient overlapped io performance), the Win32 API does give a fine-tuning option on how data is cached for reads; either random access or sequential. Enabling sequential caching might be a small performance gain. Or maybe not. I've never experimented with it.
It just worked well for reading dvds directly, for isos someone may mount them from his slow NAS (like me :P).

Revision 1549

- trying the dx10.1-only "gather" shader instruction for palletized lookups
("8-bit texture" mode), saves 4 instructions which isn't much but still... (not
tested, don't have ati)
- may fix the intel gma "no output" bug (don't have gma either :P)
- and the usual small code optimizations
I'm not quite sure yet how gather works, it probably shifts the input coords by +/- 0.5, but that may depend on the sampler filter (will it still return 4 different texels when point sampling is set?)
Here is a bit modified build:
And here is one without gather, for comparision:
"- trying the dx10.1-only "gather" shader instruction for palletized lookups
("8-bit texture" mode), saves 4 instructions which isn't much but still... (not
tested, don't have ati)"
shouldnt matter about ati, dx 10.1 should be available across the board, working on all existing dx10 hardware (including Nvidia) :)
dx10.1 is only available for recent ati cards, mobile 40nm nvidia parts and maybe a few integrated chips.
nvidia's desktop 40nm dx10.1 is only coming soon. Nvidia does have dx10 extensions, but that is a "different function".
I have a 4850... wonder how to test... time to compile...
just tested this on my 4890, there's some weird texture pixelation occuring now..
my bad, stand corrected ;p
chuuey: did you also test the two other build I linked in the first comment? do you see any difference in look or fps?
btw, this "gather" thingy and other 10.1 features will be all available in 11, they have to keep it backwards compatible, of course.
oh and please upload screenshots of the errors :P
DX10.1 lol, suppose you will also be looking into DX11 support in future. :p
You're among the most curious developers I know to try out stuff, I mean SSE4.1, multicore software rendering, DX10, I'm suprised you haven't tried using CUDA yet. xD
Tested with gather and without, windows 7 on a 4850 card in 1474 beta.
http://i27.tinypic.com/dmy4jo.jpg -with gather
http://i30.tinypic.com/9l92zo.jpg -without gather
It Doesnt seem to be all graphics, only certain text. Menus on GT are ok but in game text is pixelated and changing interlace doesnt help (screens are from same interlace setting). On Extinction only the language select is affected. Both games are PAL.
Seems wrong :P
Can you see any diff between the svn build and GSdx-SSE2-w-gather.7z?
I might just buy an ati for testing... Is the 4350 a good card?
well i also tested with your build, same pixelation effect, but it's even worse ;) by the way, ffxi flickers from time to time when changing zones ;)
for testing you'll just need any ATi card with 10.1 i guess ;) unless you need the extra performance ;)
I could also use the reference rasterizer for free! :D
your build with gather :
my compile:
both incorrect ;)
The 4350 has only 256mb of framebuffer afaik. It'll not represent actual common performance very well, but otherwise it should be good.
Maybe the 4830 is a better choice? ;)
Oh, this one might do as well:
Yeah the ATIs are like the NVidias when it comes to how they number cards. The low end of the higher series is worse than the high end of the lower series. That is, a 3850 is probably better than the 4350 (in the same way the 7800 series nvidias are generally better than 8400 series). So if you want to get a 4000 series you really should look at 4600+.
http://i26.tinypic.com/2rc5w0i.jpg -w gather build
http://i28.tinypic.com/28apc1v.jpg -1549 build
http://i29.tinypic.com/r86tq9.jpg -no gather build
On the language select screen only the background is animated so there is no in-game variation in the text aside from the build change. With 8bit textures disabled it looks the same as no gather build or older versions.

Revision 1550

More iso work. Timestamps work in Linux now (and use Paths.h). Worked on getting
rid of other redundant code, moving the logging to the standard pcsx2 log
functions, and misc cleanup.
1 line-by-line comment
line 270:
270: char fname[MAX_PATH], ext[g_MaxPath];
Missed a MAX_PATH here.
Oops. Oh well, I've already rewritten that section, anyways. I just haven't had a chance to make sure it works in Windows. After adding a GetCurrentDirectory function to PathUtils, it looks like this:
if (CDVD.init == ISO.init)
// Base it out of the current directory for now.
string temp = Path::GetCurrentDirectory() + Path::GetFilenameWithoutExt(isoFileName);
strcpy(fname_only, temp.c_str());
strcpy(fname_only, "Untitled");
ah MAX_PATH is evil, but ought to be enough for everyone :D

Revision 1551

GSdx: disabled "gather" until I can sort it out

Revision 1552

GSdx: ffxii fmv works again and even less bogus
Hello, Gabest. About Issue 184 . Software mode doesn't really help:
This rev seems to solve the display problem for the intro fmv of FF XII PAL. But black flashes can be seen now during this same FMV. I'm not sure this is caused by this revision as with the previous ones, this FMV was not watchable before.
Hello, gabest11. Good job as usual. BTW I had to report that Steambot CHronicles crashes the emu with that version ot the plugin (DX9 and DX10) mode.

Revision 1553

GSdx: Disabled requesting of thread safe D3D devices. This is a speedup, and we
shouldn't need the safety.
We discussed this in IRC and tested a bit and it should be fine. I made certain many moons ago that all calls to the GS occur from exactly one thread (in MTGS mode it's the MTGS thread, and in STGS mode it's the main emu thread), with the lone exception of the plugin enumeration and versioning functions (but those should be fine ;). So there should really be no chance of a GS plugin calling any DX function from multiple threads.
But still, this modification needs to be tested to be sure there's no lingering mistakes. Typically if there is a concurrency issue it'll rear up as a monumental failure -- either a GPF of pcsx2 or a hard lock of your computer. So if anyone gets those, please report immediately.
I'm doing this on my games right now btw.
I tried this before, but there was no difference.
didnt get any crashes with about 2hours playing various games, and there is a speedup in almost everything (and now xeno 2 is finally faster than r1426)
Everything should be a way faster, still has slowdowns in MGS3 left from r1439, other games are faster
Tested it again and it really got faster about 10%.
Though one of the new features of dx11 is supposed to be better multi-threading.
There are drawing contexts can be used to submit drawings on different threads and replayed fast on the main.
I'll have to think about how to take advantage of that.
I downed VC10... what is the difference with VC9?
compiled with vc10 beta1
Thanx :") I`ll test it ASAP. Btw there were improvements with your latest GSDX - VP2 had more speciall effects visible, TEKKEN5 was faster on a certain usually-slowdown-places. GSDX gets better and better - CHEERS!
Wow. FFXII jumped 60%, or 75fps to 105+fps. I think it's time to use the frame limiters.
After a bit of playing noticed some big errors in SW mode. Will post on forums.
Tested bot Visual compiles 9 and 10 - some small efx differences... Better speed confirmed. Steambot Chronicles still crashes emu.

Revision 1554

wxgui: Tons of updates and fixes ...
* Mostly finalized the i18n system.
* fully implemented the speedhacks dialog.
* improved the wxHelpers quite a lot.
* added a new gamefixes icon as put together by gigaherz.
can't wait to see this make it into the main branch

Revision 1555

microVU: minor changes
Sorry bored you. I have a mem card save (Mcd001.ps2), now every time i begin a game, he jumps out, only with GSdx-r1553, because with GSdx-r1538, dosen´t happend. I'm trying to help, if they want to continue to call me names, continue.
P.S.- the game works if i put in Porgressive Mode 480p, if this help.
ferrarin: as long as your comments are not just worthless "GT4 still doesn't work" kind of comments, and they contain useful info, we will have no reason to delete them. Now if you were to repeat this originally-useful info over and over on every new commit, than that would go back to being spam, and we would proceed to delete your repeated posts. We can read the comments, no need to repeat yourself.
then* (hate googlecode not having an edit comment button >_<)
Gigaherz, i just want to help, for you can help me. Thanks.
I dont' have GT4 (or any other GT game) and I don't know what causes the problems you have with those games, so no, I cannot help you. I n any case, that's not how the team works.
You see, all the developers and contributors are people with their lives, who just like to help the project. If they aren't interested in fixing GT games specifically, then you are out of luck. You have a few options: either fix it yourself, or buy a real ps2, or just wait patiently until someday it gets fixed.
We just don't like being "reminded" of bugs, or being pushed to fix them. We are doing this for free, because we WANT to.

Revision 1556

Made a clean fix for the memzero.h template expansion bug/warning (caused by
msvc treating template parameters like macros).
Before, with version GSdx1551 was not error now gives.
Correct. With GSdx-1538 works, the up version dont, so i think is a GSdx problem. Sorry my mistake.

Revision 1557

Added clean_msvc.cmd, which is a batch file that deletes all the mess MSVC
leaves behind even with Clean/Rebuild. Chances are if you're having
compiler/linker problems you can just double-click clean_msvc.cmd and have it
fixed, rather than having to do a full re-checkout of sources (see file for more
details on why).

Revision 1558

wxgui: synced with trunk (to acquire new CDVD/ISO api)
I'm leaving for the weekend. I'll fix the linux side when I get back.
All right, sounds good...

Revision 1559

Added a few new calls to PathUtils, and used them to get rid of some platform
specific code in the new Iso code. I also modified some other code to use the
new calls, and fixed a few microVU compiler warnings.
GetWorkingDirectory was going to be GetCurrentDrectory, but Visual C++ didn't like it. And I can see one or two remnants of reverted changes in here. Not a big deal, though.
Yeah, you cannot force msvc to accept typo'ed variables :p
That too. ^_^

Revision 1560

Reworked a few things in PcsxConfig, to make things a little more organized, and
make path changes later easier. (May have broken Linux temporarily. If so, I'll
fix it in a bit.)
Notes: Both Linux and Windows had variables they were saving the working directory into. These have been combined.
Also, I figure if we have iso handling built in, sooner or later we'll want default directories for isos and dumps to be in.
And, yeah, I did the Windows changes first because people get all upset if I leave Windows broken for any length or time...
Comment by arcum42,: "And, yeah, I did the Windows changes first because people get all upset if I leave Windows broken for any length or time...
-True , Windows user are often very angry in their natural habitat
Scientists are guessing that it could be 'cause the "Blue Screen" feature commonly reffered to as "BSOD" has been deactivated in latest windows versions
sincerely KabooZ
absolutely agree......^_o
BSOD is a great feature....
<it makes me remember i often reinstall my system and spent my weekend with my computer>
(sorry double post)
Yeah, there's nothing like that feeling when your system suddenly grinds to a halt and you have to reboot. ^_^
Though I've found I can reproduce the feeling somewhat by running my Linux system with all unstable packages, and updating it regularly, so things randomly break every so often...

Revision 1561

Fixed up Linux after my previous changes.
so no more BSOD for linux...?
just joking.
it's morning here.good morning.
(I'll go to work in a minutes.feel free to delete this message as it has no relation with the rev.I just love the progress in linux side.I'm always dreaming linux and windows and also other operating system will be equal each other and each of them has different special feature (like direct-X for windows and OpenGl for Linux) but has almost the same performance)
yeah directx for MSDOS 6.22 or for OS/2 xDDDD

Revision 1562

Converted a few of the file paths to strings, and moved the generic file
manipulation functions in IsoFileFormats to their own file.
The Plugin and Bios paths were more complicated, which is why I haven't done them yet...

Revision 1563

Unbreak FF X-2 with the new iso code.
for (int i = 12; i > 2060; i++)
Oops. Oh well, I didn't really need to zero that out anyways. Just thought it'd be cleaner if I zeroed out the area it was supposed to copy to.
i wonder if this is similar to the classic "Auron: Look!" crash, what happens if you wrap it?
They seem similar. When I saw how close they were, I pulled out a savepoint 20 seconds before "Auron, look!" and played with it. Didn't have much luck, though. And I recall trying wrapping it a few ways...
I spotted this one because I'd testing to make sure I hadn't broken any of the code. Took a little while to trace what the difference was in routines. The linuz plugin *never* returns anything other then 0, no matter what goes wrong.
The pcsx2 code's rigged up to set pTransfer to NULL if there was an error, but since there never was, it doesn't seem like anything was put in place to handle it...
have you guys emulated the ps2 cache yet ?
by the way tanx a billion for your hard works .
There is some preliminary cache code in pcsx2 that was written quite a while back, and not enabled; my understanding is that at the time it only worked properly for a game or two, though.
While that code is still in pcsx2, it didn't survive the change in memory models, and won't compile if enabled. Most games work without it, though, so it's been a low priority...

Revision 1564

GSdx: just updating vs2010 project files

Revision 1565

Added vs2010 project files for xpad and CDVDolio, too.
My command line build automation for 2008 is broken now, devenv just crashes with 2010 on the same machine...
So, don't expect 2008 builds until this gets fixed somehow, only if I manually compile and pack it.
Hi Gabest. Sorry for unrelated post. But I really couldn't catch your attention on forums. It's about an Issue 184 . Hardware mode is a wontfix... how about software? Here's .gs dump:
If software mode can't be fixed please say it.
Must be a new bug in sw mode.
Added my thoughts about xenosaga to Issue 104 .
I mean Issue 184 , haha.

Revision 1566

Fixed some bleedthrough on the colors on the console, took care of a typo I made
earier, and did assorted cleanup.
This revision borken windows version...
4>..\..\CDVD\IsoFStools.cpp(153) : error C2440: '=': 'char *' kann nicht in 'char' konvertiert werden
4> Es gibt keinen Kontext, in dem diese Konvertierung möglich ist
4>..\..\CDVD\IsoFStools.cpp(155) : error C2664: '_strnicmp': Konvertierung des Parameters 1 von 'char' in 'const char *' nicht möglich
he said cannot convert char into const char*
and can't convert char * to char XD
Already taken care of.
yeah I noticed a minute after posting -.-
why does that wokr in linux and in windows not? (I just assume it works in linux :P)
I have no idea why that works in Linux.
And, yes, it does compile and run in Linux. No matter what "vaustein" may think (on the forums), I do compile all changes before committing, and normally have run at least the opening of a game. (Multiple games and more then the opening, if it's a major commit)
Major commits get tested in Windows as well, but this was mainly a collection of minor stuff. One of the changes in CDVD.cpp and the change in Console.cpp were the main things I wanted to commit. The rest were just incidentals...

Revision 1567

- Re-implemented logical min/max code
- Re-implemented tri-ace gamefix
- Fixed some bugs...

Revision 1568

microVU: Setting VU clamp mode to "normal" should fix sps/problems in alot of
games now.
I'll list what I think should be fixed:
Dawn of Mana SPS <- Should be fixed, untested
ToTa Characters <- Should be fixed, untested
FFXII SPS in Barheim Passage <- Should be fixed, untested
KH1 floor bug <- Fixed for me, but theres still other sps on characters caused
by something else
Most-likely SPS in some other games is fixed as well...
If anyone can confirm the games I listed are fixed, please leave a comment :D
I confirmed Dawn of Mana sps is indeed fixed.
shoegazer tells me this fixed burnout as well.
tales of abyss disappearing characters is not fixed
FFXII SPS in Barheim Passage: Confirmed,fixed.
There is no more SPS around characters in ToTa when clamp is set to normal, but characters are now invisible.
Nice Commit, fixes:
MK Deadly Alliance missing geometry
Simpsons The Game SPS
It fixes SOME sps in Castlevania, but not all of them.
Still, now, it is MUCH better :P
Nice work.
thanks for the comments guys.

Revision 1569

Quick fix for r1566.
That shows what's probably C's most annoying design problem (pointers being a variable attribute instead of part of the type).
yo ucould have also solved it like
char *token, *ext_point;
but I guess it looks "wrong".
more weirdness: a typedef'ed pointer will not have this problem :D
Oh, if I'm reverting a change, I just tend to revert it back to exactly the way it was. The other way would have been fine, too.
It was one of these things where, once I saw it, I knew exactly what I'd done wrong, but I just hadn't noticed it at the time...

Revision 1570

microVU: more regAlloc work...
This rev fixes We Love Katamari (SLUS 21230) missing polys problem introduced in r1545. Thanks Cotton!

Revision 1571

- Automatic texture filtering should be ok now, occasionally point filtering was
used. Tested it on the ps2 and figured with no mip levels LoD and minification
settings are just ignored altogether.
- Also run a few tests on the gather instruction with the reference rasterizer
and found a fatal flaw with it. It returns the four samples for bilinear
sampling (in a funny order, which isn't documented of course, x = bl, y = br, z
= tr, w = tl), but there is no way to guess which four were selected exactly.
Due to some hidden rounding error it might grab different texels than I would
when calculating the position of the upper-left texel, of which the fractional
part is be used for the interpolation. When the texel positions do not match it
leaves annoying discontinuity errors. Oh well...
Forgot to mention but the pixel shader might be too complex for 2.0 and it won't compile.
error X5426: Shader uses texture addressing operations in a dependency
chain that is too complex for the target shader model (ps_2_0) to handle.
So I added the D3DXSHADER_SKIPVALIDATION flag, let's see if it works :P
Btw, it's probably because texture coordinates are now looked up for region repeat modes, ever since Jake enabled it in r1340 :P
Texture filtering seems fine again.
Noticed it stopped filtering a few textures in Grandia3 a while ago.
Well, that's fixed :)
GT4 has problems that I cannot fix, the data coming from pcsx2 is wrong.
Hey gabest, just checked it a bit, and it seems sm4.1's gather is meant specifically for shadow stuff: it supports only single-component texture formats, and returns the values in w,z,y,x (clockwise)... or that's what AMD/ATI's pps says :P
Also, quoting from: http://msdn.microsoft.com/en-us/library/bb944003%28VS.85%29.aspx
"Gets the four samples (red component only) that would be used for bilinear interpolation when sampling a texture."
I'm not sure what were you trying to use Gather() for, but I don't think it's useful in its SM4.1 version.
On the other side, SM5.0 (d3d11) supports GatherRed, GatherBlue, GatherGreen and GatherAlpha, so that one might be useful, I guess.
But maybe you already knew. :P
This sounds a bit like it could be used for blending?
(Hoping some clever technology comes up to replace the problematic blending in hardware rendering :p )
GSTextureFX10::SetupOM << this stuff. It causes like 80% of the remaining bugs (exaggerated, but still :P )
I wanted to use it to replace four texture sampling with one, for palette lookups when first reading the indexed texture.
After getting the sample order right (trial and error), it actually worked about 99% well, just those ugly dots that appeared because of inaccuracy...
Only reading red channel isn't a problem, as I can create the indexed texture as a red-only format.
It would be more convenient if it returned the alpha though.
huh? :P
Games I know are broken due to the blend (can even hackfix them sometimes ) :
-Haunting Ground (The stripes in the image)
-Valkyrie Profile 2 and Radiata Stories (Also the stripes, the games are trying to do some depth of field effect and fail)
-I think Shadow of the Colossus and the Ghostrider game as well (not confirmed yet :p )
The stripes are the sign of 32/16-bit frame buffer casting.
16 bit data is arranged so that it takes up every other 8 pixel of the 32 bit frame buffer, or something like that.
Games specifically draw in columns then change the format and it magically becomes right.
Here's my results for valkyrie profile 2:
-First is software rendering, which shows the depth of field effect working:
-Second is dx10 hardware rendering as it is now:
-Third is dx10 hardware rendering with this hack:
//bd.BlendOpAlpha = D3D10_BLEND_OP_ADD;
bd.BlendOpAlpha = D3D10_BLEND_OP_MIN;
And last one is with another hack added, that fixes the texture scaling:
dst->m_texture->m_scale.y = (float)h / hh * 0.8f;
I hope this helps somehow. If not, I thought about asking what you think of game specific hacks in GSdx? :p
Are the aforementioned blending issues vaguely related to TotA's offset bloom effects?
Nope, those are a slightly different issue (but related to the texture scaling hack).
Thanks for your plugin, run fine i probe your plugin dx9 in wine but run slowly but you have planned plugin for opengl?
Is it using one of the blending modes marked "bogus"?
Upscaling ratio is only estamated, offscreen rendering may span over the frame buffer edges :P
Opengl is hard (chaotic is better word) and I have no help, currently on hold.
Found an old .gs that has the clipping problem but can't see the blending problem with it.
"Is it using one of the blending modes marked "bogus"? "
I think so, yeah :p
"Upscaling ratio is only estamated, offscreen rendering may span over the frame buffer edges :P"
Ah, ok. I thought it was due to lots of rounding, and at some point it missed an important pixel or smth.
I think it uses // * 0200: (Cs - 0)*As + Cs ==> Cs*(As + 1) ...
thank you its fixed now.
P.S: EXCELENT job :)
This .gs should work (Also has some nice texture detail etc, vp2 is looking awesome! :p )
The common thing with the red fog garbage in vp2 and xenosaga3 and the overbrightness is all in this part btw:
else if(tw < tp)
// FIXME: timesplitters blurs the render target by blending itself over a couple of times
All these games have that condition, and if we simply return there the buggy scenes get skipped.
Any idea if that can be done better? :)
This file is neither allocated to a Premium Account, or a Collector's Account, and can therefore only be downloaded 10 times.
I was late to the party :P
Sigh, I've had it with file hosts... :p
Steambot Chronicles still crashes emulator when started... wonder what`s the reason..... But otherwise - good job!!!
please re upload the file ramapcsx2.. thx and god bless

Revision 1572

wxgui: Improved threading model used by the log window, plus a few minor fixes
to main window startup/shutdown code.

Revision 1573

- Finished implementing regAlloc. Sadly the speedgain wasn't great (0%~2% in the
games I tried). I think the speedup should be bigger with a CPU that supports
SSE4.1, but I don't have one to test :p
Anyways I was able to cleanup a lot of code while implementing the regAlloc so its not a complete loss. And having a regAlloc class to manage reg allocations makes future modifications easier :)
Speedup is always good, even if it small
Lemme test that. :p
Ok, preliminary results are somewhat poor. Sometimes I can't even see a 1fps difference.
I'd say you got a bug somewhere?
Red terrain bug in Shin sangokumusou 4 (Dynasty warrior 5) was again.
and still SPS.
Hey man, if it makes future modifications easier that's a plus. Remember, that was one of the reasons you began this project, to make the management easier. So to take a step towards that in my mind is a success. Keep it up.

Revision 1574

microVU: tweaking/testing some stuff...

Revision 1575

microVU: fixed a bug in my clamping code from r1568. Fixes TOTA invisible
characters when clamp-mode set to 'normal'
Is it OK that opCase3 and opCase4 have no difference (setupPass1 method)?
opCase3 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }
opCase4 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }
nice, another bug squashed
yes its okay ;p
just a little testing
game Naruto Shippuuden Narutimate Accel 2
these screens captured with microVU (missing geometry proble)
and these ones are with superVU (still mising geometry but much better compare to mVU)
try turning off both mVU speedhacks, they were causing problems in NuN3.
i don't have NA2, but its most-likely the same problem.
Nothing changed unfortunatelly
use mvu0 and svu1 and it should work
for this game it's the same as using just sVU

Revision 1576

Working on a brand new plugin interface, based on passing APIs via structure
instead of individually binding each function (which is generally cumbersome and
limited in a number of ways).
Much work and documentation left to do, but it's a good starting point I hope (and I need a break for a few hrs). I've been trying to cover most of the initial sticky points with irc discussions, but there's likely things I'm still overlooking.
Also, I'm planning on retaining most or all backwards compatibility with existing plugins using a compatibility layer api. So no worries there.
If you really want to create something cool, why not make it a bit object oriented like COM? Without reference counting of course :P
First parameter would be the instance data, the "this" pointer.
It's just so ugly that plugins define it as a global variable instead of dynamically allocating it in the only exported function like DllGetClassObject and getting back as the first param in each call.
Actually that's not a bad idea for performance efficiency, if nothing else. If I change from CALLBACK to __fastcall that can actually reduce the overhead of function invocations by quite a lot, and really there's no reason to be using CALLBACK on all those fnptrs. I was just following the established convention.

Revision 1577

Cleaned up some loose ends I left behind in my initial rough draft of
PluginCallbacks.h, and added some eol-style:native properties to /common/include
files that lacked them.

Revision 1578

microVU: Improved microProgram management/searching.
Instead of just having live/dead programs, we now have young/old/dead programs.
This works great with GoW (the game still needs the CHECK_VU_CONSTHACK hack ON to get good speeds)
Super VU will always run GoW faster however because it recompiles alot less than mVU.
But, mVU runs the game more accurately:
Super VU: http://img.photobucket.com/albums/v177/ouchmytiredhurt/zeroRecsGoW.jpg
microVU: http://img.photobucket.com/albums/v177/ouchmytiredhurt/mVUGoW.jpg
Gow with this executable is fully playable without the blocks?
This fires on blades of chaos is always were correct on MicroVU
VU_consthack is good but still fps in GoW is unstable anyway i like this game on microVu more than on SVU

Revision 1579

NewPluginApi: Some tweaks as per Gabest suggestion; probably a tired disaster in
need much review.
// fixme! [air dies of sleep deprivation]
yo me 2 >.>
but now I'll get a good night's sleep... or rather day xD
btw air you work mostly on larger projects (or so it seems to me^^)
how come?
I like this function OSD_WriteLn().. also can't wait to see a snapshot
of savestates being displayed at the right top corner like psx emus.. ^^
One silly question tho, I wonder if external developed plugins (not with
pcsx2 project) would be compilable with these new changes and new definitions?
or it would be like before, all whats needed is "PS2defs.h and PS2Etypes.h"?
Well, the files will change, but it'll be like before. The existing plugins will have to be updated to use the new interfaces tho.
>> btw air you work mostly on larger projects (or so it seems to me^^) how come?
... because I'm too fancy for my own well being.
>> One silly question tho, I wonder if external developed plugins (not with
pcsx2 project) would be compilable with these new changes and new definitions?
Like before but, hopefully, even better. I'm trying to keep the design as independent of emulator and external libraries as possible. It will check for and use certain things if available (such as some of wxWidget's base cross-platform defines for window handles), but these aren't critical defines either... in that they have reasonably sufficient fallbacks.
That's nice, but I imagined it just a bit different :P
With a little change it would be possible to cast those function pointer structures to c++ classes with the novtable attrib.
That's way it would be compatible with c and c++ at the same time.
"That way" I mean, where is the edit button!
Google has ingeniously converted the "edit" button into "delete + retype comment + submit" xD
LOL for me its more "Copy+delete+paste+fix your error+submit"
>> With a little change it would be possible to cast those function pointer structures to c++ classes with the novtable attrib.
You're going to have to be more specific because I'm not sure what you mean.
The novtable is MSVC specific so I assume its use is in the plugin only, although the docs for it are vague so I'm not sure how it really changes typecast behavior, or how I'm supposed to restructure the struct to match it. And I don't know anything about COM except that typically I can't comprehend its bizarre syntax and profane use of operator overloads, so citing that as an example probably won't be helpful.
Did not test it, but something like this:
struct IPlugin;
struct IGS;
#if defined(__cplusplus)
struct __declspec(novtable) IPlugin
virtual bool CALLTYPE init() = 0;
struct __declspec(novtable) IPluginGS : public IPlugin
virtual void CALLTYPE vsync(int vsync) = 0;
typedef struct IPluginVtbl
bool (CALLTYPE *init)(IPlugin* _this);
} IPlugin;
typedef struct IGSVtbl
bool (CALLTYPE *init)(IGS* _this);
void (CALLTYPE *vsync)(IGS* _this, int field);
} IGS;
class GS : public IGS
// IPlugin
bool CALLTYPE init();
// IGS
void CALLTYPE vsync(int field);
GS() {}
extern "C" __declspec(dllexport) IPlugin* CreatePlugin(int type)
case GS: return new GS();
return NULL;
IPluginGS => IGS
When inheriting a class in pure c the members have to be repeated, that's the only annoyance.
In COM the name, version and other properties are stored in the registry so there are no exported functions to query those.
It would be bad to just create the plugings for that. There could be another exported function which returns just this information in some struct.
hm, if there is a "new GS()" there has to be a "delete" somewhere... to not mix memory managgers, only the dll can delete it.
If it was reference counted it could deallocate itself in the last Release call, but I think now we need to resort to another exported function just to do that.
Hrm, if it were doable then best way to do that is to literally make an entirely separate header file that's MSVC/C++ specific. But I don't think it'll fly.
For one, it's a compiler error to use virtual functions or inheritance with struct types, so the IPluginGS will need to be classed. But regardless, the plugin's derived implementation needs to be a full-blown class (minus novtable), and at that point MSVC is entirely welcome to take certain liberties with how it lays out the vftable in memory (since its entirely allowed to, by spec) ... which would result in pcsx2 invoking the wrong functions unintentionally.
Furthermore, the vftable is usually not even stored as part of the class. I noticed for example in my new IOP work that MSVC constructed a single static version of the vftable for my InstructionOptimizer class, and most instance code referenced it directly (it's a good optimization since it eliminates a large chunk of memory and initialization overhead associated with classes with lots of virtuals). Other instance code that used the Instruction base class dereferenced the single vftable* at the head of the class. But this storage behavior can change from class to class, and most certainly has changed between versions of the compilers.
All of this still applies even with 'novtable' since that's only eliminating vtable overhead for the base classes -- the code still relies on there being a vtable generated for the plugin's derived implementations.
So yeah, it *might* work, but if it works at all, it would be working by the graces of the compiler deciding to adhere to the programmer's specific function order specification, and it not deciding to optimize the vftable to a static table outside the context of the structure itself. I don't think it's a good idea to encourage that sort of rules-breaking in a plugin spec. :/
Well, believe it or not, every COM interface is defined this way and it works.
MSVC compiled code could use the class def with virtual functions, others (pcsx2 or plugins in c) the struct with function pointers, whcih is no different from the already suggested structures.
Just a random interface from dx10:
extern RPC_IF_HANDLE __MIDL_itf_d3d10_0000_0000_v0_0_c_ifspec;
extern RPC_IF_HANDLE __MIDL_itf_d3d10_0000_0000_v0_0_s_ifspec;
#ifndef __ID3D10DeviceChild_INTERFACE_DEFINED__
#define __ID3D10DeviceChild_INTERFACE_DEFINED__
/* interface ID3D10DeviceChild */
/* [unique][local][object][uuid] */
EXTERN_C const IID IID_ID3D10DeviceChild;
#if defined(__cplusplus) && !defined(CINTERFACE)
ID3D10DeviceChild : public IUnknown
virtual void STDMETHODCALLTYPE GetDevice(
/* [annotation] */
__out ID3D10Device **ppDevice) = 0;
#else /* C style interface */
typedef struct ID3D10DeviceChildVtbl
ID3D10DeviceChild * This,
/* [in] */ REFIID riid,
/* [annotation][iid_is][out] */
__RPC__deref_out void **ppvObject);
ID3D10DeviceChild * This);
ID3D10DeviceChild * This);
void ( STDMETHODCALLTYPE *GetDevice )(
ID3D10DeviceChild * This,
/* [annotation] */
__out ID3D10Device **ppDevice);
} ID3D10DeviceChildVtbl;
interface ID3D10DeviceChild
CONST_VTBL struct ID3D10DeviceChildVtbl *lpVtbl;
#define ID3D10DeviceChild_QueryInterface(This,riid,ppvObject) \
( (This)->lpVtbl -> QueryInterface(This,riid,ppvObject) )
#define ID3D10DeviceChild_AddRef(This) \
( (This)->lpVtbl -> AddRef(This) )
#define ID3D10DeviceChild_Release(This) \
( (This)->lpVtbl -> Release(This) )
#define ID3D10DeviceChild_GetDevice(This,ppDevice) \
( (This)->lpVtbl -> GetDevice(This,ppDevice) )
#endif /* COBJMACROS */
#endif /* C style interface */
#endif /* __ID3D10DeviceChild_INTERFACE_DEFINED__ */
I have even seen mplayer using directshow filters under linux through the c-only structures.
well, there seems another level of indirection, the vtbl is a the first member of what CreatePlugin would return, allocated as a class, but it's basically the same.
ah, can't write again :P
Gabest: is it even WORTH doing that? seems like it would bloat the plugin interfaces way too much, just to make it "cross-compatible" with C++ objects... :/

Revision 1580

microVU: tweaked some regAlloc stuff; i think it should be faster.
anyone tested this ?
I benchmarked FFX intro:
2009-07-29 15:38:53 - pcsx2-r1580
Frames: 8290 - Time: 64654ms - Avg: 128.221 - Min: 100 - Max: 176
2009-07-29 15:36:04 - pcsx2-r1580
Frames: 8310 - Time: 62977ms - Avg: 131.953 - Min: 102 - Max: 179
mVU wins! But not by much but hey that's the first time I see faster speed with mVU I think.
Xenosaga runs faster with mVU now :)
FFX, FF12, Persona4 and DragonQuest8 all run slightly slower than with svu yet.
Still, this is the kinda speedup i was hoping for with regalloc. Nice job :)
Resident Evil 4 also runs like 2~3% faster for me with microVU than superVU now.
Comment by sunnydrake7
>> anyone tested this ?
>> http://developer.amd.com/cpu/Libraries/sseplus/Pages/default.aspx
Because PCSX2 is primarily working via dynamic recompiliation, that lib wouldn't be of too much benefit. It could benefit plugins like gsdx or spu2x though. Will have to look into it further later.

Revision 1581

More new plugin api work.

Revision 1582

wxgui: synced with trunk, and started work on an improved plugin initialization
procedure. (branch currently does NOT compile, sorry)
Sorry about the branch not compiling. My next commit won't b for 4-5 days, and hopefully I'll have everything sorted out by then.
oh nooo!!! the pain!!!!
how could you do this to us..... and I thought you were one of the good guys :P
though if you really beat yourself up about this "there there" as sheldon might say XD
not to be so negative but why commit if you know its broken compilation and your not going to be able to sort it for the next 4-5 days wont that stop other devs for fixing and updating things as they wont be able to commit there stuff for others to test and work on as nobody is going to be able to build the source?
steven: no other devs work on the wxgui branch, plus commits dont have to assure a working version if you know its going to be fixed soon, we can revert to an earlier revision if need be.
One big reason to commit a broken build is for backup purposes. You never know what could happen while you are away. It also lets others see where the current build is headed.
Anyway I don't believe anyone other than Air is working on the wxgui branch. The other devs can continue to work with the trunk.
arcum recently worked with this branch too.
>> not to be so negative but why commit if you know its broken compilation and your not going to be able to sort it for the next 4-5 days wont that stop other devs for fixing and updating things as they wont be able to commit there stuff for others to test and work on as nobody is going to be able to build the source?
That's why it's a BRANCH.

Revision 1583

microVU: fixed a bug

Revision 1584

- Trippled the number of cached textures, many games constantly recreated them
- Don't clear some shaders at each drawcall (in dx10) , which is a nice speedup
(but could potentially be bad, please check..)
I`ll check DX10 mode asap and report how are the games after I get back from work. Thanx for the update :")
i noticed a speedup of around 5% in various games
the only game i have where the graphic card is the bottleneck is FFXII in the menus with the recent 8-bit texture option tuned on, and i didn't notice any improvement, but it didn't seem to break anything either
Wow, negative from ferrarinews! It's probably didn't fix GT4 again :p
It's ok,as long as he keeps spamming,the game doesn't get touched :)
Rama: What bugs could it cause? We really need to start concentrating on GSdx accuracy than keep adding speed changes that could increase the already large count of bugs :/
Any bug by this would be of the obvious kind. You'd spot it instantly :p
much slower in final fantasy x-2 drop about 8-10fps compare to r1571 (D3D internal res:1024x768)
I am interested what happened with Steambot Chronicles. I`ll test it asap and report.
Doing various tests with persona 3, 4, and FFX I'm not seeing any huge difference, Persona 3 and 4 I don't see anything at all, with FFX I'm seeing about 1-2% less usage of the CPU but the same frame rate. Haven't noticed a single thing broken though.
I did a variety of test on ffx-2, there was no difference in speed.
I'd need to know at what scene you get that slowdown though, maybe attach a .gs.
kojiknight: Yeah, this optimization is highly game specific. It helps xenosaga for example.
it mihen highroad scene
It'd help if i saw something in that .gs :p
Anyway, the GSdx framecounter is working, and it says 86fps with this mod, and 81fps without this mod.
Can you tell me:
- Your vga card name
- Your cpu name and clockspeed
- If you run in dx9 or dx10
Report: Steambot Chronicles still crashes PCSX emu.
Other games have better graphical fixes of some glitches. Speed in Tekken5 is decreased by 2-3 fps in some terrains.
Ok, I get it Steambot is broken. Please don't turn this into another gt4.. :p
:) Nope, just reporting, rare issues, otherwies everything is fine. Some EFX are better in games like VP2 and Tekken 4,5 and TAG. However I am not using any speedhacks. I am reporting Steambot because it`s the GSDX that makes the emu crashing - the 1474 rev was OK, not that I will switch to it - just gave a report :) Hope it`s useful.
We'll look at it sooner or later. Sooner if you can provide a dump or .gs file that shows the bug ;)
i use 8600GT 256MB GDDR3, E2180, Dx9. maybe this happen only with weak vga card (i know mine is weak but it runs faster with older gsdx rev)
Well, this spot obviously stresses something in GSdx, and either your cpu, the vga card, or the dx9 api cause that slowdown (My guess is its dx9).
My guess would be a lack of video memory. It was mentioned before, that the games that use a lot of textures (like Xenosaga) requires a lot of video memory (512+) and raising cache size could move requirements even further.
I was reinstalling my system, on windows 7 now :P
The texture limit could be much more sophisticated, 300 or 600 does not matter, most games are below the limit, but when a game like xenosaga runs out of vram (256MB is not enough for that game) it is no longer fun, let it be using 100 or 1000 textures.
Instead, the real amount of vram should be the upper limit, but ever since agp it became virtual and hard to figure out. I think dx7 was the last one that could tell the real psychical vram size.
This "virtualization" works better with dx9 where each texture has a copy in system memory and could be swapped in fast, but with dx10 to make room for a new texture another must be read back and saved, which is very slow.
About not clearing shader resources. Then the debug runtime complains and manually unbinds them, I don't know how harmful that is or is going to be in the future.
@ gabest11
Very well spoken lecture! Thank you for the detailed explanation.
Ok, I was doing a thorough check on the shader resource clear, to see if any game had any issue with it.
Since that wasn't the case, I figured we should take that speedup.

Revision 1585

Saw that SSE4.1 has ptest, and I wanted to try it out xD
untested though cuz I don't have an SSE4.1 cpu :)
compile error -
ix86_legacy_sse.obj : error LNK2001: "class x86Emitter::Internal::SimdImpl_DestRegSSE<102,5944> const x86Emitter::xPTEST" ([email protected]@@[email protected][email protected][email protected]@[email protected]@B)
fixed in my other commit.
its odd that i didn't get the link error...
How do you test? It doesn't crash until I try to close pcsx2...
The crash at closing pcsx2 can't be from this.
Rama already tested this for me, and it appears to be working correctly.
If it wasn't correct it would break pretty much every game or crash in-game :p
Ah, well it just makes games faster, so good call. :)

Revision 1586

minor fix for broken compiling

Revision 1587

Some cleanup around iCore.
I turned some defines into inline functions, and made sure that it wasn't checking if u32s were >=0 in them, and made sure the functions were being used, since there were a bunch of places where if statements equivalent to the defines were being used instead of the defines.
I spotted a discrepancy that might be a bug, but I'll leave it till I'm sure which behavior is correct...
And, yes, they are still called by defines to my new functions for the moment, since I didn't feel like lots of search and replace, and I might change the names a bit to look nicer...

Revision 1588

Stub out some functions in the cache code.
This is just mainly because I'd rather have broken (ifdeffed out) code in the trunk then uncompilable broken code in the trunk(again, ifdeffed out)...
Nice work all around, just a small request :p
Please consider that jake has a lot to merge already each time he updates the wxwidget branch.
So since he's away right now, the more we update pcsx2, the more he'll have to merge.
So best keep it simple is all I'm saying :p
I should add that Jake plans to merge the wx branch into trunk soon.
His goal is sometime next week if time allows him to.
I'll keep it in mind. Sounds like a good time to work on plugins, since they should be the same between the wx branch and the main trunk. and there are a couple other things I have to take care of anyways.
I'd been meaning to look more at what Jake had done with the wx port recently, since it seemed like it was getting close. Just hadn't a time recently where it would compile on Linux...
Alright, good luck then with the plugins.
I'm also having "fun" currently with that :p

Revision 1589

microVU: Optimizations, cleanup, and fixed a bug...
Latest build gives me 200+ new warnings all "c4800: 'int' forcing value to bool 'true' or 'false' (performance warning)
Program still compiles, but it immediately crashes when you try to load a game or start the bios.
what compiler are you using?
msvc isn't giving me any warnings.
also can you tell me some of the line numbers where these warnings are happening.
if its talking about stuff like:
if (someInt) { doSomething(); }
then yeh i've been doing that stuff since the beginning of mVU.
what the...it's traditional C/C++..
force 'int' value to bool is not a warning, lol.
it should be because of compiling with Warning level 3

Revision 1590

microVU: more optimizations
I am getting this error on the console when trying to run this revision:
First try failed allocating Micro VU1 at address 0x5f240000
But the PCSX2 itself continues working (didn't tested actual run, don't have bios dump atm).
works fine for me, no weird errors
Comment by nstorm0.0, Today (3 hours ago)
I am getting this error on the console when trying to run this revision:
First try failed allocating Micro VU1 at address 0x5f240000
But the PCSX2 itself continues working (didn't tested actual run, don't have bios dump atm).
This isn't an error you should care about. It's normal that it happens, and depends a lot on your system configuration (drivers and devices connected), and also by chance (address space randomization in vista).
As long as it continues working and doesn't fail to allocate it, its fine.
I see, thanks gigaherz for you comments.
Btw I've tested under XP Pro SP2. But I couldn't disagree - as long as it works, it's fine.

Revision 1591

GSdx: little code cleanup
Well what ever was causing the no output on the gma 950 is fixed with the clean up :D
no edit X|
but just read through, and saw the software vertex shader
nice job!
if(hh < 512 && m_renderer->m_context->SCISSOR.SCAY1 == 511) // vp2
^ Great :p
Also I see you have that PSSetShaderResources call in again. Somehow this doesn't slow down the build for me. Cool :p
Btw, try this here in Create() as a swapchain flag. It's interresting :p
Checked with the debug runtime and calling it only at the end of StretchRect was enough, that's only called a couple of times per frame.
But preventing any kind of optimizations doesn't sound good :P
Heh. It looks like previous glitch with thin lines developed to the new level: http://img229.imageshack.us/img229/9647/glitch4.png (Persona 4) >.<
GS, if needed: http://www.mediafire.com/file/wjz42zmlitk/gsdx_20090801133420.rar
It's the same for P3. Seems like they are using same engine.
Again, the gs is incomplete in two frames, only the battle scene and the shadows are there :P
Tried it myself and it doesn't look that bad.
Hmm.. it seems impossible to save dynamic scenes from this game in gs. x_X
Don't know what to think now. Maybe it's somehow related to my graphics driver or such
it is possible, I dumped those from a gs, just don't use any speed hacks
All right here is the .gs with all speed hacks disabled:
no idea :P
The last working build:
1426 - with no graphical garbage;
1469 - with no strange lines.
I'm pretty sure this is a case of odd multiples of the native res.
Try setting the D3D internal res to exactly *4 of the native res (typically 2560 * 1792, but check the GSdx window).
This odd rounding causes too many glitches, in other games as well.
We really need a more fixed scaler (like scale * 2 and scale * 4), at least as an option.
OMG. I found out that if I uncheck "Allow 8-bit textures" box the problem with lines solved itself.
And about resolution - maybe it'll be better to add multiplier of native resolution instead of custom dimensions?
Most people won't know in life what is D3D internal resolution is and many forums recommend to set it as you said to *2 or *4 of native. Why not to simplify the task for most of the users?
For example as shown on the picture: http://img228.imageshack.us/img228/541/resmul.png
Lol, nice job on that montage :p
But yeah, this is what I meant essentially.
There's the problem of the ressources this needs though.
X2 is 1280 * 896 which is fine. Next step (x4) is 2560 * 1792 already though.
That's about the point my card beginns to struggly. X8 is out of the question :p
But on the other hand it fixes oh so many glitches, so its really worth it imo.
then why not like this:
should work for most people I guess .25 steps would work as well
... and how do you express the lcd-native fullscreen resultion like 1680x1050 with multipliers? :P
see your point gabest but, it would be nice to have a multiplier option for those games that have different native resolutions. that way we wouldn't have to change the resolution just to have a 1:1 x2 resolution output. some of my games are 512x512, 640x448, and 640x480. i know i don't have too but, i always change the native resolution to a multiple of the original and with a 2x option we wouldn't have to change it for games that have different natives. you're doing great work as it is though, so keep it up. :)
Comment by gabest11, Today (47 minutes ago)
... and how do you express the lcd-native fullscreen resultion like 1680x1050 with multipliers? :P
there is no difference in quality between the internal resolutions when it comes to LCDs at least with DX10 and DX11 not tested in DX9
also it doesn't matter if you have the same resolution you use for your desktop (at least I have never seen one Oo)
Yeah, output res is totally irrelevant. What matters is that non power of 2 scalers do shift the textures a tiny bit. Leading to glitches like this:
Admittedly, fixing the scalers to powers of 2 just fixes half the glitches, but its better than nothing ;)
Been having some problem with this revision, some games output "Gsdx: m_merge is NULL!" which they didnt before and in some games right after this PCSX2 crashes if I have any interlacing mode enabled and native mode not enabled.
So far just got 3 games that do this which I kept in HDD and cant test more cause i'm not home, but anyway Megaman X8, Gradius V and Bleach: Blade Battlers crash.
In regard of the 2x 4x native res discusion, you could just add a default dropdown menu for native, 2x and 4x for example and instead of a "native" checkbox make it a "custom" checkbox that would change the d3d int res option into the one we have now for those who want it that way.
In my case with just 512x512 games 2x is not enough quality while 4x is too much which is why I like using 1536x1536 instead.
Or like the one we have right now being greyed until you check "custom" that would enable the custom box and grey the "native/2x/4x" one in my example.
nice idea shadow lady O_o
and yo my gradius V crashes too with interlacing and custom res
Hmm, you need to have a interlace mode set in the options for it to crash.
Took me a while to figure that out :p
Oh yeah forgot to say that in firsr comment and I was gonna say it next but forgot, my bad xD
blame no edit button :x
that revision brings back the old and famous "ghost bug", from tales of abyss :/
thumbs down, unfortunely.
(both with 1440x900 of internal res)
Maybe it's even better to use edit box with real numbers (1 up to 8 with 0.5/0.1 step) instead of dropdown list with multipliers? All better than calculating resolution by yourself. >.<
using: pcsx2-r1593 all hacks off, mvu disabled(and enabled).
I'm getting the "m_merge is NULL" crash in vp2 w/ gsdx-r1591(dx9 hw)
but not with r1584(also dx9 hw).
As a guy said earlier - there's a problem with games crashing when interlacing is on while using a non-native resolution - Resident Evil Code Veronica X can't boot under these circumstances.
I never boot games through the bios and they all still work, but I'll check.
Yes some games crash with interlacing enabled on high native res (ex Popcap Games Vol 2 says m_merge is NULL and crashes). Also Naruto Accel 2 has a line at the bottom of the screen where it looks different and the ghosting effect is more visible now. I use 2048x1792 internal res.
Some screenies:
All revs after this one have this problem (this one included).

Revision 1592

pcsx2: removed some msvc++ warnings from one of arcum42's cleanups
microVU: minor fixes.
The ps2's VUs (and FPU) pretty much always do sqrt(abs(x)) whenever doing
SSE's sqrt will give you a NaN if x is negative instead, so force abs(x) before
doing sqrt (unless the value is known to be positive).
Interesting thing is that while gcc may have lots of silly warnings that crop up, it doesn't seem to give warnings that require !!'s. As such, I'm not likely to notice when they're needed, unfortunately... :(
yeah this is one of the cases msvc++ has given silly warnings that gcc was fine with lol
it was saying "performance warning", but it spammed it like 100 times for some reason xD
anyways it was fixed by just !!'ing the int expressions to convert to bool.
Ironically, the cleanup started because I was getting tired of warnings gcc gives about doing (x >= 0) on unsigned variables all over that section.
I'll admit I'm still wondering about MMX_IS_GPR, tohugh.
MMX_IS_GPR was ((x >= MMX_GPR) && (x < MMX_GPR + 34).
In line 780 of iCore-32.cpp, which otherwise used IS_GPR, it used (mmxregs[mmxreg].reg >= MMX_GPR && mmxregs[mmxreg].reg < MMX_GPR+32)
This is *probably* supposed to be IS_GPR(mmxregs[mmxreg].reg), but I'm not sure if the 32 or the 34 is correct.
It's one of these cases where I just decided to leave that case the way it was, till I get a better handle on it. (though I adjusted it to remove the unneccessary check...)
And, yeah, my spelling sucks in this comment. An edit button would be so useful... :)

Revision 1593

KiNGKiMO noticed a crash when specifying a iso filename in the cmdline, to make
pcsx2 auto-boot that file. I fixed that, and while I was at it, change the
bootmodes around.
The way it works now is:
- Base mode: 0=normal (cdvd plugin), 1=load elf, 2=use iso loader, 3=emulate no
- Bios flag: 65536+base = mode startup through bios boot process. Default is to
skip bios.
So for example to load X.iso using the internal iso loader, and executing
through the bios, you would now do: pcsx2.exe -bootmode 65538 X.iso
This needs implementing in linux side, and maybe changing it so it's nicer user-
wise (for example, reading the number as HEX would make it 10002 instead of
BTW am I the only one with the process remaining in memory after closing program window sometimes?
Are you sure you're closing it correctly? (IE: not just the gsdx window ;) )
Good work, giga :p
Yep. I am closing just the program even before loading GS.
There are no graphical window already but process still remains and eat up to 50% of first core time. It happens around on time in 3-5 program runs.
Yeah, and it doesn't happen to anyone else it seems.. :p
I am the Chosen One. ^___^"
Saw it. There is a huge frame skipping and the window cuts the game with black bar. Happened when I forgot MAKARON EMU opened. Noticed that VP2 is terribly skippy and ingame was lagged with that weird glitch of - half of the visible screen was cut and the other half was black. When I closed MAKARON it fixed PCSX2.
Good job!
er I have it too XD
but I am apperantly the only one who has the problem with the configuration data (the program "forgets" folder locations but remembers them If I start a new pcsx2 instance)
if I close pcsx2 I can still see it in the task manager and it uses 25% cpu exactly I have a quadcore AMD so it's one whole core
damn you google for not having an edit button!!!
it appeared a while ago (prolly with the folder forget thing together) but I thought it was my problem cause on my brothers pc there is no such problem -.-
hahah :")
OK. Submitted this as issue.
Ok, good :p
I used rev 1593 but it still impossible swap / change xenosaga episode III discs. There only logo appear where Shion ask you switch to Disk 2.No matter how you tryed logo still present and disc 2 does not boot. Same in different way when you start new game with disk 2 Shion appear and ask you swith to Disk 1, then i change disk 2 to disk 1 and nothing happen, logo still present and disk 1 does not boot.Same problem with Samurai Warriors 2 extreme legends then you try to transfer data from Samurai Warriors 2 Disc. It says "Data will be imported from the Samurai Warriors 2 disc.Proceed?", then you press yes there logo appear " Please open disc tray". I change SW2 xtreme legends disc to sw2 disc and nothig happen, data does not transfered and it seems that game freeze as it was in xenosaga episode III.
Don't these games offer to do a save before the "change disc screen"?
Do that save, mount disc2, and load the save from its menu.
Should let you continue then.
I know about it but i thought that swap discs may possible.
It should be possible, and in fact it works with some games. One way it might work, would be to escape from the game, choose File->Run BIOS, then let it emulate "no disc" for a few seconds, escape again, and load the new disc. But if the game needs to "think" the tray is open, then maybe the best option is to use cdvdGigaherz, which does emulate having the tray open when the drive reports access errors (when you have no disc, or the tray is open).
Still, not all of the CDVD drive commands are known, specially not all the commands in the security chip (mechacon) so it is possible games are requesting info about the drive's state in unknown ways.
This is KiNGKiMO, thank you so much gigaherz for the fix.. this is REALLY USEFUL.
I want to report 1 more thing regarding this too, I'm using "Esc Hack - Use Esc key to fully exit PCSX2." at Speed Hacks.. this isnt working with the fix, Pressing Esc Key doesnt close PCSX2 right away.
Hm nothing I changed should have affected it, kimo :/ With the wx branch so close to merging, I think it's not worth to waste time fixing that, given it will be useless later.

Revision 1594

Add the changes from r1593 to Linux.

Revision 1595

* finished most of the new plugin system (branch is buildable and runnable
again, but no significant functionality has been added yet).
* Removed STGS code from the branch since I planned to kill it off anyway and
it was more work to code proper support for it in wx than to remove it.
Haha, sneaky way to get rid of stgs.
Welcome back :p
The MTGS will have a new synchronous mode, which will behave *almost* like the current STGS, except all GS activity will still pass through the MTGS ringbuffer. The mode will probably only be available in debug/devel builds since its only purpose will be for debugging stuff.
oops, haha. I noticed I made search/replace changes to Changelog.txt. I'll need to revert that. :p
So with the new MTGS synch mode, will it affect frame skipping to be less
Yes, I have good plans in store for frameskipping.

Revision 1596

Zeropad/Win32: Make what appears to be a fairly significant bugfix, for what
it's worth.
Anyone even use this thing in windows anymore? Eh, whatever.. :p
One or two, I think. Just enough to bug me when I make changes to it. I personally haven't seen it actually work in Windows since pre-0.9.4, IIRC, though.
In Linux, in the long term, I'll probably replace it with my Zeropad fork. Still have to re-port that to Windows one of these days.
No one uses this plugin in windows. There's no reason to, and all the alternatives are better.
Well if it hasn't worked, this bug might explain why. It looks to be important code and it was basically passing some uninitialized pointer to a Win32 API, so god knows what was happening as a result (likely a GPF).
anyways if it really doesn't work at all then I should prolly consider removing it from the pcsx2 solution and reducing plugin clutter.
It works well enough in Linux, but, yeah, in Windows, I'd get rid of it. I get the feeling that Zero did a bunch of work on the Linux side, and never got around to fixing the Linux side back up afterwords.
And on the Linux side, hopefully my fork will supplant it eventually, when it's mature...

Revision 1597

GSdx: experimenting with msaa, add msaa=N to gsdx.ini to activate it (N=2,4,8)
It works :)
Some games take a huge speed hit, while not even looking better.
But some games got enhanced a LOT, and speed is the same :)
yays, AA via gsdx itself! Bored of driver settings :P
Oh god, AA in gsdx!
great AA in gsdx, but when i tryed run Suikoden III whitout msaa black screen
yea something is wrong with dx9
Any other N-numbers or just 2,4,8?
You can try any number :P dx9 up to 16, dx10/11 up to 32.
If I enumerate the modes only 2, 4 and 8 are supported on my 8600gt.
If you give an unsupported sample count the next highest will be selected automatically.
So it's up to my card and supported api, thanks
I haven't tried this yet, but... the AA (at least set at 2) has no negative effect on the perfomance? It runs as fast as it were set to 0?
It should have performace lost, compare to native res. But compare to a high internal res, I think AA will perform better
Performs better in GOW 2 without the side effects of non-native resolution (i.e. ghosting). Very good work. We only need a hotkey to change and it would be perfect :)
Thank you! This is one of the last two 'changes' that I've been doing in my custom build.
Works great!
To be more specific with 'works great'-- playing Kingdom Hearts 2 at internal 1440x1080 w/ 4xAA on a 275GTX. No stutters now on very high-video demand sections whereas previously 2880x2160 would hiccup a bit when there was a lot to process in a cut-scene.
Using msaa with any value (except 0) the ghost effect from tales of abyss is gone!
great job :)
It looks not like true solution to the problem but it somehow works. So my gratitude to gabest also. :)
But in the tales of abyss I have one more problem:
Corresponding gs:
Ghosting one:
Corresponding gs:
PS: I tried to disable all speed-hacks this time. Even before making snapshot, because this game is truly capricious with them. Even a little acceleration cause all kinds of "Trap" and "TLB miss" errors.
really? 1.5X works fine I played it through with that also every speed hack in the middle section most of em are fine with almost any game Oo and they all work perfectly fine with ToA
the ghosting problem was never fixed was it? but msaa is a NICE workaround XD especially for me since I almost only play on native res XD I like the ps2 feeling it gives with msaa it's just smoother XD
Yeah. The middle section speedhacks almost certainly make the game unstable for me because of crashing after battles on random occasions.
That's great, but I hope it will be supported through gsdx interface.
Having to edit an ini file, is not convenient.
And some irrelevant question to gabest - is Visual Studio 2010 really worth to try?
guessous: It was only try-out stage I seriously doubt that it'll be left as is if no critical problems occurs.
i talked too soon... msaa only fixes ghost effect under certain circumstances. when you change the screen (opening a menu or going elsewhere) the ghost effect comes back.
i'll try to reach gabest on forums.

Revision 1598

GSdx: fixed dx9 + msaa=0

Revision 1599

- Normal Clamp Mode clamps a few more stuff (Fixes Ice Age 3 falling through
floor bug)

Revision 1600

GSdx: fixed the crash when booting through the bios

Revision 1601

memcpy on PcsxConfig made pcsx2 crash upon exiting, when the string members were
deallocated, I guess they were added later.
Oops, yeah that would have been my fault for adding strings. Tho admittedly it's a surprise why it ever used memcpy instead of a direct assignment in the first place... >_<
It's the case of killing two birds with one stone - you can close Issue 343 and probably Issue 341 . ^_^
Yeah, annoying crashes are fixed.
Thank you gabest this was really annoying.

Revision 1602

wxgui: separated core emulation options from user interface options (mostly!
some interdependencies remain), and stripped out some of the old framelimiting
toggle/cycle code, which will be replaced with a better framelimiter system
... I wonder why my commits from my laptop put a bunch of extra linefeeds into the commit log. >_<

Revision 1603

wxgui: minor cleanups; renamed Utilities folder to Tools, to alleviate confusion
with the Common/Utilities.

Revision 1604

wxgui: maintenance sync with trunk.
Gone for another 5 days. Man I hope I have some serious progress made when I get back. Depends on if the weather co-operates or not.
have a good time :)

Revision 1605

microVU: some optimizations...

Revision 1606

microVU: Removed the "Exiting from Possible Infinite Loop" logic from Release
builds, should be a small speedup.
Its still there in debug/devel builds, so we can easily tell if a game is
hanging on VU1.
It seems good.
But I believe if there are more of such optimizations it's better to group them with setting in the .ini file, DisableSafeChecks=0(1) or such for example. So users can restore the functionality if it's really needed but still able to disable it if not.
well really this check shouldn't be needed if the recs are working properly (unless a game does something really weird).
i mostly just coded it for myself to find problematic games, and i originally included it in the release builds so normal users can report to me the problems.
at this point there are still a few games that get stuck in infinite loops, but i think its because i still need to implement a few stuff.
I don't want to be like, you know, 'GT4' but you broke Champions RTA again.
But as long as my ps2 works, i can wait :)
i know champions rta is broken, but it wasn't working correctly anyways.
i have a real fix planned eventually but the game is doing some very ugly stuff thats hard to emulate ><

Revision 1607

LilyPad: A number of small fixups.
DirectInput devices corresponding XInput devices should be listed as
"[Detached]" when XInput is enabled. No idea if this works, as it requires an
XBox 360 controller to fully test.
FF Axes now sorted, rather than being displayed in the order MS returns them.
Small motor DirectInput binding now correctly displays "Square" effect type in
list when first created.
Attempt to more accurately model "soft" vs "hard" presses. Don't have a game
where this matters, so no idea if it works.
"Attempt to more accurately model "soft" vs "hard" presses. Don't have a game where this matters, so no idea if it works."
soccer games like winning eleven/pro evolution soccer use this, thanks for this add-on mattmenke.
Oi, would it be possbile for some ps2-like pads(f.e logitech rumblepad 2) to auto configure according to the orginal ps2 pad, just like dolphin does.
Rude to start a question with oi
I have an x360 controller. Tell me what you're looking for specifically and I might be able to help.
Also, I know this isn't a support forum, but maybe you could provide an insight on what motor to use with the 360 controlller, and how many of them. Thanks.
NorikumiSubs: When you have DirectInput and XInput both enabled, either the DirectInput device corresponding to the XBox 360 controller should disappear or you should see "[Detached]" before the name of the DirectInput device.
As for which is big and which is small, the first is the "left" motor, second is the "right" one. I believe left (first) should be set to big. Default motor setting when you create the FF bindings should be right for XInput, but if they're not, tell me, and I'll change them.
Here's how it appears for me:
And here's a little something taken from MS's page: "The left motor is the low-frequency rumble motor. The right motor is the high-frequency rumble motor."
Turning the Axis motors on/off seems to have the same effect with both big and small. By default, big motor is set to Axis 1: Slow, and small motor is set to Axis 2: Fast.
One problem i'm encountering in Persona 4 is that the UP and RIGHT axes of the left stick are somewhat limited, and the character is moving at slow speed. This may be because of either usage (though i've bought it a month ago) or calibration, but increasing the sensitivity manually yields proper behaviour (full speed movement of the character).
I don't know if the right stick has the same issues or not. (By the way, the 360 sticks and L2/R2 triggers have a 0-65535 range of sensitivity. This might be a problem since the sticks are extra sensitive, screwing up the MAX value.)
Oh and, to reply to this "Attempt to more accurately model "soft" vs "hard" presses. Don't have a game
where this matters, so no idea if it works." you could always use MGS2 for testing, because i remember it annoyed me when i played it on my PS2. If I recall correctly, the PS2 controller has 255 levels of sensitivity for the buttons.
Oh, and gawmir7: Without a bunch of devices to test, I have no idea how common button numbering is, so I have absolutely no idea.
On one other thing. Disabling the DirectInput in the General tab removes my x360 controller from the list, leaving me with 22 bindings. Removing XInput removes "XInput Pad 0" and leaves me with 4 bindings.
NorikumiSubs: That's right...Slow/low frequency generally gives the bigger vibration, at least with my PS2 and RumblePad 2 controllers.
A lot of people have sensitivity issues with LilyPad and the XBox 360 controller. I suspect the controllers themselves are calibrated in a dramatically different way from PS2 and PC controllers, and also never/rarely return certain axes as fully down. Without my own Xbox controller, I can't really play with the calibration myself. Anybody with a controller and the necessary knowledge is welcome to play with it. All that matters is the two line function that matters is just "ShortToAxis(int v)" near the top of XInput.cpp. Current version uses no branches and all integer code to adjust the range from -32768 to 32767 to exactly match the range -65536 to 65536 (Adds 1 if above 2^14, and then doubles regardless. Sticking with all integer code doesn't really matter, as code is only called a couple hundred times a second or less). Larger/smaller values are allowed, so something as simple as just scaling might be fine, or might want to use some other function (Like * sqrt(abs(original value)/32767.0) or something).
I don't have MGS2. Tried the first one, wasn't impressed, never bothered to try the others. Also a bit of a pain, as it requires a pressure-sensitive source of input to work. Don't do anything fancy with standard buttons.
Thanks for the info on XBox 360 DirectInput controller behavior - that's exactly how things should be (Well, not sure about the binding counts, but removing the devices from the list is correct).
Having DirectInput on and XInput off leaves me with this:
Clearing and binding all buttons/sticks again works, but the sticks are so sensitive that they often rewrite themselves when I try to set the axes by moving them.
BUT with only XInput on, I CANNOT add Big/Small motors, as the buttons are greyed out.
D'oh i blame the lack of an edit button. i mean that with XInput OFF i cannot add motors.
That's because Microsoft's crippled DirectInput drivers for XBox 360 controllers don't support rumble, in an attempt to force developers to use XInput. For XBox controllers, you should probably be using XInput rather than DirectInput.
I think XInput is really nice except for the limitations...
and way more customer friendly the only really bad part is that atm only XBoX 360 controller are supported ... which is stupid cause they have the worst D-Pad since the original XBoX controller (oversensitive and not precise enough -.-)
That's a huge limitation, and makes the entire thing useless on PC.
Fine for XBox-exclusive games, but for PC, just makes things even more complicated, as you now have to use *both* APIs if you want rumble on XBox 360 controllers and want to support general purpose USB devices.
One other thing about the Xbox sensitivity: You could try going to the diagnostics screen and see what values you get when it's fully pressed.
the only pressure-sensitive buttons on the 360 are L2 and R2. the D-pad does suck though.
@mattmenke yeah the problem is that so little gamepads actually feature XInput if only XBOX pads are usable then it's kind of pointless...
btw since XInput has the same binding for every controller (don't really know how to express myself there) why not make a "bind XInput controller button" since that is one of the actual improvements over direct input (or so at least I think^^)
Too much effort. Might be tempted to spend time on it if I had one, but as it is, writing code which I can't run, or can only run after writing code to emulate a device I don't have, is painful.

Revision 1608

Worked for a bit on parseCommandLine in Elfheader.cpp.
Basically, I added a bunch of comments, since I was working out how that function works with a mind towards rewriting it, pulled a commonly used conditional into a function, and likely fixed a bug or two.
Main one would be that it looked like it was starting out further then it should have when looping. At the very least, Champions: Return to Arms seems to have been picking up an erroneous argument from that, though I don't think it affected anything...

Revision 1609

After thinking about it, I'm reverting one of the changes I made in r1608 for
the moment, though I may rewrite the whole function in the future...
It does subtract strlen(p) + 1 from args_ptr earlier, so I'm sure that's why it's in there. I hadn't noticed that previously...

Revision 1610

Here's a better bug fix for the issue that was bugging me in r1608.
After r1609, I just suddenly realised that it was absolutely futile to be scanning over a whole bunch of space we already set to 0's anyways... :)

Revision 1611

GSdx: fix for transparent walls in kingdom hearts (or anything else that sets
AA1 with ABE off)
anything that fixes kingdom hearts is awesome.
LOL... I`ve played KH2 and KH COM a lot... haven`t noticed any bugs... with even 9xx revisions... and if I recall right even ot GSDX 875....
It was a newly added bug :P
Hmm, could you code this missing part Gabest?
//otherwise scale.x need to be reduced to make the larger texture fit (TODO)
I'm not quite sure if that's all that's needed, but some hacks showed improvement for these glitches in xenosaga3 or valkyrie profile 2.
(The brightening effect in xs3 and the fog in the forest in vp2)
It'd help if at least the bad texture size problem was out of the world :p
I've only seen street fighter ex using that part, and even that is skipped because it is basically a blurring effect and not needed.
The real solution for such reinterpreted render targets (base address, pitch, pixel format may change) could be a similar page/block tracking system as the texture cache uses.
I just found out that at least vp2 doesn't even want to update the render target.
It looks like it's trying to update the depth stencil?
That part is labeled "Todo" right now :p
Ok, here's a .gs of "Tales of Crashia". The game got its name because it used to stall a pc to the point only a reset could fix it.
It's better nowadays, but still a memory hog. It also shows the bug I'm talking about nicely :p
I have 2 problems with plugins since the beginning. One is missing parts of models especially in parts of ass :) )in db budokai tenkachi 3, and second is gray stripes (this is artifacts loking like the shadows) in the lotr third age. I see that performance is improved once again, and rest working near the perfect. One bug is that god of war loks crappy on non native res (when native res is disabled the main character is blurry and doubled). Kingdom hearts 2 looks and working avesome even in higher resolutions.
Sweet. I'm really impressed at how quickly that KH bug I reported was fixed. Nice work. ;)

Revision 1612

A few minor modifications to CDVD and IPU.
In CDVD, I changed it to explicitly put together the seek to sector and number of sectors from the parameters, rather then the ugly way it was doing it.
I changed a few areas to use a for loop, to make things a bit cleaner.
And I added a FIFOfrom_clear function, and have ipuSoftReset using that function, rather then clearing all the fifo output variables itself.
I fail to see how casting a pointer (which all it does is an unaligned memory access) is "ugly", and how reading 4 bytes separately, shifting them, and or'ing them is any better.
Unless you pretend to make this code compilable on big-endian machines... which would be pointless anyhow.
yeh i also liked the old cdvd code better.
was easier to read IMO and faster :p
although i would have used u32 instead of uint/int for the casting xD
Eh, well, I probably just looked at it one too many times. I'd been trying to trace back the "Auron. Look!" crash...
If both of you prefer the old version of that code, I'll revert (and use u32s).

Revision 1613

Revert the changes to CDVD, and clean up the changes I made to ElfHeader.cpp,
getting rid of some extraneous commented out test code, and refining the
comments I left a bit.
Having comments explaining how the function worked was a good thing, but the ones I left were drowning out the actual code, so...
only 1 spam comment :D, I want to say that, recently, I don't see any of your comment ended with "though..." :P
I've been trying to cut back a bit on certain words I tend to overuse. And ellipses, too, but I use them so often, I have trouble trying to end a paragraph without them occasionally.
Silly, I know, but it's habit at this point.

Revision 1614

Workaround a problem with thread affinities.
Should fix some slowness issues, mainly on AMD cpus.
Note: I actually hated to change any code there, it was so tidy before :p
// (up to 25% faster on athlonx2, about 5% faster on core2)
In case there are those who don't look at the diff :p
25% faster on AMD X2? is that 100% sure?
will try because i have one since my E6700 broke...
"up to 25% faster" doesn't instantly mean "25% faster" .
also it seems linux is not affected :/
Linux never had that issue to begin with :p
d'oh so my phenom won't receive boosts...
oh by the way, what's up with that bug that uses 100% of the first core?
Huh, it was around the time I was thinking about what's wrong with thread affinities also. O_O
lol nevermind. i guess this fixed it.
NorikumiSubs: Believe it was deliberate, actually, on the theory that running pcsx2 on one core/cpu and the GS on the second would give better cache performance. For games that are CPU-limited, this would result in 100% usage of the first core, rather than semi-randomly switching pcsx2 between cores. For whatever reason, this hurt performance drastically with Athlon XPs and a little on Core 2s.
My explanation could be wrong. Haven't been keeping up with the project lately.
@mattmenke this is hitting also Core Duo and pentium D :-( On my core duo i dont remember game that won't be absorbing first core almost completle! 70-100% while second is on 2x - 60%.. this is waste of resources :-)
In theory, it's not. If you have two cores, and two threads, one needing 100% CPU time of one core, and the other 60% of a core, it shouldn't matter if you run the 100% one on one core and the 60% one on the other, or let the OS decide what to do with them, and have them as a whole take up about 80% time of both cores.
In fact, all else being equal, if they don't share L1 cache (Or L2 cache), having them run on separate cores should well be marginally faster, for caching reasons.
I could see why this would be a problem for HT chips, but surprised it hurt performance so much in general.
What if the OS puts other processes on the core that needs to run pcsx2 100%?
It could have run on the second core instead, but missed it, and now only gets "100% - X" of one single core.
gabest: Indeed, and Windows kernel itself only runs on the first core, or at least it used to. Regardless, as there was a 25% X2-specific slowdown, that doesn't seem to be the main problem.
before r1614, removing core 0 from affinity (and leaving cores 1, 2 and 3) didn't put 100% load on any of the other cores.
The Affinity change was implemented for CpuSpeed checking only. I coded it as according to MSDN docs and examples -- saving the current affinity when setting the new affinity, and then restoring once the CpuSpeed was calculated.
This apparently does not work on some AMDs though. So much for docs and examples. :p
Yeah, i saw that part but wasn't sure why it didn't work.
So I made another function to make sure it's unset.
Yeah according to the docs, just blindly setting an 0xffffffff mask is *supposed* to fail, and you're *supposed* to use some other function to query the valid affinity mask from Windows. But apparently AMD's cpu drivers don't bother with those rules and regulations :p
Thanks for AMD support :)

Revision 1615

microVU: extra + preserve sign clamp mode now semi-implemented (before it would
just do the same as 'normal' in mVU)
Fixed some missed geometry in mVU1 in Naruto Shippuuden Narutimate Accel 2
i've reported before, fixed not by this commit but , thanks anyway
still some little problems on MVU1 still reamains
@ Heatblazer: Why are you using google code comments to report GSdx bugs, even in totally unrelated revisions?? Make an issue or report it on the GSdx thread in the forums. This is considered spam and will be deleted in the future.
cottonvibes: Good job, will test SPS games with it. Any word on when you will fully implement it? I guess it will be smarter to wait till then to test it :P
its possible that this fixes some sps games, but yeh probably best to wait till i fully implement it.
i'll probably get to it sometime within 1~2 weeks when i'm bored xD
Happy Birthday Vibes Cotton !
heh thanks xD

Revision 1616

Fixes for ICC compilation errors ( Issue 350 )
I remembered for earlier revisions I can only compile ZeroGS with ICC(11.1.035), pcsx2.exe definitely cannot be compiled.
now all sorts of 18 projects except setup can all be compiled with latest version(11.1.038) of ICC?
I haven't tried it out, currently ICC removed from Windows.
I failed to compile GSDX with recent revisions. Gabest wrote on forums:
"intel's compiler produces horribly slow gsdx, icc<vc9<vc10 (when I last checked it, it could not optimize sse intrinsics very well, that could be to reason)"
I wonder how ICC will affect emulator performance, going to test tomorrow.
Compiled gsdx with icc about a month ago.
Tried compiling with ICC11, pcsx2 hangs with a black GS screen when starting any game or bios, without any error messages. Debug build worked though, maybe I did something wrong.
I succesfully compiled PCSX2 (but not plugins) with ICC11 and it runs bios just fine.
Well, for now I can compile with ICC11 all that I need except gsdx. All dependencies (SoundTouch, pthreads etc.), PCSX2 itself and SPU2-X.
And there is GREAT boost on performance.
Just for example: it allows to use quad-core CPU (not SO effective as manual parallelisation, but... better, than nothing).
And it gives more fps on 2 cores too (for Intel CPUs, at least; not sure about AMD).
I have no additional bugs with ICC-compiled builds.
>> And there is GREAT boost on performance.
How much great?
How did you test it? Which settings? Do you use native/simple gfx settings for best result?
Where do you test it? BIOS/Disgaea, lol? Try GoW2/Tekken5/FF12/GT4.
Provide some statistic.
"Great", of course, differs from man to man. :)
But just for example, God of War 2 (approximately, of course):
Default compile - 31-38 fps, 34fps for 70% of the time in first room (after you kill all enemies).
ICC compile - 33-42 fps, 39 fps for 70% of the time.
My settings a bit agressive:
But the same tendency with lower resolutions.

Revision 1617

vs2010 project files for pcsx2 (plugins later)
Yay, so we will entirely ditch VS2008(SP1) and stay with VS2010 beta 1 eventually right?
I'm looking forward to it.
hmm when that time comes it's probably not beta anymore Oo
That means I'll have to download the massive 500+MB Visual Studio 2010 redis package to be able to use PCSX2...well I won't be downloading that I'm affraid
Great, just great.
Not happy... :l
novax9: I doubt when the time comes you will need to get the 500mb package at all. The program is still in beta, so i imagine a lot of that contains updates and changes that are required that havent been released yet. For example there may be some beta .NET updates which have yet to be released by windows update.
Just wait instead of getting grumpy. Anyway, nobody said we were ditching VS2008 yet, only somebody who isnt part of the team and has no say in the matter.
so far the redistributable necessary to is 4.4mb, where did you get the 500mb from Oo
I can't compile GSdx with msvc2008 anymore!!11111oneonone
noez :O
We will only "discontinue" VS2008 support if/when VS2010 Express is released, at which point there would be a freely available compiler supporting the 2010 project files. Until such time, 2008 will be the compiler of choice for building the win32 projects.
Furthermore, when the wx branch is soon finished, people will be able to use Code::Blocks for Win32 if they so please, and compile pcsx2 with MSVC compilers from 2005, 2008, or (I think) mingw. Code::Blocks supports all of them.
(that won't apply to GSdx tho, for a while, since it still has about 2.5k lines of code that gcc considers invalid C++ :p)
I'm not familiar with gcc, but if it can use the libs from directx sdk then we could try fixing up those remaining incompatiblities.
Someone needs to guide me how to setup the environment :P
Any hope to get faster compilation times for pcsx2? About 20 minutes on the server where I do the auto-builds.
2010 can compile files parallel (not just independend projects), but with whole program optimization important things happen when linking, and that's still single threaded :(
Gabest: 80% of LTCG slowness is caused by microVU. The other 20% is the new emitter. In mVU it seems to be two or three specific parts of the code that give MSVC's linker so much grief. They're hard to fix though -- when I fixed the problem by limiting some of the inlining and templating it caused a 1-4% performance drop in many games.
I just tried vc2010 beta 1 and it blows. I'm not gonna use that POS for now.

Revision 1618

missing project files

Revision 1619

doh, so many missing files

Revision 1620

forgot to set function level linking..., that trims more unused code and dlls
deps, any good revision number ahead to reach? :D

Revision 1621

- Cleaned up microVU_Compile
- Added file microVU_Branch
when the pcsx2, may use 100% of the quad-core processors?
run it twice :D
i don't think PCSX2 will ever use 100% of 4 Cores.
you can be lucky when the VU's are splitable to two cores like:
core1:EE rec/IOP rec/SPU2 | Core2:VU0 rec | Core3:VU1 rec | Core4:GS
but is it worth or even possible to split up both VU's?
If you just add the following code to the right places, PCSX2 will always use 100% CPU time on quad core systems, even when you're just configuring plugins!
DWORD WINAPI Use100PercentCPUTTime(void *junk) {
for (int i=0;i<4;i++) CreateThread(0, 0, Use100PercentCPUTTime, 0, 0, 0);
you are doing it WRONG!
while(1) _mm_pause();

Revision 1622

Added some tag code in I was fiddling with. (Nothing uses it yet. I mainly
wanted a backup of what I was working on.)

Revision 1623

Link in Tags.h, use one of my new enums in various places, and move some code in
IPU.h to a new function of it's own.
If the code I'm modifying seems like a bunch of variations on the same code, there's a reason for that. And that's a lot of why I'm looking at it...

Revision 1624

* Major cleanups and improvements to the Threading namespace.
* Created CoreEmuThread class framework, which currently runs the EEcore, IOP,
and VUs with threadsafe suspension, reset, and resume features.

Revision 1625

A bunch of IPU.cpp now uses Tags.h. Ironed out a few things in Tags.h.
Hmmm... Noticed a silly mistake in here that makes no difference to the running of pcsx2. Some of my functions are misnamed. The only two times I used them, I was looking at the code and not the name, so didn't notice. :)

Revision 1626

Disable vsync when going from "limit" to "skip" framelimit mode.
doesn't GSdx use the display drivers own vsync or does it have an own vsync?
GSdx asks the driver to enable / disable vsync.

Revision 1627

Fix a silly mistake I made in naming functions in Tags.h.
Surprised I didn't catch this when I made the IPU changes, but it was pretty much the last ones I made.
Oh well, at least I was looking at the code, not the function names when making the changes. :)
Added some comments to Tags.h, too, so it's easy to tell what the different flags are for.
Using Visual Studio 2008 I post quite a few warnings from this change.
"warning C4800: 'u32' : forcing values to bool 'true' or 'false' (performance warning)"
I receive approximately 10 of these warnings the lines in question are 121, 126, 134, and 137 all are in Tags.h
The file still compiles fine, and I don't seem to have any noticable performance hits, I figured I'd report this either way.

Revision 1628

wxgui: Begin work on some missing panels for the pcsx2 config dialog.
i forget, wasnt someone on vacation, the person who did the wxgui stuff?
Hi Jake errors report
@maximu: thanks. Those errors are actually harmless, didn't know wx would report them. I'll see if I can't disable or avoid them somehow.

Revision 1629

microVU: minor changes

Revision 1630

microVU: Implemented some undocumented stuff which lets Champions Return to Arms
get in-game.
The game still looks ugly, I'm not sure if its problems are gsdx or pcsx2.
zeroGS just renders a black screen which it no help xD
Note: I still need to optimize this fix.
dont worry about return to arms: afaik the games related to everquest are ugly anyway. ;)
heh well, the game was doing some tricky stuff which i wanted to emulate properly.
This fix could help some other game work, but i don't think it'll help that much games (its a very rare case)
seems somewhere along the lines i've broken SO3.
not sure which revision, i'll be checking that soon.
k it was this revision that broke it ><
i'll be checking to see whats bugged.
If the problem is a split screen issue, then thats an issue that affects several games and not just Return to Arms. Baldurs Gate Dark Alliance and 2 are also affected by this same issue.
They are all affected by this, as they all use the Dark Alliance engine to my knowledge.
the split screen is fixed with SW rendering.
but there is in-game graphical corruption, most likely caused by vif, vu, or gs.
not sure which is responsible.
Yeah, same goes for the original "Champions of Norrath"...
Finally i had some time to compile and run it.
I would like to thank you for the awesome work you did :).
Champions are still not emulated?
What should I do, that would be comfortable playing together?
2 years are gone and this game still don´t work can someone look at this game

Revision 1631

microVU: minor cleanups
Thanks again Cotton, for your increddible work in this project !!!

Revision 1632

- Fixed a bug from r1630 (it was breaking SO3 and probably some other games)

Revision 1633

pcsx2: fixed some msvc++ compiler warnings

Revision 1634

* Removed some erroneous language error messages during first-time startup on
non-english systems.
* Cleaned up BIOS code a bit and moved all the scatterings from Memory.cpp,
Misc.cpp, etc. into a single BiosTools.cpp file.
* Implemented BIOS selector in the config dialog.
Nice job
Error Pcsx2 COnfiguration ussing option documents (Recomended) Can not enumerate files in directory \documents\pcsx2\bios
Folder Bios Not exist on the rute
Other minor error explication select on the configuration EE cyclerate and vu cycle not change descriptation .

Revision 1635

Re-enabled capturing via F12 key. It was missing the callback entirely.
The videos I capture here turn out all blueish though. No idea why :p
Seems to be confussing red and blue colors, otherwise it works again thank you :P
Yeah, as I said. I have no idea whats up with that :p
fixed :)
Remark: it would be nice if all shortcut used by pcsx2 were systematically
documented on a help file.
Also maybe an "api", or interface to handle all kind of shortcuts, would be interesting. This way the user could assign to each shortcut a function.
And if there's a conflict (for instance the esc key is used differently by plugins & pcsx2), then it could be easily managed.
My 0.05$
Yeah, it'd be nice to consolidate this stuff a bit more.
On the other hand, we all kinda know which keys are free and which aren't :p

Revision 1636

GSdx: Fix for the bad colors when capturing.
is it just me, or does this look bit hackish fix.
bool IsRBSwapped() {return m_rbswapped;}
m_capture.DeliverFrame(m.bits, m.pitch, m_dev->IsRBSwapped());
STDMETHODIMP DeliverFrame(const void* bits, int pitch, bool rgba)
Isn't RGBA totally different thing than rbswapped? Isn't rbswapped BGR color. So are we getting wanted result by accident? :)
wish there were edit button...
My knowledge isn't enough to understand all stuff that happens inside "STDMETHODIMP DeliverFrame(const void* bits, int pitch, bool rgba)" so might just be bit confusing naming of variables too.
Anyways nice to see this fixed
dx9 has bgra all others rgba, by default it should be false and set to true in the constructor of GSDevice9.
Going to check recording.
yea, IsRGBASwapped was called something else before, with a complete opposite meaning, I forgot about DeliverFrame when renamed.
ah. That dx9 explains the swapping. Thanks for explaining and fixing it in next commit :)

Revision 1637

GSdx: corrected recording code.
Ok, I'd never thought of doing it this way.
Thanks for fixing this up :)
is it faster than recording with fraps? any way to get spu2 recording synced to this?
When using spu2-x, you get a perfectly fine audio stream.
You just need to mux the stream with the video, and speed the video up to 60fps.
I use virtual dub mod for this :p
How I can download this pluigins pls helpppp mee

Revision 1638

Converted VifDma.cpp over to using Tags.h. Worked some more on straightening out

Revision 1639

Minor correction to the last revision.
I do not know since this version or from version 1638 but now game Growlanser Generations and Growlanser The Dual Darkness do not freeze when the protagonist gets to casual battle. Thanks!!! Also excuse for my bad English. :)
Why msvc is so stupid, and warning about return bool as int.
Fixing it by adding "!!" made the code a little stupid too :P

Revision 1640

Improved the safe_delete / safe_free macros to avoid potential block scoping
pitfalls, and fixed what looks to have been a minor typo in Tags.h :)
Put that function in for completeness, and I'm not sure if I'll use it. But, yeah, I did a quick copy and paste, and forgot to remove the extra equals sign...
Funny that only the guaranteed to check for NULL deletes are double checked.
Eh, figures. The first online source I checked for it (which was a few months ago) said that checking for NULL is recommended prior to delete because some compiler implementations may not check. But everything else I check says otherwise.
Also, free double checks too, in that code, not 'just' delete. I've had problems in the past with various ansi c implementations that didn't do null checks on free (Watcom, borland, early GCCs, etc). I *think* everything does nowdays, but eh. It's not really a defined standard so I'm playing safe.

Revision 1641

microVU: Fixed a case where a cached microProgram was killed but was still being
This fixes Suikoden III hanging/infinite loop problems, and possibly some other

Revision 1642

microVU: Now prints some more Warnings to the console when unimplemented
features are happening.

Revision 1643

Removed duplicate null checks on safe_delete.

Revision 1644

Fix a foopah, and get rid of the useless imdct warning.

Revision 1645

Changed the MFIFO test and message because it spams too much now that it
actually does what it said it did before. Fixes the FFXII opening.
That's what I get for changing the test to match what the message said it did. There are three modes the ps2 is supposed to use, based on 2 bits. 00 = normal, 01 = chain, and 10 = interleave. So the test that was there tested the second bit to see if it was chain mode or not.
I changed to print the message that it's not chain mode if the two bits aren't 01. Turns out the two bits are set to 11 in ffxii's opening. :)

Revision 1646

Convert Sif.cpp & Vif.cpp to use the Tags.h code.

Revision 1647

microVU: Now properly supports E-bit set on branch delay slot instructions.
(Gets rid of "Unknown Micro VU opcode called" errors in Dark Cloud 2, and
possibly fixes some other games)
Def Jam Fight For New York now freezes as Loading screen (after character select). For previous revisions, it crashes directly :)
Since ferrarinews doesn't spam for a long time, could you guy's fix gt4?
I got it,
redshadowfoxdie is ferrarinews's new neckname ...
I am joking ...
nope, my nickname usually is mytik, this is my default email address :)
nonono, before gt4 I suggest burnout 3 to be fixed
agreed BO3 is way more fun^^
Yes pls fix GT4. For the love of god.
And the sps issues in Ghost Hunter.
And the missing fmv in rules of rose in gsdx hardware.
And Fatal Frame 2 and 3 please!
Champions return to arms should be fixed too
no problem right? :)
No, since it's wishes day. Just add to the list of games you want fixed :p
No No No. I demand that Super Raibown Tea party 2000 is 100% functional before any other game that exist or will exist in the future is fixed.
I want to play at Summoner 2! (freezing)
and "Gauntlet: Seven Sorrows" in hardware mode (as you know - it broken)
and clean "shadows" in Soul Calibur 3
please-please, oh-h... ,-) Please?
And pls fix shadows in Ico and Shadows of the Colossus in HW on GSDX ;)
Sorry cotton :p
Just wanna ask, whak does mean VU0 perma-stall breaking execution...
messages after all?
It means vu0 is spinning (in c this would be simelar to while(1) ), and we stop running it (breaking).
Oh and since Summoner was mentioned, fix the mega slowness in that game :p. Easily one of the slowest games in pcsx2 for me.
Also fix Duck Hunt. There's no reason Pcsx2 shouldn't be able to support SNES games and lightguns. The PS2 is faster than the SNES, afterall. And I want power glove support, dangit! Get on it, you lazy pad plugin authors!
errr... mattmenke.... aren't YOU a padplugin author......
Hmm....now that you mention it... No wonder those pad plugin authors are so lazy... I demand I get right on it!
Yeah, it's about time we could enjoy fatal Frame 2 and 3 on Pcsx2 =P
Champions are still not emulated?
What should I do, that would be comfortable playing together?
Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)
Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)
Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)
Def Jam Fight For New York now freezes as Loading screen (after character select). For previous revisions, it crashes directly :)

Revision 1648

And we can add Gif.cpp to the list of files now using Tags.h
If anything breaks, line 188 and line 289 are the main ones that would have slightly different behavior.
Line 188 can be changed back by changing it to
if (!(Tag::SafeTransfer("Gif", gif, ptag))) return false;
if (((CHCR::MOD(gif) == CHAIN_MODE) || (CHCR::MOD(gif) == UNDEFINED_MODE)) && (gspath3done == 0)) // Chain Mode
Is closer to how the old version of 289 worked.
Doubt either will be an issue, though.
Never mind on 289. Looked closer, and what I did actually was the old behavior. :)
Testing all these changes along with my own stuff, so far its looking good :)
Glad to hear it. :)
I've been trying to commit these changes in manageable chunks, because while a lot of the changes are straightforward, and shouldn't cause issues, occasionally I've been doing things like change code to what the comments say it did, when what it actually did was slightly different.
I like this so far, though. I think these changes improve readability, and also reduce the chances of mistakes in the code. And if we want to change how tags are handled at some point in the future, it should be a lot easier.
And I'm still surprised to find out that there is a 4th, undocumented mode besides normal, chain, and interlaced. Either that or both bits get set by accident on occasion. :)
Hmm, might be some sloppy code or whatever, that left the 2 bits low.
If it can happen on the hardware, I guess it's best to assume it will :p
Btw, we're planning a unified dma controller for the ee and iop sometime.
Chances are most of the dma code will have to go then.
No schedule for that though, it may take a long time yet.. :p
I see what you mean. I'll have to confirm it with less hacked code, but I just found a case where ASR0 & 1 are both set in hwDmacSrcChainWithStack in the RET handling. It gets treated as if there are no addresses in the current code. (May have to fiddle with that; wonder if that's right?)
That's when you press start in Star Ocean 3, btw. It might act differently in Windows, given that there's a weird platform difference on that game anyways.
And no problem about the dma code going at some point. I may as well keep changing it when doing my changes in other areas of the code. It'll still be useful as reference code...
May actually be a bug in my code on that one. I'll play with it more...
Yeah, it was. Good thing I hadn't actually used that function in the code yet. :)
tried to play Final Fantasy X-2 on rev 1653 (built by gabest) i noticed that yuna was running really funny like a meter would require 10steps when running like a cartoon :p
Figured i should try to see when it began and slowly tested previous revs by gabest and the weird run bug appeared on this revision 1648.
The issue shows it self on the bridge of the ship.
Hoped this helped and thx for a super emulator.
This revision breaks Tekken 5.
After the intro, you just get a black screen.
I also tried the 2 line changes you mentioned:
if (!(Tag::SafeTransfer("Gif", gif, ptag))) return false;
if (((CHCR::MOD(gif) == CHAIN_MODE) || (CHCR::MOD(gif) == UNDEFINED_MODE)) && (gspath3done == 0)) // Chain Mode
They don't fix the problem.
I rather gathered. See r1657.
sorry about that, i thought i was updated to latest revision when i noticed the problem.
so i reverted until i found out this revision was the originator of it.
its indeed fixed in r1657
No problem.
I'm starting to think I should buy Tekken 5 for testing despite not really being interested in it as a game...

Revision 1649

wxgui: All kinds of mess, but still not up to running games yet.
* Borrowed wxScopedPtr from wxWidgets 2.9
* Fixed up first-time startup procedures and folder selection
* Implemented most of the rest of the missing configuration options, and
cleaned up some ambiguities regarding bool types and bitfields.
big plusssssss!
sounds like not as much left as I thought^^
Problem configuration folder

Revision 1650

Initial pixel offsetting support via gsdx.ini.
Use pixoff_x = somevalue and pixoff_y = somevalue.
This can be used as a workaround for the various upscaling errors :)
Try these values for Takes of the Abyss for example:
Tales.. Ah well :p
Ah, this is the hack that you've been working on for a while? :p
for me it's
for TOA though the effect seems kind of pixelated (idk if that's even a word XD)
even though this is great 20 gazillion plussssssss
Yeah, this is part of the stuff I tried to workaround the upscaling problems :p
The values change depending on how you set the D3D res.
Is this to fix the sort of clone-shadowy type effect on ToA, and perhaps .hack?
Could this affect Shadow Hearts at all?
Silly question, can we use floating point for the offset values..?
ATi cards will benefit from this afaik.. +1 for the effort..
nevermind I see that you declared them as integers :p sorry..
works with god of war too?
No floats for that, sorry.
And yeah, it works on shadow of the colossus :)
Eh, I meant god of war. But it'll work on both games :p
It's better than nothing but not a perfect solution. (For example in SO3 it shows graphical garbage at the side of screen opposite to the shifting direction. =_=)
Is there no way to algorithmically determine the offsets based on internal res? The way the commit summary is worded, this is customized more on a per-game basis rather than a resolution basis.
Sure, this can be computed based on internal res. The thing is, this is indeed a game specific setting.
funtastic work, GoW2 NTSC fixes with
but a good idea could be automaticly turning it of when native is checked Oo
Yeah, of course.
Also, it'd be way better if I knew which textures to offset, and which to leave alone.
Unfortunately I don't.
Hope Gabest can help :p
Why did it work ok in r1584 and before ?
Whats changed that now requires this workaround ?
I see :p
What about something like selectively upscaling everything except those layers which would otherwise be distorted due to upscale?
DKTronics... what are you talking about?
this effect never worked with custom res afaik
it was deactivated in r1354
but this workaround is the best tackle to the prob yet
AAAH this is really cool! made me really happy! Finally shadow of the colossus's fairy shading is in place.
Sorry guys, I didn't read the thread properly, I thought this was the same as this problem mentioned here
I apologise, sorry, I've just been dying to test the newer builds, but keep getting that shifted image in games like ICO.
Rama, what settings did you use for Shadow of the Colossus?
I get rid of blurry battle graphics in FFX with x=-34,y=-34, but with those settings I got 34 pixel width blinking borders on top and left side of the screen.
I think of for image cropping settings like Pete's OGL graphics plugin for Psone EMUs does.
The amount to shift depends on the D3D internal resolution you set.
If you need to offset by 34 pixels, then the internal res must be way too high..
Same thing really, it depends on what D3D internal res you use. Try -8 for both.
Well, I was just doing a double of the native resolution. Went from 512x448 to 1024x896. Is there a way to calculate or have a general rule as to what your offset needs to be?
I also noticed that using offset settings brought back the overbloom effect even with higher resolutions. Looks like I'll have to choose one or the other for Shadow of the Colossus.
this is one of those things that will work perfectly on the wiki, the wiki could even have a simple calculator where you introduce your internal resolution and it returns the proper shifting values for each game that needs it

Revision 1651

microVU: minor changes...

Revision 1652

microVU: 70% implemented Branch in Branch Delay Slots. Hopefully I'll finish
Compare Star Ocean 3 intro with mVU vs sVU, and you can see mVU now correctly
renders the title menu/new game startup screen =)
Using microVU for MGS2 solves the missing graphics geometry...
Great, it also fixes a problem in valkyrie profile 2 (the extra map for shortcuts, when you press circle on the world map).
void condEvilBranch(mV, int JMPcc)
This revision bugs Def Jam Fight For NY. Before the game goes into character select screen and only freezes after that (I already reported this)
Now all we get is a BLACK screen right at the beginning
Some things I saw:
Channel 2 DMA is stopped and reached END tag
VIF1: interrupted
VIF1: interrupted stall in effect
VIF1: decoding VIF data
VIF1: LAST VIF code was 80000000
GIF: Intermittent mode
GIF: temporary stop
GIF: transferring from EE to GS
GIF: transferring from VU address 0x0 REGS 0x0 Loopcount 0
Is there any message about a branch in delay slot?
Sorry no!
Actually, I missed out a revision - r1648. And it looks like that's the one which caused the problem as it concerns with Tags and Gif (as the command showed). I will revert and test it
Sorry cotton! :)
good job, cotton.
but Dynasty warrior 5 SPS still remains.

Revision 1653

Tags.h meets SPR.cpp. Plus some more work on Tags.h and Misc...
Just as a note; functions in the namespace D_CTRL are not ready to be used yet. They are just stubbed out, and would in fact not return correct values at the moment.

Revision 1654

microVU: Finished properly supporting branch in branch delay slots.
yay! 'finished' is always a good word. so what is left on microvu?
r1653 is stable
r1654 (this version)application crash!!
I have try DEVEL profile.
seem working OK,
but SSE2 profile, application crash....
there's some ugly IPU code that randomly causes crashes when other parts of the emulator are changed.
i'll see if i can can hack-fix it; but for now the DEVEL build should work fine :D
isEvilBlock, XD I presume next will be: isGoodBadOrUgly
prolly more increasing connotation like evil -> demonic -> Diabolic
badBranch, EvilBranch lol
Naming is hard, but it doesn't mean that it can't be fun :P

Revision 1655

pcsx2: removed some warnings from the new dma tag code.
i meant msvc++ warnings ><
I think i fixed some typos in tags.h, not entirely sure if thats what you wanted so check it just-incase :D
still application crash when Run (including BIOS/CD/DVD...)
Problem signature:
Problem Event Name: APPCRASH
Application Name: pcsx2.exe
Application Version:
Application Timestamp: 4a8cbd1d
Fault Module Name: pcsx2.exe
Fault Module Version:
Fault Module Timestamp: 4a8cbd1d
Exception Code: c0000005
Exception Offset: 0019979c
OS Version: 6.1.7600.
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
PCSX2 Log:
Initialize VU0....
Initialize VIF0....
Initialize IPU...
than crash
compiler by VS2008 Team Suite.
Help!!! back to r1653
I have try reompiler to DEVEL profile,
it's work!!!
but SSE2 profile, application crash...why
qqqq: check my comment on r1654
Gha, how annoying.
Yeah, I'd just quickly sketched out those functions, and since I wasn't using them yet, hadn't really gone over them to make sure they actually did what they said they did.
I'd actually already straightened out most of the typos before leaving for work, actually, because I'd started to use one of those functions, but hadn't had time to commit yet.
That's definitely what I'd meant to put in there, though. Thanks!
Now I can concentrate on the issue with r1648. Think I know what caused that, but I'll have to test things...

Revision 1656

Disabled precompiled headers for release builds. This fixes the random crash
introduced 2 revisions ago (caused by some crappy IPU code we need to eventually
get rid of)
Since the IPU code randomly works/breaks with different changes to pcsx2,
eventually we'll be able to re-enable PCH.
release SSE2 profile working again~~~
Hehe, magical voodoofix time again :p
Just curious, I've been compiling pcsx2 using the 2010 project file provided by Gabest a few revisions ago and have not experienced this problem. However, I notice most revisions only update the 2008 file. Am I missing out on any potential fixes if I continue to compile using 2010?

Revision 1657

Tags.h: 0x8000000 != 0x80000000.
Gah. Simple arithmetic.
I'm starting to get irritated with how many typos I seem to be letting slip through...
In any case, this fixes the timeout errors in the beginning of FFX-2. Wouldn't be surprised if it fixed the rest of r1648's issues, too.
Nice catch arcum, also fixes Tekken 5 ;)
I thought it probably did. I couldn't verify since I don't have a copy, though. I've thought about buying it before simply for testing purposes, sadly. :)
I really would think that having what would amount to random values in the Irq flag would break more then it did. :)
Oh, and I wouldn't have made that mistake if I'd started with any file other then IPU.cpp...
this fixed tekken 5's black screen/hanging after intro.

Revision 1658

wxgui: Fixed most of the trivial bugs from the prev commit.
* Removed NoncopyableObject class and replaced it with a
DeclareNoncopyableObject() macro -- which reports saner C++ compilation errors
when the object copy is attempted.
* Improved first run wizard and several configuration panels.
* Moved the BIOS selector to its own menu item and dialog box, separate of the
Settings panel.
* Fixed various bugs preventing configuration changes from being saved.
nice Job :)

Revision 1659

Correct fix for thread affinity in CpuDetect, and fixed commenting in
This revision *should* finally fix this problem, without a need for the hacky forced-fix. Everyone check your cpu readouts and make sure things aren't locked back on Core 0 again or whatever :p
Works just fine here for me.

Revision 1660

wxgui: sync with trunk (boooring)

Revision 1661

wxgui: The Linux side compiles and runs again. Note: Removed "Open in Explorer"
buttons for folders since there seems no reliable way to do that in Linux.
In this revision I also fixed/streamlined a few things I noticed, such as using SetSizer instead of SetSizerAndFit for panels. (The latter is intended for top level windows only)
Now I can get back to trying to get a game running... :)
And now I can actually test it... :)

Revision 1662

microVU: Changed some VU0 syncing stuff. mVU0 will only exit out early from
recompilation for syncing whenever mBit has been set, instead of all the time.
This is a nice speedup in Nanobreaker, as well as fixes the constant
recompilation problem.
If anything breaks with this let me know :)
Cool fixes VU0 perma-stall spamming shit in console in MGS3
Though I doubt we should really have people e-mail zero if the graphics are bad... ^_^

Revision 1663

microVU: minor change...

Revision 1664

wxgui: Additional fixups to linux behavior.

Revision 1665

wxgui: Changed the method of usermode storage so that it doesn't violate
/program files permissions; plus some minor bugfixes/cleanups.

Revision 1666

Added Vif Error flags to Tags.h.
I might actually want to split this into multiple files, since I'm starting to put register flags in that aren't actually part of the tags.
We'll see...
You know if you're going to keep on this pattern it might be a much prettier solution to use structure member methods, instead of an external namespace.
for example:
struct VIFregisters { // this is the current struct
[...] // current contents
// If true, interrupts by the i bit of Vifcode are masked.
__forceinline bool MII() { return !!(err & VIF_ERR_MII); }
... and then in code you just do:
if( vif1Regs->MII() ) { [...] }
Note that yes member methods are perfectly legal on structs in C++, and they do not affect the storage of structs in any way. (in fact as long as you have "struct" as the qualifier C++ won't let you use virtuals or other members that normally change data layouts and such).
That's a point. It probably would make more sense to put the methods in the existing structure.
Though that does eliminate the indication that the methods are part of the Vif error register. Suppose I could nest structures, to get:
if (vif1Regs->err->MII()) { [...] }
I'll also have to look closely at Vif0Stat, and Vif1Stat, as they have slightly different flags.
And it occurs to me that I maight be able to incorporate the checks on MII, ME0, and ME0 into INT, ER0, and ER1, since the first three mask the second three...
Though not exactly like that example, obviously, since err is an existing member of VifRegisters.
And, handily, looks like all the differing flags between Vif0Stat & Vif1Stat are on different bits...
Actually it'd be:
if (vif1Regs->err.MII()) { [...] }
And really there's even a third option, which is to use bitfields:
union {
u8 allbits;
struct {
u8 MII:1;
u8 ME0:1;
u8 ME1:1;
} err;
That's how the cpuRegs struct is laid out, and also all the gifTAG parsing code in gsdx and zerogs (those also use nifty macros for making the struct/union redtape less taped). Using bitfields there isn't really any need for get/set accessors or enums or defines, etc.
Some people don't like them though because they don't trust them (C standard has no required bitfield order, so a compiler could store them randomly and be C standard compilant). But since the most popular use of bitfields is for mapping the bits of hardware registers since like the dawn of time, no modern compiler dares violate the sacred low->high bitorder.
... so I'm all for bitfield use. :)
(well, except for IBM's compiler, which does high->low to match the big-endianness of its target cpus, but hardly any concern of ours :p ).
You could even be especially clever and change the macro for vif1Regs from a pointer to a C++ handle:
#define vif0Regs ((VIFregisters&)PS2MEM_HW[0x3800])
#define vif1Regs ((VIFregisters&)PS2MEM_HW[0x3c00])
... and search/replace all 'vif1Regs->' to 'vif1Regs.' :D
(Welcome to Stupid C++ Tricks 101 .. Lectures begin on Thursday. Tardy students will be penalized).
There's a reason why you mention these tricks in a revision with 666 in the number, isn't there?
I like bitfields. There are a few cases where having accessor functions might be more useful, though. I like the idea of building the masking of INT, ER0, and ER1 into the function, for example.
And rewriting lines like this to use bitfields might be a pain:
vif1Regs->stat &= ~(0x1F800000 | VIF1_STAT_INT | VIF1_STAT_VSS | VIF1_STAT_VIS | VIF1_STAT_VFS | VIF1_STAT_VPS); // FQC=0
(Though lines like that could probably use it...)
Eh, yeah. >_<
Using the union approach allows you to still operate on the bits directly, at least. But it means you'd still need the #defines and enums (which isn't really a bad thing, I suppose). So it'd become:
vif1Regs->stat.allbits &= ~(0x1F800000 | VIF1_STAT_INT | VIF1_STAT_VSS | VIF1_STAT_VIS | VIF1_STAT_VFS | VIF1_STAT_VPS); // FQC=0
Just noticed something. For whatever bizarre reason, the last field on vif->stat, fqc, is 4 bits on vif0, and 5 on vif1. That complicates things...
Though the extra bit is a reserved field on vif0. Not sure if it does anything.
The field would specifically be reserved because the VIF channels, at the HW level, use the same basic duplicated logic. So the HW design would want to ensure matching bitfields and, if one side doesn't need the bit, they would mark it as reserved to retain matching fields for both sides.
Makes sense.
Real question is how to handle that if we do bit fields. Reserve it the full size on both, and make sure that vif0 doesn't use the extra bit?

Revision 1667

wxgui: More bugfixes to configuration saving/loading.
how i can download pugins plss help me i new and i need help

Revision 1668

microVU: Finally fixed the Kingdom Hearts missing poly bug =D

Revision 1669

microVU: Cleanup of opcode lookup tables. (Removed the macros since multiple
instances of the tables aren't needed anymore)

Revision 1670

Odds and ends. Various defines involving vif->stat are now enums, and are now
used in various places. Added a new file to GSnull. Moved the new Vif functions
to Vif.h.

Revision 1671

Changed some more stuff to use the vif stat enum's; and some other minor

Revision 1672

Lets use the Gif stat enums, too. And set some of the dmac irqs to have more
accurate names, and misc other things.
I always wondered why you guys use so many 'magic numbers' in the code, it's hardly manageable, hard to update, etc... Glad to see that changing :-D
Some parts of the code are like ancient. They come from times when nobody was sure it'd ever run real ps2 software :p
Or are mostly verbatim from the original pcsx, in some cases.
Magic numbers and hard to read code in pcsx2 have been a pet peeve of mine for quite a while, and I spend time every so often trying to get rid of them.
In a lot of cases, you have to have a decent understanding of what's going on in the code to get rid of them, so as I understand the code more, I'm able to take care of more of it...

Revision 1673

Some preliminary HID code that I may or may not build off of.
Err... LilyPad, of course.
Heh. I checked how to use HID stuff from within RawInput only, instead of using the hid stuff + the setupapi lib (which IMO seems like the wrong place to have hid functions O_o). But there didn't seem to be any documentation about the descriptor data RawInput returns... :/
The annoying thing about doing it this was is using ReadFile with overlapped I/O. Unnecessarily ugly, IMHO. I hadn't thought about using RawInput.
RawInput worked for reading packets of data just fine, I gt some C# code for it around somewhere... :P

Revision 1674

microVU: minor change...

Revision 1675

- Started implementing VU macro mode (code off by default)
- Disabled Constant Propagation for Jump Addresses (this rarely was a speedup,
and it slowed down recompilation time a lot in some games causing bad slowdowns
GoW and Killzone have a lot more stable speed now, thanks cotton
Macro mode on mVU seems to be very stable out of the box.
Try FFX with it btw, mVU is 10% faster in it :)
Oh well:
[14:21] <rama1> dawn of mana uses some physics engine, and it seems to run on vu0 macro
[14:21] <rama1> and yeah, its bugged :p
Bit of trial and error brought up it's SUB.
^Using this instead of the recompiler, and the game physics work perfetcly again :)
So, cotteh, it will be macroVU first? :P
Whew... I can`t catch up with all those revs... I haven`t tested 1666 and it`s 1675... have a break guys :"D
@heatblazer dont mention the word break yet as there on a role and i'm hoping that one day all the ratchet and clank games will become playable with very few graphic errors as i broke my ps2 last week and can no longer play them. :`(. btw devs thanks for a brilliant emu.
cottonvibes help dolphin team
[email protected] - why you made such a stupid comment as that?
Hu-u-uge THANKs again, Cotton !!! Many games runs faster now =)
But... can you explain what exactly gives new VU macro code ? :)
It is for compatibilty or for speed ?:)
rama about this INTERPRETATE_COP2_FUNC(SUB, "SUB");, what exactly in COP2 is supposed to be changed?
replace rec func with intepr.

Revision 1676

Various changes that were accumulating. Broke off Gif.h from GS.h. Changed some
defines to enums. A few other minor things.
This looks like more changes then it really is when you look at the list of files...
Note: I'm aware of a number of errors in the commented out code that I'll fix later. Punctuation *and* using reserved words...
guliverki site does not support downlodas?

Revision 1677

Fixed up the bitfield code in Gif.h to the point where it will compile.
Positioning in memory may still be off, so it isn't used yet.
A few silly errors in there originally. Think I started typing it out right after doing a bunch of enums.

Revision 1678

Added what should be the correct padding to gifRegs...
All right, that *ought* to work now. Still needs testing, and I haven't hooked it up to anything yet.
Being able to say gifRegs->stat.P1Q instead of (psHu32(GIF_STAT) & GIF_STAT_P1Q) should be an improvement, though.

Revision 1679

LilyPad: bugfix that should (hopefully) make it more difficult to accidentally
bind an entire axis. May make issues with devices incorrectly reporting initial
state worse.
can't compiler with 4 error (VS2008 Team Suite)
HidDevice.obj : error LNK2001: unresolved external symbol [email protected]
HidDevice.obj : error LNK2001: unresolved external symbol [email protected]
HidDevice.obj : error LNK2001: unresolved external symbol [email protected]
HidDevice.obj : error LNK2001: unresolved external symbol [email protected]
C:\PCSX2\\bin\plugins\LilyPad.dll : fatal error LNK1120: 4 unresolved externals
Setupapi.lib isn't in your default include path? It is in mine. Also, you're complaining about the wrong revision. Seriously, if you can't even find the right revision to complain about in a case where it's this obvious, you're not in the SVN target demographic, anyways.
I can't edit my previous comment, so...create following message...
It seem still need Windows Driver Kit (WDK) to compiler
I'll try later.....
Actually, you don't need that. You just need to add Setupapi.lib to the library list. You have the setupapi header files, so you have the library files as well. Committing a fix momentarily, should let you compile.
Oh, and sorry for my first response...
setupapi.lib is in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib
you need add this path to VS2008
add setupapi.lib to Link/Input in VS2008
It's OK.
I know your work is hard.

Revision 1680

wxgui: Prepped the R5900 recompiler for the new wxWidgets-enhanced dedicated
emulation thread design, and removed the old boolean-based re-entrant event
checking mess.
Note: Nearly have a successfully booting branch! (bios crashes when it reaches
CDVD api callbacks, should be a simple fix but it'll have to wait until later
Awesome work!
Jake, can you, please, revert or fix BIOS CDVD booting branch ? We need it for some games... Really...
The new built in CDVD system will work more correctly in the wxgui branch, and that's where I'm currently focusing 99% of my energy.

Revision 1681

LilyPad: Added setupapi.lib to release build. Was already correctly linked in
Yay, I can build LilyPad again!
Sorry about that

Revision 1682

wxgui: Redid a bunch of the wxWidgets assertion handlers so that they're thread-
safe, and fixed the wxLogError stuff to pipe through to the PCSX2 console
(better than it spamming popup errors, and also makes it thread safe as well).
.. oh, and it successfully boots the BIOS now, suing the 'Boot Without Disc'
menu option. :D
Great, not so long from booting games now huh? :p
Great to here it, compiled a version not to long ago just to check out how the new GUI was coming and I'm really impressed. Everything is much easier to access and flows together very nicely. Keep up the good work as always.
Problem report
Unhandled exception at 0x01013a34 in pcsx2.exe: 0xC0000005: Access violation reading location 0x00000018.
> w32pthreads.dll!pthread_setspecific(pthread_key_t_ * key=0x00c58a40, const void * value=0x74f03301) Line 160 + 0xa bytes C
Visual studios say line if (!TlsSetValue (key->key, (LPVOID) value)) in pthread_setspecific.c

Revision 1683

* fixed console log position/size saving settings
* Configure buttons in plugin selector work as they should now
* fixed devel/release builds broken in the prev rev
just note: tried to run BIOS with mVU and it breaks on:
void vsyncVUrec(const int vuIndex) { mVUvsyncUpdate(mVUx); }

Revision 1684

Major Fixes!
* Fixed like a gazillion bugs in the new CDVD system; memory corruption, memory
leaks, failed resets, and who knows what else.
* New commandline parameters!! Added -skipbios/-nodisc/-usecdvd/-elf [file]
options, intended replacements for the now obsolete -bootmode (bootmode should
still work as it used to).
* fixed a bug that kept -help from working, and updated -help to display all
the new command lines.
* -nogui command line now causes PCSX2 to close on escape, instead of escaping
back to the GUI.
I think there might still be some issues with CDrom access using the built in Iso loader. Will try and look into it when I get the chance.
Fixes a few of my ISOs that were having problems before.
Great work as usual Jake, seems like some fixes to disc changing too? Will test later.
Also in CDVDaccess.cpp:
ssprintf( fname, (fname_only+" (%04d-%02d-%02d %02d-%02d-%02d).dump").c_str(), ssprintf? Is that a typo or I'm just too noob to have seen that before? (prolly the latter hehe) :P
Some comment typos:
-->Al subsequent checks use the non-negative value here.
Assertion check for CDVD != NULL (in devel and debgu <-- builds)
There is a function called ssprintf to print variable-content message to file.
Yes ssprintf is a custom printf implementation gigaherz and I put together quite a while ago. It uses std::string internally so that it's 100% safe from buffer overruns or similar junks.
"#define SafeSysCloseLib( lib ) ((void)(SysCloseLibrary(GSplugin), GSplugin = NULL))"?
Oh well, I'll fix it while I'm fixing Linux up...
Kingdom Hearts 2 crashes now right after start
It's not this rev it's 1686 causing it. It only happens with Run ISO from menu
thanks for info
run-execute hangs pcsx2

Revision 1685

* Added the missing cd image types to the iso browser (img, bin, nrg, etc)
* Minor fix when using cdvdiso in browser mode (keeps the browser from being
obscured by the GS window).
Just wondering if anytime in the future going to support
*natively* CSO image type. now the only way to deal with compressed image is
using some CDVD plugin.
The CSO format is by my estimate very poor. It intended for being usable by PSP firmware itself, and it's doubtful it would provide very good compression on the large majority of PS2 images (anything with FMVs typically does not compress much). Furthermore, NTFS compression likely matches or exceeds it, and is "right there" already built into the operating system.
(.. unless you have linux ..)
So yeah if we do a native built in format it's only going to be if it can surpass the compression ratios of NTFS compression. Otherwise it feels like a lot of work for not much point. And for it to be useful it's going to have to be based on 7zip or something. It's doable, but certainly not a high priority
... unless someone else wants to do it and post it as a contribution/patch, of course. Noithing stopping that :)
Those compression formats are all a bottleneck anyways.
Nobody seems to be using LZO, which is the only algorythm that makes sense for disk images and the like, because of low CPU use.
Compared to this, DEFLATE is a turtle. And NTFS seems to be using that too...
Speed isn't the problem really. The problem is getting a compression algo that is effective on more than 5% of available PS2 titles. LZO wouldn't qualify, it's compression ratios aren't even as good as gzip which itself isn't good enough to be of use on most titles.
A proper image compression algo should do two things:
* Compress the easily compressible data with high ratios.
* Store FMV data or other already-compressed data in original uncompressed form. (basically anything that compresses less than 10% or so)
This way the emulator need not waste CPU speed decompressing blocks of data that only scored 1-10% compression ratios.
If you implement it this way, you should actually have little impact on ISO reading speeds, because the time required to decompress the data is largely made up in the time saved loading less data from the HDD.
Things are seldom that convenient. For gzip and mostly anything else (which is mostly slower than gzip) stuff, reading is CPU bound, not HD bound, making the read actually slower, as HDs are *way* faster than DVDs anyways.
What could be saved is space, perhaps using somehting like LZMA, with decompression being maybe fast enough for DVD needs.

Revision 1686

Linux only: Preliminary fixups for supporting the new improved commandline and
g_Startup implementation.
@arcum42: Just noticed that I forgot to remove/replace all instances of "elfname" -- it's successor is g_Startup.ElfFile. So you'll want to fix that, in case you get to it before me (and you might, I'm back off to sleep now :)
Yeah, I'm fixing it up to work right now. I'll probably wait on coding the other menu options till I'm totally sure how they work in Windows...
Breaks Run ISO Image from menu.
blargh. It's broken in Release builds because of *taadaa* COROUTINE. The lovely random and mysterious and untrackable memory corruption mess.
I'll turn PCH back on later, should fix it. Or someone else can do it (cotton?) if you feel like it. I'm trying (and failing :p) to stay focused on work stuff here.
Coroutine? Figures.
Note: We are completely open to patches that rewrite coroutine being submitted in the issue section. ^_-

Revision 1687

Corrected an issue when closing plugins, and fixed up Linux to compile (Though I
haven't made the gui changes yet).
Note: I'm not sure at the moment if Elf files work in Linux, given the changes. I'll be checking that shortly, but I wanted to get it running with isos again first...
Nope, they don't. Easy fix for it, though.
Oops, haha. good typo I had there in ClosePlugins >_<
Oh and yea I didn't realize the RunELF command also used the global elfname. It should have its own local elfname var, and *not* use g_ElfFile (which is meant to be a pointer to argv only)
Yeah, thought something was off when pcsx2 was segfaulting when closed. :)
Easy mistake, though.
And I'll switch to using a local var in RunElf...
pcsx2\pcsx2\HostGui.h(20) : fatal error C1083: Cannot open include file: 'CDVD.h': No such file or directory
Compiling under VS2008 fails,think it's caused by #include "CDVD.h" in HostGui.h
yeah in windows that needs to be prefixed: "CDVD/CDVD.h"
I could add cdvd to the global includes list but I think I prefer it prefixed and outside the global includes namespace. It's not something that's used that commonly.
There is a weird bug in Devil May Cry 1 in the sewers level - if you jump, Dante falls and passes trough the floor and disappears from the screen unable to move, you can still draw menus or hit or shoot but - consider it a dead loop. No speed hack and all Advanced - defaults.

Revision 1688

Fixed Elves in Linux, and implemented two out of three menu items.
Haven't bothered about the iso menu item, since it'd take a bit more effort to implement...
ah, yeah that works too, although really the RunELF bit should probably just be using its own "const char* localtemp = gtk_file_etc()" thing, instead of g_Startup. :)
Not that it matters that we get things perfect. I'm just fixing all this up for one final good public beta for people to use for the next few weeks, before I go and break trunk in fun ways with wxgui re-integration.. ;)
True. That's the other part of why I didn't bother to do the iso menu item.
And that definitely works for me, since I'm getting ready to do a precompiled Linux beta.
I'd actually been planning at looking more at the iso code. Think a rewrite was mentioned as being in progress, though.
I recall I'd found that it crashes if the demo "4 Edges" by "The Black Lotus" was loaded...
And I still have yet to test the latest wx code in Linux. My copy of codeblocks got all messed up. It crashes the moment I load the project file. :(
I'm probably just going to redo my 32 bit chroot, since an uninstall reinstall didn't take care of it.
>> I'd actually been planning at looking more at the iso code. Think a rewrite was mentioned as being in progress, though.
>> I recall I'd found that it crashes if the demo "4 Edges" by "The Black Lotus" was loaded...
Do you mean the IsoReader or the ELF loader? I think the demo crashes because of ELF (makes more sense, it shouldn't be using the cdvd/iso stuff at all).
No rewrites are planned or in progress of ELF, and yea it's a slopfest. ;) I did clean up a few minor things in the wxgui branch relating to the GetPS2ElfName and loadElfCrc, but nothing in the ElfHeader class itself.
There's plenty of public docs available on ELF, so there's not much excuse for us not having an ELF loader that works, eh? ;)
I meant the isoReader, and this particular demo was done as an iso, so it was going through the isoReader. It was actually crashing when IsoFS_findfile gets called with a corrupted elf file name, as I recall.
Works properly with the linuz plugin, for some reason.
And I agree on the elf code. I cleaned up parseCommandLine a bit ago primarily because I got curious how it worked, and because it was a bit convoluted. Seem to recall it turned out to have a fencepost error in it, too. :)
>> Works properly with the linuz plugin, for some reason.
Oh re-check it with the new iso fixes. There were a number of corruption bugs that cased a lot of ISOs to fail to run when using the built in iso loader.

Revision 1689

Use a local variable for the elf name.

Revision 1690

Fixed Windows.
Presumably, anyways. I can't boot into Windows at the moment, and my 32 bit chroot is in the middle of a rebuild...
One of the nice things about the wx branch's codeblocks project files is that the include environments for linux and windows match exactly.
Of course the drawback is that if codeblocks devours itself in a fit of self-masochistic loathing, then you're screwed. >_<
Yeah, that's the issue. :(
Fortunately, I don't consider the process of rebuilding the chroot difficult. (Though a lot of people would disagree with me...)
Hmm, Arcum fixed Windows. Quite a feat, actually, although I thought you were fixing PCSX2.
Sorry, couldn't help myself there. :)
I personally consider it a much more impressive feat when we fix Linux ( r1478 )
hi , brocken pcsx2 in plugin.cpp lasts rev's
> pcsx2.exe!OpenCDVD(const char * pTitleFilename=0x00000000) Line 861 + 0x5 bytes C++
pcsx2.exe!OpenPlugins() Line 987 + 0x22 bytes C++
pcsx2.exe!SysPrepareExecution(const char * elf_file=0x00000000, bool use_bios=true) Line 405 + 0x5 bytes C++
pcsx2.exe!MainWndProc(HWND__ * hWnd=0x0022063e, unsigned int msg=273, unsigned int wParam=40004, long lParam=0) Line 727 + 0x9 bytes C++
[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]
pcsx2.exe!RunGui() Line 412 C++
pcsx2.exe!WinMain(HINSTANCE__ * hInstance=0x00000000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00422432, int nCmdShow=1) Line 65535 C++
pcsx2.exe!__tmainCRTStartup() Line 574 + 0x1d bytes C
CDVD->newDiskCB( cdvdNewDiskCB ); <-- This error
I can't reproduce that error. It looks like you're trying to boot into the BIOS, and that's working fine for me here (well it works fine in debug/devel modes -- release mode is currently broken for other reasons).
In case anyones curious, my chroot rebuild is mostly done now. It would have been done before now, but I went to bed after my last comment on this commit.
At this point, I can run pcsx2, and I can open the wxgui project in codeblocks. Can't *compile* it, but I don't think I chose the right options on wxwidgets when I installed it (as I let codeblocks pull it in), so I'm reinstalling it.
Ah, never mind, you broke wxgui on Linux again anyways, by adding more naked code in...
Got it working somewhat by hacking DispatcherEvent in. It doesn't detect any plugins that have anything after .so, which is most of them, though. (File format for the plugins is usually lib<pluginname>.so.<version>
Oh sorry, that's just a temporary hack. I'm going to remove it soon.
Or well, maybe not. Changing the dispatchers to use the emitter is the eventual plan but I don't want to futz with it until games are running on my end. ;)
No problem. At least I've got codeblocks working.
Besides that, the issue I was running into was that the include directories in the Utilities project on the Debug target need to be on the other targets for Utilities as well...
For the moment, I think adding:
.extern recEventTest
.globl DispatcherEvent
call recEventTest
jmp DispatcherReg
to aR5900-32.S, wrapping recEventTest in extern "C" {}, and adding DispatcherReg to NakedAsm.h would make Linux happy as far as the dispatchers go...
Yeah sounds about right. If you want to made those mods (or have already) then go for it. I'm not in a mood to redo things using the emitter and I may not be in such a mood for quite a while.
As for the plugin enumerator, hrmph. Guess we'll have to add a non-win32 define that additionally enumerates *.so.* (should be non-win32 because I think linux and OS-X both would want that behavior)
All right, no problem, I'll go ahead and commit my current changes.
And I think Mac OS X would want that behavior too. Usually for actual system libraries, the way it works is that you have libraries with that file format for each one installed, then a link named lib<name>.so linking to the currently used version.
Not behavior we want here, of course, but that is why the naming scheme is like that, to my knowledge.

Revision 1691

* Re-enabled PCH in release builds; fixes various mysterious crashes.
* Restored Run->Execute's old behavior when the emu is in a reset condition
(plain jane bootup using CDVD plugin).
* Fixed some CDVD init stuff on the Linux side of things.

Revision 1692

wxgui: A few Linux related changes.
Spotted a mistake or two after committing this.
I just meant to comment out OnAssertionFailure, since Linux wanted an actual function for it if it was there.
And I don't think "../../common/include/Utilities/Dependencies.h" was supposed to get into pcsx2.cbp...

Revision 1693

wxgui: Correct r1692.

Revision 1694

microVU: Made the flaghack safer by accounting for some problematic case.
It fixes the few games I have that were having problems with the flaghack (but
the speedup the flaghack offered in those games has been lessened).
The speedup on games that weren't having problems before should be around the
same as before; (in other words: games that were compatible with the hack should
still be as fast as before, and games that had problems with the hack will
probably be fixed but the speedhack won't do as-much)
Great stuff. Katamari Damacy and Radiata Stories are fixed :)

Revision 1695

wxgui: Connected up the CPU panel controls so that they do something, and
fancied up the "Apply" button so that it ungrays only after changes to the
config have been made. :)
and again, just some remind notes :P
1. If I will remove pcsx2.ini it doesn't says that I need to reconfigure it, just makes default one.
2. There is no changes between options microVU and SuperVU (same value in the conf)
3. Value 4 for "VUCycleSteal" directive crashes PCSX2 @ General Setting dialog on:
(green arrow)
4. Values for Other Hacks doesn't saves correctly. Well, their state isn't loading actually.
5. Gamefixes dialog doesn't saves/loads any value.
6. Logging dialog windows doesn't save the vales too (well, it was so since the first runnable release :P)
Also, why it tries to create folder pcsx2/ in user's Documents folder but makes it instead in AppData/Local/ ? :P
>> why it tries to create folder pcsx2/ in user's Documents folder but makes it instead in AppData/Local/ ? :P
It should use both. The appdata/local/pcsx2 folder contains the usermode information for whatever locations you run pcsx2.exe from. I needed an operating-system defined universal location for this info, and it was either there or the registry. Initial revisions of wxgui were storing a usermode.ini in the current working dir, but that had the same problem the 0.9.6 release have: violates Vista/Win7 permissions in program files. ;)
In Linux, compilation currently errors out saying that GetWindowChild is 'not declared in this scope'.
If it gets past that, it complains about OnAssertFailure not being defined...
> I needed an operating-system defined universal location for this info,
> and it was either there or the registry.
I hope it wwll be a lone ini-file in specified static location ;p makes life easier for 3d party software :P
OnAssertFailure errors are related to it only being avail in debug builds somehow. I'm not sure offhand why.
GetWindowChild .. well.. I dunno. I thought I was using it other places already. I'll look into it.
Aha, it's FindWindow, not GetWindowChild. I'll fix in a jiff.
Odd, I was building a Debug build...
Yeah I don't know what's the matter. It's clearly there in the generic headers and stuff. Wait, actually maybe you're missing one of the new files from your project! The function is defined in....
Might be missing from the cbp.
Yep, that's what it is.
Ironically, if I'd done the search with Scite, which I use on the main branch, it doesn't know what's in the project and what isn't, so I would have found where it was defined.
Codeblocks is nice enough to limit the search to files in the project, though. ^_^
>> I hope it wwll be a lone ini-file in specified static location ;p makes life easier for 3d party software :P
Hmm, yeah I hadn't really given thought to 3rdparty stuff, though the ini file in AppLocal probably isn't something a 3rdparty software should care to look at anyway, I think. It simply specifies the location of the pcsx2.ini file for whatever source folder you run pcsx2 from (that way you can have different configurations for different dev copies and/or versions of pcsx2 :)
Most of the current 3rdparty apps assume either Current Working Directory or have you manually specify your pcsx2 location. Don't think that'll change. Tho, if the user installs using the installer, there'll be registry keys that a 3rdparty app can use to find pcsx2.exe automatically.

Revision 1696

* synched with trunk to pick up all new cdvdiso fixes.
* configuration wizard now starts if pcsx2.ini is missing/deleted.
* changed GetWindowChild (MSW specific?) to FindWindow.

Revision 1697

More CDVD and cdvdiso bugfixes: cd-rom images should work now (ie, the old
school non-DVD sort!), and improved the error and async read handling (possibly
affects people running games from dvdrom)
Ironically, the very first game I loaded with this game 30 or so CDVD READ errors[1] on startup. Works perfectly fine afterwords, though, and it's the same game I had to hackfix in the iso code before, Final Fantasy X-2...
[1] CDVD READ ERROR, sector=1944435
Final Fantasy X gives a bunch of these (with a different sector) right before crashing at the "Auron, Look!" screen, too, but I expected that... :)
I can't reproduce that error here. Is there anything special I have to do? :)
Never mind, I don't have FFX-2 .. I read it as FFXII (FF12). Bleh. So confusing.
Anyways if it doesn't crash and runs correctly then I'm inclined to believe it's correct emulation, and that the game is, for some reason, intentionally trying to read invalid sectors. The original gigaherz implementation ignored the error and invalided the pTransfer buffer pointer (bad). I fixed it so that the transfer buffer remained valid, but I still ignored the error and returned a pointer to whatever the last successful read was. The new code properly handles the error, and does not read any data or raise any read-completed interrupts.
Not particularly. They actually happen before the opening even really starts up. Could be a bad spot on my rip of the iso or something, though.
I did have a bunch of changes in my local branch[1], but I just tested with a clean copy of svn, and got the same errors. Not a big deal, since it continues on afterwords.
Crashes if I try to make blockdumps, too. Could be Linux specific.
[1] Namely, I've been converting a bunch of code to use bit fields, including all the chcr code I put in...
Yeah, that's the trouble with the Final fantasy series. And I test with all 3 routinely, too...
And it's likely that it's actually trying to read invalid sectors, since FFX does the same thing. In fact, I was testing FF X-2 because the invalidated pointer broke it originally, before I put a test for a NULL pointer there, so I knew there were potential issues in that spot.
Taking a closer look at the Blockdump crash right now. It's at line 295 of CDVDaccess.cpp, somewhere when it's getting the filename...
In fact, it's because the function it's calling to get the iso name is mapped to NULL in the CDVDapi_Iso struct in CDVDIsoReader.cpp, not ISOgetUniqueFilename...
Just noticed: this revision fixes that issue with that 4 Edges demo I was mentioning...

Revision 1698

A quick fix to prevent creating dumps with the built in iso code from crashing.
Ah, good. does dumping work correctly now? I fixed the main bug that was breaking it earlier, but never actually tested it ;)
It seems to. Haven't made a large enough dump file to really test, and in Linux, they appear to get saved at /, but the files are actually created, and it no longer segfaults if you tell it to create a blockdump...
Actually, looks like the dump won't load. It acts like it's going to, says that block 257 isn't found, then says it can't open "cdrom0:\MODULES\IOPRP310.IMG;1".
Thought that was too easy. Oh well, at least part of the problems taken care of.

Revision 1699

It fixes the compilation error in Windows, or it gets the hose again.
I'd be surprised that that didn't give me an error in Linux, but I've noticed in the past that gcc can occasionally be generous with that sort of thing when it shouldn't be...
Yeah I had the same thing happen to me in gcc 4.0 on the wx side.
I'm looking down the code, you're looking up at me
You're cold and tired, that is easy to see
Lower the cpp to you, a bug on the file
Your building will be soft and smooth and your plugin will be mine
That sounds seriously wrong... :-P
I blame the lack of an edit button.
Lol NorikumiSubs

Revision 1700

Fix a typo causing *.dump files not to appear in the "Run ISO" file browser.
hey I was about to commit that!
too slow xD

Revision 1701

More CDVD fixes. I *think* this revision might provide some noticeable speedups
when running games directly from cd drives. Also built-in CDVD blockdumps work
now (DVD images only, legacy CdRom games still don't blockdump right unless you
use the cdvdiso plugin).
Someone do a few blockdump tests for me and make sure this still works. I made a few last minute code changes right before commit and I'm too exhausted to test it right now after having done ilke 200 consecutive blockdump tests already.
If it works I'll de -1'ify myself. I just did that to get yall's attentions :p
Kinda rushing my tests but I made a dump of FFX (PAL) and the dump seems to boot and goes into the opening video.
Just tried making a dump of Oni aswell, which I believe is a CD based game and that seemed to work just fine.
Ok, thanks. It's possible the block dump incompatibility is specific to the one CD game I have available for testing. In any case it's stable enough for me for now. I'm going to leave it be.
I would also like someone to give direct-from-CD play (using cdvdghz for example) a try and see if it feels a bit faster now.
Just noticed that this revision causes Final Fantasy X-2 to stall out on the CDVD READ errors, rather then going past them...
What FF X-2 currently is doing is this:
CDVD READ ERROR, sector = 0x001dab73
CDVD READ ERROR, sector = 0x001dab53
CDVD READ ERROR, sector = 0x001dab63
CDVD READ ERROR, sector = 0x001dab73
CDVD READ ERROR, sector = 0x001dab53
CDVD READ ERROR, sector = 0x001dab63
CDVD READ ERROR, sector = 0x001dab73
CDVD READ ERROR, sector = 0x001dab53
CDVD READ ERROR, sector = 0x001dab63
CDVD READ ERROR, sector = 0x001dab73
CDVD READ ERROR, sector = 0x001dab53
CDVD READ ERROR, sector = 0x001dab63
CDVD READ ERROR, sector = 0x001dab73
CDVD READ ERROR, sector = 0x001dab53
CdStandby : 2
CDVD READ ERROR, sector = 0x001dab73
CdStandby : 2
CDVD READ ERROR, sector = 0x001dab73
<the last two lines keep repeating>...
Works properly with the linuz plugin, btw, which rules out some of the changes being the culprit...
Rama has FF X-2 and can't reproduce this error. It could be region specific or your image might actually be corrupted. The only thing I changed in this rev was to fix a bug that caused PCSX2 to "issue" the read anyway even when it failed (it would retry 16 times, and then just act like it read the data).
So all it was doing all this time was lying to FF X-2 that it could read the sector.
If the game literally tries to read unmapped or special mapped sectors on the inner tracks of the DVD, then an iso copy may be lacking those sectors if the ripper didn't know it needed to include those blocks.
All right, must have been a corrupted image, since I reripped it and it's fine. Guess the earlier version was just more forgiving of a bad image.
Strange, though, because I reripped it exactly the same way I rip all of my dvds, which would have been how it was ripped in the first place. Wonder how it got corrupted?
(The way I normally rip isos, btw, is "dd if=/dev/dvd of=<iso name>.iso")
Incidentally, the "Auron, look!" bug is now more amusing after these changes. Instead of crashing, Auron and Tidus glance at each other a bunch, pace around, then Tidus hides behind Auron and stays there. :)
... I think that's an improvement? lol
You could say that... ^_^
The fundamental issue is still there, it's just that now the dvd stalls if it gets instructions to read to a sector that doesn't exist, instead of actually trying to jump off the dvd and crashing. And when it's stalling, all the tricks they use to make the characters seem a little more alive become evident...
oh! I forgot to address this one:
>> Works properly with the linuz plugin, btw, which rules out some of the changes being the culprit...
Yea! Linuz has a hacky fix in it that 'ignores' certain types of invalid sectors. Gigaherz smartly removed it, and it was prolly masking over other errors

Revision 1702

More Macro VU work

Revision 1703

microVU: Removed the use of an offset-register for referencing VI regs.
It didn't make any noticeable difference speedwise, and removing it will make
mVU macro code simpler.

Revision 1704

mVU Macro: Implemented more instructions...

Revision 1705

Changed the chcr stuff over to bitfields, and got various other bitfield stuff
ready for later on.
All right, I'm done with big commits for the weekend. I was debating on whether to even do this one, with everything else going on...
In fact, if you want me to merge this into the wxwidget branch myself, Jake, just let me know.
Don't think these changes would cause much in the may of merging issues, though.
not a problem. I doubt any of those files will have anything more than a logging conflict or two (due to unicode compliance stuffs). I'll merge later when I'm ready-ish. :)
All right, cool.
And, yeah, I decided you were right about the bitfields. They look a lot better in this revision then the namespaces I'd set up previously...

Revision 1706

Fixed typo.
Don't know *how* I didn't catch that.
The heat's been messing with me the last few days, so that might be part of it. Bloody 107 F temps...

Revision 1707

mVU Macro: Implemented more stuff and did a big cleanup.
And again - BIG THANKS !!!
Eee, this may be kinda stupid question, but what exactly Macro is for?
VUmacro is technically known as the COP2 unit (using MIPS terminology), which is the "Co-processor 2" of the R5900 (EEcore).
It allows the EE to execute individual instructions on the VU0.
* VU0 micro mode runs entire programs on the VU0
* VU0 micro mode (COP2) runs a single instruction
so is mVU in some games faster than ZeroVU now?
some games faster, some game slower, but I think mVU emulate the VU more correct than zerovu
I thank you, speedups in tekken5 and more stability, or sc3 and pes09 more stably in the last builds
when the cleanups is in the command window, stuttering occurring now in these latest builds is a greatly reduced cleanup lines in command window, this makes it much more stable.
continue the great work.
Working great here. little speed up in tekken 5.
Cant wait for Microvu to get multi-threaded. if it ever get ....
Yea it's great, tekken5 only 2-3 fps slower on microVU than ZeroVu for me now mVU 49fps against 52 on Zerorec on slowest arena *T5(PAL)
btw can you include Interpretate SUB instruction fix in COP2 some games like Rumble Roses, Smackdown vs Raw, and Munhunt 2 really needs this
also can't wait for threaded VU
thanks cotton
Oh, thanks for answer.

Revision 1708

mVU Macro: Some changes for a more correct interlocking behavior again VU0 micro

Revision 1709

Installer Improvements:
* installer will automatically version itself to the svn checkout
* default installation folder, filenames, and links all contain the revision
number now.
* Plugins are optionally included into the package (details in txt)
* VC++ Redist detection: the Redist installer is only extracted/invoked if it's
not already installed.
Note to self: I still need to check and make sure I'm including all dependencies, and make decisions about the dependencies needed by gsdx/zerogs.
for such a cool change you SURELY will get +1. :)
Come, now, this is google code. A -1 is just as likely for a cool change. ^_^

Revision 1710

Finished mVU macro, and set it on by default.
Basically this means whenever COP2 recs are used, its calling mVU instructions
instead of sVU instructions.
Note: Theres a very-minor incompatibility problem when using interpreters/sVU
for VU0 with mVU Macro. But I'll fix it later (and it probably doesn't effect
VU0 issues described in Issue 170 still happens even with macroVu+microVU.
Does macroVu is still pretty the same as SupeVU? ;P
MacroVU is for VU0 only or MacroVU1 will be in the future too?
There is no macro mode for the VU1. It can run full programs only (micro mode).
As I recall, VU1 doesn't use the coprocessor or macro instructions...
VU0 has 2 modes, Micro Mode and Macro Mode.
When its in Macro Mode its also called COP2 (it works as a co-processor to the EE).
VU1 only has Micro Mode, and doesn't have a Macro Mode.
mVU's Macro Mode should hopefully have the same compatibility as sVU's Macro Mode.
If not, report problematic games that broke in this revision, and I'll see if I can fix them.
Also it'd be nice to get some speed comparisons between this revision, and the one before it.
I think mVU Macro should be faster.
BTW Killzone and Gow games still have some instability in speed
Well... tested few games - didn't notice any difference in speed and compatibility as well. I can say that new macro isn't slower than old superVU macro.
I have tried this rev out and it makes strange things in FFX-2 happen like the blue spinning ball deal in the deck of the ship when you first start is gone pretty much. and there is strange yellow lines accross the screen too just before leaving the deck to the elevator. and other odd looking bits of floating color. It does however address the major slow down I had in r1708 it is running smooth again just weird stuff going on. so it is back to r1707 for now.
Oh my bad, visual studio was updating intelisense at the time. 1708 speed is fine. the visual isses are definitely still there though.
Hmm, there's a thought. I wonder how many other complaints of jerky fps on specific revisions is because of intellisense updates in the background. ;)
Primal (E), shows some 3D now with microVU0 enabled, it's still unplayable thou and it will eventually hang but a great improvement over hanging on the "loading" screen :P
mm I usually close VS after a build but this time I went and compiled each revision so i could find which one did the graphic glitch, and left it on :/
Well I tried "WWE SmackDown! Here Comes the Pain" players cannot attack each others.. you can move through the other player. NO collision :D.
Rheikon and kimokimo1, can you guys see if r1713 fixes your problems?
cottonvibes r1713 fixed it yes, good work man.

Revision 1711

wxgui: another sync with trunk to pick up more of those cdvd fixes.
the syncs are getting huge because of the TortoiseSVN properties updates (it manages merge information, which is a lifersaver really). But that's why a merge that should have only modified about 15 files ends up modifying 80. :)
+1 because it's dull work and your explanation for the size

Revision 1712

wxgui: Enumerate all the plugins on the Linux side. (And expose a nasty segfault
Note: If you put all the standard Linux plugins in the plugin folder, and go to the plugin screen, it will segfault the moment it tries to load either ZZOgl or ZeroGS.
I got past that issue by only including GSNull as a graphical plugin. :(
Not that I managed to run the emulator with null plugins, either. I can see getting Linux to work is going to take a while...
Backtrace I got from the crash on loading the graphics plugin was the following, btw:
#0 0xf0089ba0 in ?? ()
#1 0xf77afe4a in __nptl_deallocate_tsd () from /lib/libpthread.so.0
#2 0xf77b0fd9 in start_thread () from /lib/libpthread.so.0
#3 0xf7735b5e in clone () from /lib/libc.so.6
Looks like a threading issue.
Actually it looks to me like a C++ exception handling issue, maybe.
_deallocate_tsd should only be invoked if the thread is attempting to terminate. And the thread should only be attempting to terminate if it generated an exception because of some invalid plugin error.
Anyways, I should be able to reproduce that here. I can test plugin enumeration fine. I just can't run games. :p
Yeah, reconsidered after posting that comment...
Just keep in mind that you'll need to disable segfault catching to be able to get a backtrace.
What bugs me is that it likes GSNull. I'd be able to understand it better if it was all Graphical plugins. Might be that GSNull "implements" some optional function that ZeroGS doesn't or something, though.
Actually I take back what I said, I did some tests and multiple wildcards seem to work fine here. I realized I hadn't actually tried to use one since like the DOS 3.xx days, and who knows what I used to screw up and blame on something else, when I was 11 yrs old :p
Yeah, I thought of that too. When I first encountered the problem, I reverted the change, and set up symbolic links to the plugins that all ended in .so. Same issue. Then I started dragging links out one by one, and that's when I pinpointed that it was just ZeroGS and ZZOgl causing the issue.
At that point, I put the code back the way I had it, got rid of the symbolic links, and verified that all the other plugins showed up if those two weren't in the plugin folder...

Revision 1713

mVU macro: I forgot to enable some flag updating code I did in my last commit.
This probably fixes a lot of the games that were having problems.
Fixes munhunt2
> Fixes munhunt2
What exactly it fixes in Manhunt 2? It is still the same for me, except it is lags much more now.
Also, Issue 170 still here.
It was the same problem as in the Smackdown games, but in munhunt player was about 1/4 fall through the floor
This fixed part of the graphics issues from r1710. still some missing graphics and some floating bits are around.
Rheikon: Where in FFX are the floating bits?
I have the game, but don't have any gamesaves or anything. I can test the beginning though. Will I be able to see it there?
If-so I'll try debugging the problem tomorrow.
FFX-2 is the game. and its right on the celsius ship the ball in the middle area of the bridge is mostly gone. and if you go back to the elevator you can see the glowing parts that were supposed to be for lights I think just kind of floating off to the side. I can't remember any other specific places at the moment. and if you have this then yes it is right at the beginning pretty much.
BTW what kind of problem is this?

Revision 1714

* Moved some files around in an attempt to improve CoreEmu and UI separation.
* Major upgrade to the UI's handling of savestates
* Maintenance work to the C++ exception handling
* Some improved error handling and message popups here or there
This commit almost certainly breaks GCC in some horrible C++ sorta way. I'm too tired to test it tonight though. I'll give it a whirrl tomorrow.
(and this huge commit just started out as me trying to fix up the thread so that it was properly suspend/resumable and could handle errors nicely with yes/no type prompts)
It's mostly in a "files need to be added/deleted, and declarations are missing" type of way. It has issues with CDVD_API, for example. And the extern of DoCDVDreadSubQ in CDVDaccess, for example (which either was renamed, or no longer exists).
That's odd. I didn't think I touched anything to do with CDVD this time around. O_o I'll check it out.
Actually, looks like that was because of me adding #include "CDVD/CDVD.h" into System.h, which I did because you added enum CDVD_SourceType to it...
Looks like there's also a million warnings, at least in GCC 4.0, regarding the exception classes. I need to revisit the C++ docs and decipher what the actual behavior is in that situation since I can't trust my fav website anymore (it's written to be understood by regular humans, but it itself does't always understand the C++ standard)
Yeah, noticed those. I just got distracted by the errors before I got to a point where I was going to look at them...
I'll fix the warnings. The proper fix is an annoying one. I need to get rid of the C++ initializers, basically... which means using a common initialization function. I'll be a bit of a copy paste job.
I'm still not sure what's up with the include file troubles you're always having. I hadn't had to change anything except case in include files when migrating from msvc over to wx -- well and remove some old out-dated ifdefs from the old trunk that were needed to fix its weird-ities :p
... but yea if you can update the project files and get the errors fixed, up it. I'll commit a warnings fix in a bit. :)
Most of those exception errors look rather silly. It just wants you to reorder things a bit, like from:
explicit AssertionFailure( const wxString& msg_eng, const wxString& msg_xlt ) :
LogicError( msg_eng, msg_xlt )
, BaseException( msg_eng, msg_xlt ) {}
explicit AssertionFailure( const wxString& msg_eng, const wxString& msg_xlt ) :
BaseException( msg_eng, msg_xlt )
, LogicError( msg_eng, msg_xlt ) {}
I'm actually on the verge of going to bed, though, so I doubt I'll commit anything right now. Sundays a work day for me, and I rarely have much coding time on workdays. :(
right, but even if I reorder it, the actual initialization order will be wrong and things will get effed up in some cases. Plus it's a lot of ugly duplicated code >_< ... I need to get rid of the initializers entirely and replace them with an Init() function.
Ah, point.
And I managed to get it to compile by:
a) throwing a
# define __unique_stackframe
into CoreEmuThread.cpp for Linux,
b) Moving the definition of enum CDVD_SourceType into System.h, and
c) adding the missing files.
While b) works, it's probably not the best way to go, so I'll wait till the morning to commit, and see if I think of a better way to handle that...
Morning in this case defined as past noon.
ok, no problem. I'll look into the enum thing. I used a forward declaration and that *should* be legal. Hrm.
good luck guys
Well, this is irritating:
Not really seeing a better solution at the moment. Including CDVD.h in System.h seems to cause too many issues, and I don't really see a better place to move it.
I'll put it there for the moment, and if we come up with something, we can move it then...

Revision 1715

Fixed Issue 384 - minor compilation error in linux when using local inis.

Revision 1716

wxGui: Get Linux compiling again.

Revision 1717

Added some diagnostic messages to a hackish part of the EE recompiler.

Revision 1718

Reset and recompile the current block on constant buffer overflow. (Some other
checks should be changed to use this if this isn't immediately reverted.)

Revision 1719

microVU: minor changes...
uhh i feel very uneasy when i use float in simple math of integer code.... C++ typecast is blessing and damnation.
Don't rate if you don't know what you're talking about.
Negging a commit because you don't like decimal numbers is retarded.
And FYI, compilers optimize out constants. There is no "float", the compiler see's (0x100000 * 0.5) is a constant, and then converts it to "524288" which is an integer at compile-time.
Cottonvibes your right of not be happy with the -1.
But I cant believe you just said he was a retard... He was very polite in his commit and even if the -1 is not justified, I don't think he deserved that treatment.
I'm neutral with your commit but -1 for your attitude. Sorry.
I disagree. It's like someone walking into my job, looking at my gear, stating his discomfort with Canon cameras with no explanation, and then turning to my client and telling them not to use me.
It's simply unprofessional to just say "I don't like this, and is therefore wrong and shouldn't be used" without any rational explanation. I'd consider it downright aggressive.
If my commit broke something or effected any game negatively a -1 would be justified.
But negging commits for fun, or because you personally don't understand simple multiplication by decimal numbers obviously doesn't make me happy (especially because I've warned people about this stuff before).
The rating system is a great tool, but I hate when people abuse it.
Also because of stuff like this we're going to be disabling comments and ratings when we merge the WX branch to trunk.
It may be that I over-reacted a bit, but when someone devotes ALL their free time working for a project with no pay, its very-arrogant to criticize their work without a good reason IMO.
Take it easy cotton~
And sunnydrake7, please never '-' a reasonable change just because "you" don't like it
ok set to neutral if it caused so much personal retaliation, but i have a lot troubles with compiler typecast optimizations/conversions - it's not so dependable as it seems and more dangerous if you use it complex projects which use recompilers/register/memory and if code must run on different compilers, this was just my personal exp..
I totally Agree with you cotton. you shouldn't have got a -1 for the reason you said.
But at least you know you maybe over reacted. I don't think the guy deserved to be called a retard because I know your more brilliant than that :)
Sorry for my English (2nd language) I may not have express my thought clearly in the first post.
No, cotton was right. The guy pretty much is a retard.

Revision 1720

wxgui: retooled exception handling, should eliminate warnings in GCC and remove
previous initialization ambiguities. (ended up being a nice code cleanup too,

Revision 1721

microVU: Normal clamp mode clamps a little more stuff (fixes some very rare sps
I found while playing kingdom hearts)
Cool Thanks
Hi cottonvibes , the commits so far have not fixed it but I have taken some screen shots and maybe they can help you determine what is going on.
good/odd 1
good/odd 2
That looks like the usual GSdx transparency bug and probably has nothing to do with microVU...
it only happens after using r1710 the ones before it are fine. and the only thing that changed at that point is the microVU stuff so it seems at first the logical choice. Also one of his commits did fix some of the graphics issues so ya...
I'm going to have to get FFX2 sometime this week so I can debug it and find out whats wrong.
Bositman: Rheikon said the game broke when i enabled mVU macro by default.
If you have the game can you also confirm this for me?
Will do, seems this one has to be added to my permanent ISO game list since it loves to break :P
pcsx2guide == Bositman ???
I think I'll go and test it too since I wanted to test macro anyway^^
less SPS is always better^^
Yeah stupid google code does not late you change username, it just uses the prefix of your gmail address, which sucks.
I have the same problem with FF-X2 exactly
good to know it is not just me. Also my bad calling it micro when its the macro stuff that was changed :/
when i change clamping it also effects mVU macro stuff (because both mVU macro and micro use the same opcode implementations).
I'm not sure if the FF-X2 problem is related to clamping or not though...
Well when i turn the VU recs clamp to none the screen starts flashing strangely but you can see the missing parts again. they still however show in front(ontop) of everything else. If i put clamping up higher the globe and some other stuff in the bridge is compeltly gone. By the elevator the two lights inside it are atleast aligned properly it seems but the ones not behind anything do not light up still and the one set that does still shows ontop of everything else.
SUB opcode again. Must be some flag handling :p

Revision 1722

Quick fix for GCC versions 4.2 and earlier, which lack the __COUNTER__ define.

Revision 1723

Command line fixes ( Issue 331 ):
* I had incorrectly documented -usecd as -usecdvd (oops)
* Skipbios now defaults to OFF is was intended

Revision 1724

Issue 331 - let's also fix the "double initialization" issue when booting cdvd
plugin from the commandline.

Revision 1725

* Improved thread safety of file logger (needs work yet)
* Debug builds automatically open the console log during the first time wizard.
* Added terminal logging to linux builds.
* Linux: Bugfixed plugin configuration dialogs being unable to receive input.

Revision 1726

microVU/macroVU: When subtracting a reg by itself, its safer to just set the reg
to 0, instead of actually doing the floating point subtraction.
This fixes the problems in FFX2 introduced in r1710.
Also thanks to rama who found out it was SUB that was breaking the game. (Saved
me a lot of debugging to narrow down the problem ;p)
yep it is all fixed now. nice job!
let's hope this doesn't break something^^
nah it shouldn't break anything.
any number minus itself should be zero.
this doesn't always happen in floating point arithmetic though, because of NaNs/INF.
Nice :) So how do you catch the cases where the number is Nan or Inf and you have to subtract it by itself? Just set it to Nan/Inf instead of 0?
On the PS2 Nan/Inf are just normal numbers, so they end up as zero. This may have very well been the issue. Under IEEE:
Inf-Inf = Inf
Nan-Nan = Nan
On the PS2, both would equal zero.
thanks for the insight guys +1
The only issue here would be WHICH zero? (-1)-(-1) = -0 or +0?
Does the PS2 have +0 and -0? If it doesn't have NAN or INF, I'm not sure it would have +/-0 either.
Well +-0 are "necessary", cos the sign bit is independent of the value. It's anther question if it considers this bit in its calculations in a predictable way.
One test would be if 1/(-0) gives -MAX or +MAX, and I would guess it goes to -MAX like a normal fpu woudl go to -INF, ... but oyu never know unless you try :P
Thanks working perfectly.
You guys are brilliant !
The ps2 does have positive and negative zero.
I know that (-0)-(-0) = +0 though on the ps2.
I assume its the same for all negative numbers subtracted by them-self, but I'm not 100% sure since I haven't tested.
This is also fixed several bugs in FFX like not showing land on the map (upper-left corner) when moving through some locations, like north side of Thunder Plains or Calm Lands from center to Monster Arena. And missing animation like in the beginning of summoning Anima (just black screen instead of sky). Also probably some other screen flickering, but don't remember where it was.

Revision 1727

* Added /gui/AppRes.cpp : contains resource management code that used to be in
* Redid disk/linux console logging to be both thread safe and crash-safe.
* Cleaned up plugin init/open exception handlers
* Was forced to implement a manual version of wxEventLoop because of a critical
design flaw in wxWidgets' message loop exception handler.
Looks like it's giving me issues with the new code in main.cpp.
In member function 'virtual int pxEvtLoop::Run()':
pcsx2/gui/main.cpp:337: error: 'm_shouldExit' was not declared in this scope
pcsx2/gui/main.cpp:340: error: 'OnNextIteration' was not declared in this scope
I'm assuming this has to do with both being protected members of wxEventLoopBase...
It also doesn't like passing wxStrings to fputs, but that part's easy to fix... ^_^
To detail the exception handler foopah of wxWidgets ... wx has four main tiers of message loop handling:
* The EntryPoint (called once per app)
* wxApp::OnRun() (called once per app)
* The MainLoop (called once per app)
* The EventLoop::Run procedure (called from many points, including modal dialogs and stuff).
EntryPoint has an exception handler that performs a catch-all (...), and runs OnExit(). This ensures proper cleanup of resources on unhandled exceptions (good!).
wxApp::OnRun() is what you're *supposed* to override if you want to implement your own custom exception handling. Fair enough, except read on:
MainLoop simply defers to EventLoop::Run. It's purpose is probably to give platform specific implementations of wxWidgets an opportunity to do differing OnRun setup code (which should be in the always-platform-specific Entrypoint handler anyway, so it's pretty well useless).
EventLoop::Run() performs the meaty goodness of dispatching messages (the heart of any user interface). And here's the problem. EventLoop::Run contains a catch-all (...), that *mandates* the execution of OnExit().
Translation: My exception handler in OnRun() was useless, because the exception handler in EventLoop::Run() was already doing OnExit() cleanup, under the assumption that the program was going to terminate itself. But I didn't wnt the program to close. I just wanted to popup a dialog and move on in life. And since there was no way to disable that exception handler, I had to write my own EventLoop::Run from scratch based on the wxWidgets source code.
Protected members should be fully accessible. Only private members would be inaccessable :/
Correction: I'm assuming it's doing this because gcc hates me...
Anyways I'm compiling locally here to see what I can figure out.
Make sure to change:
fputs( L"PCSX2 > ", stdout );
fputs( "PCSX2 > ", stdout );
in ConsoleLogger.cpp...
Ok, in looking I realize that the EventLoop::Run function is much more platform specific than I thought. I'm actually better off hacking out the exception handler from PCSX2's local win32 version of wxwidgets. Why?
*The GTK Version doesn't have the same problem!* It only has a catch-all in the Entrypoint code, as it should. Nothing in the message handlers.
This further confirms my suspicion that this is in fact a bug and not a feature.
And my previos rant is unjustified. Turns out there's a HandleEvent override designed for handling exceptions at the message level. Of course the docs told me to use OnRun(), which is where the whole mess started. Thankfully I stumbed across it in continued browsing of the wxWidgers sources.
Hate when the documentation turns out to be wrong or outdated...

Revision 1728

wxgui: better fix for universal message-level exception handling.
This should fix Linux compilation errors. Lemme know if not.
That did it...
isn't this fun? :p
I'm still not sure what to think on that plugin enumeration crash. I doubt it's a threading issue since it's isolated to a specific plugin. And the only things being run are PS2getLibType/Version/Name. There's really no possible chance for corruption *except* at the stage of loading the DLL itself (which is an operating system action).
Anyways my suggestion is to comment out everything except the code that actually loads the plugin, and see if the crash persists. If so, then the next step will be de-threading the enumerator and seeing if that fixes it.
I purposefully threaded the enumerator because it's a "heavy" action to thread, and was a good test of wxWidgets thread safety. I didn't run into any problems here so I thought we were in the clear. I'll code in an #ifdef to dethread it, so we can test without.
(tho really typically threaded crashes are much more random than even this -- ie if it were really related to threading you should have a reasonable chance of complete success .. but it always crashes, which seems to point to something else)
I've been adding Logging in virtually everywhere, to try to see exactly where it crashes. Which is driving me stir-crazy. Of course, I still haven't really been able to dedicate as much time as I like to it. That'll change when I get to Thurs.
And, yeah, it'd be bizarre for the threading to be killing it predictably. It'd make more sense if it was loading bad data into a combo box or something...

Revision 1729

pthreads: Added <excpt.h> to pthreads.h since SEH requires it; Added versioning
to the project/output filename (currently V2, which is SEH-enabled)
The SEH version of w32pthreads should be fully compatible with any other MSVC-compiled binary, whether it be C or C++, SEH or not. SEH is conveniently flexible in that way :)
also, forgot to mark this as wxgui branch specific, which it is.

Revision 1730

* Fixed thread classing so that detached pthreeads are handled safely, and so
that virtual functions in C++ destructors are explicitly specified.
* Added some helper functions to Pcsx2App for safely executing menu commands
form any thread in the emu.
* Fixed several minor bugs in settings / config handling.
@arcum: This revision may fix linux thread crashing problems. I'm pretty sure there were some issues with the thread class referencing detached threads by handle -- which is bad because once the thread is detached the pthread_t handle becomes invalid.
No such luck.
In fact, actually, it now crashes if I choose "Current Working Folder". The line:
if( UseDefaultSnapshots ) Snapshots = PathDefs::GetSnapshots();
seems to crash it in the Apply statement in Paths.h, for some reason.
Of, gcc didn't like Panels::g_ApplyState.ApplyAll(), so I just set it to Panels::g_ApplyState.ApplyAll(true). Beats me why, though, since I saw that true was supposed to be the default value...
(Just to mention, it crashes in the normal spot as well. This was just a new spot...)
Ugh. There's got to be something wrong with your wxWidgets library build. :( The only conceivable way code like the Snapshots assignment could be crashing is if wxString is unstable or thread un-safe -- which would be the case if wxWidgets isn't built with wxUSE_STL 1
I can't think offhand of anything else that could instigate crashes like that. I'm not even using any threading stuff in that first panel at all.
I'll check my linux build here, but I have a hunch it's going to work fine >_<
I think I'll try downgrading my copy of wxwidgets a bit, and fiddling with the options to see if it makes a difference.
I could be an unstable copy of the library. We'll see.
Come to think of it, what version of wxwidgets are we using on the windows side?
The Windows side uses 2.8.10.
The ApplyAll thing is some kind of GCC bug I guess. If I import the Panels namespace and remove the Panels:: qualifier on the call, it fixes the error. No way that should make/break default parameterization tho.
(unless the C++ Standard somehow defines this behavior, in which case I will lose whatever minimal amount of lack-of-disdain I have left for the C++ standard ... I'd say "minimal amount of respect" but I stopped respecting it a while back and I now measure my opinion only in synonyms of dislike.. lol)
ok the good news (?) is that I can reproduce the Settings crash here in Linux. Still haven't a clue what could cause it since I'm pretty sure I didn't change anything related to that area of the code. But who knows.
I'm assuming gcc bug, because that *should* have worked...
And I rolled back from wxGTK- to wxGTK- Not sure why Gentoo calls the package "wxGTK", but the version scheme for Gentoo packages is basically <program-version>-<package-version>.
That took care of the weird Snapshot thing, though the other behavior is still there.
Think I'll mask off the other version, so I don't accidentally reinstall it...
Either that, or if you're able to reproduce it, something fixed it without me noticing. I'll have to fiddle with it; see if I changed something without noticing it.
I'm recompiling with the other version to see if that's honestly what the difference was.
I had it crashing here for a bit, same spot.. and after I made 2-3 changes and undid them, it didn't crash anymore. I think this is a GCC bug somehow that is (was) fixed by forcing a full rebuild of sources. Specifically, FirstTimeWizard.cpp needed to be rebuilt I think.
Well not so much a bug as a missed dependency, so important files weren't getting recompiled and were using mismatched structure/header data -- causing oddball crashes.
Yeah, I did a full rebuild in there, too, so that's probably what it was. I thought it might have been the library because I spotted what looked like a bug in the ebuild for the later of the two versions, that I thought might have prevented some patches from being applied when it was built.
Glad that wasn't the issue... :)
Indeed. Now only remains the stack corruption crash in the plugin enumerator that I can't seem to reproduce, that's apparently only caused by ZeroGS/ZZogl. That one's got me stumped. I'll include a de-threaded version of the enumerator and hope that works, but who the hell knows :p
Even if it doesn't, it'll probably give us a better idea of where the issue is, at least.
I've just been going over some of the changes I had sitting in my copy of the normal branch, looking for bugs, and trying to decide whether to commit them or wait till after the merge.
Mainly because I needed change gears for a few hours before going back to wxgui...

Revision 1731

Relaxed loadstore cycles a bit on the EE.
This hopefully lets a few regressed games work again.
Also a speedup, specially in fmv..
Increase cycles, thanks few fps here and there :D
FMV speedup, good!!
Good :)

Revision 1732

Minor changes to how the commandline auorun feature works, so that it
initializes in the same general order/pattern as using the GUI. May fix some
spotty problems.
Long time no see. I`ve had a lots of jobs to do. I`ve tested the latest revs and I have to report that the bug from Devil may Cry when jumping and fall into the terran glitch i s gone.
I`ve tested Romancing Saga - good begining, but when finishing with creating the character and when you start - it freezes.
I`ve testet Steambot Chronicles - crashesh as usual.
I`ve testet Mana Khemia 2 - perfect for playing.
Hope it was helpful, keep it up guys!!!
r1708-1713 some of them broke the ICO, in the second room, the camera flies up. clamp configuration does not help. sVU & mVU same.

Revision 1733

Might as well copy some register code from GSdx to GSnull, so I have a starting
place on register handling in it.
One of these days I want to get GSnull so that it handles everything a normal GS plugin handles except actual graphics, and it's easier to do that if I already have the register information in there.
The changes I had to make to the code to get it to work in Linux should be a good reference for any ports of GSdx in the future, too...

Revision 1734

Added more logging to the plugin management process (init/open/close). Added
SVN_REV info to the console log.
PCSX2 0.9.6 - compiled on Feb 27 2009
Savestate version: 8b400004
CPU vendor name = GenuineIntel
FamilyID = d
x86Family = Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
CPU speed = 1.797 Ghz
Cores = 2 physical [2 logical]
x86PType = Standard OEM
x86Flags = bfebfbff 0000e39d
x86EFlags = 20000000
Detected MMX
Detected SSE
Detected SSE2
Detected SSE3
Detected SSSE3
Not Detected SSE4.1
F1 - save state
(Shift +) F2 - cycle states
F3 - load state
Bios Version 1.60
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
MTGS > Thread Started, Opening GS Plugin...
MTGS > GSopen Finished, return code: 0xffffffff

Revision 1735

Patch r1734 for Linux.
Linux doesn't use svnrev.h. It does, however, import SVN_REV in the build scripts...
Is the SVN_REV auto-determined from the repository, or does it have to be manually specified? As far as I remember, the subversion commandline tools for checking revision info are pretty crude. I don't think they do proper recursive revision checking, unless you make a script to it. But maybe that was fixed in a recent subversion update?
I added this code to configure.ac a while back:
svnrev="`svn info | grep Revision:`"
if test -n "${svnrev}" ; then
[Define to be the subversion revision number])
AC_REVISION([$Revision: 0 $])
AC_DEFINE(SVN_REV,"$Revision: 0 $",
[Define to be the subversion revision number])
So Linux gets SVN_REV from there...
Admittedly, that's totally incomprehensible to me. ;)
But yeah it uses svn info. The drawback of svn info is that it gives the same revision number for all subfolders. So PCSX2, plugins, etc. all get r1735, even if the plugins haven't changed since r900 or something. It's not a big deal but it is a difference from the win32 build method that you'll probably want to be aware of.
Oh good news! You can grep for "Last Changed Rev" instead of "Revision". That'll allow you to match the Win32 SVN_REV monikers. That's apparently new, but it should be in subversion 1.6 or above.
Yeah, I'm aware of it. Never got around to having the Linux version of the plugins track svn version anyways, though...
That might be worth changing. I can always fall back on the old behavior...
Yeah.. having it incorporated into wx branch would of course be most useful. I assume it would be the same basic idea except done as a pre-build step or something.
Presumably. I haven't played with the build features in codeblocks much yet. I'll have to look into that.

Revision 1736

Some more changes to use dmaRegs and gifRegs in various places.
dmacRegs, that is.
Forgot to add a few jNO_DEFAULTs in here. Not a bit deal; I'll add them later. They aren't really needed here, anyway, it's just good practice.
I'll probably be doing passes like this periodically. It'll take quite a while to get all the old code converted over, and occasionally it might be easier to keep the old version...

Revision 1737

* Redid 'Run' menu as separate 'Boot' and 'Emulation' menus (implementation is
still spotty as always)
* Fixed some more bugs in config/settings Dialogs
* Fixed a nasty bug in memory cards (no more magic memorycard deletion, yay!)
* Renamed a lot of variables, because I just like refactoring code...
* Fully implemented emulation commands: Pause, Close, Reset.
(no it still can't do anything more than boot the bios, yet >_<)
Still planning to dethread that plugin enumerator. Just had some other things on the list to finish up :p
No worries.
I just got my keyboard working on the bios and boot loader screens again, so I've been busy booting into other partitions I haven't been able to access for a few weeks...

Revision 1738

5.1 support is back!
Currently for XAudio2 only, and it's not doing much (Simple copy of the stereo
source to the other speakers).
Gigaherz is already working on a nice, semi - prologic II upmixer though ;)
Too bad it never left for me :p
Yeah, the mystery never stops :p

Revision 1739

Fixe the dsp (winamp plugin) crashes. Thanks to Gigaherz for this one, too :p

Revision 1740

SPU2-X: Minor cleanups and updated DLL/resource versioning info (which never got
updated for v1.2, oops)
It needs correction to savestate code, if you wanna stick to pre-wxgui release.
Here is a patch.
Index: RecoverySystem.cpp
--- RecoverySystem.cpp (revision 1740)
+++ RecoverySystem.cpp (working copy)
@@ -252,7 +252,7 @@
u32& pluginlen = *((u32*)g_gsRecoveryState->GetPtr(0));
u32& gslen = *((u32*)g_gsRecoveryState->GetPtr(pluginlen+4));
- gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4), gslen );
+ gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4 +4), gslen );
@@ -262,6 +262,7 @@
if( (freezer == gsSafeFreeze) && (g_gsRecoveryState != NULL) )
+ FreezeTag( name );
// Gs data is already in memory, so just copy from there into the gzip file.
// length of the GS data is stored as the first u32, so use that to run the copy:
u32& len = *((u32*)g_gsRecoveryState->GetPtr());
2 line-by-line comments
line 255:
255: gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4), gslen );
Need correction.
Current code raises problem:
# Encountered an error while loading savestate from slot 0.
# Since the savestate load was incomplete, the emulator has been reset.
# Error: Savestate data is corrupted or incomplete
# Filename: Tag: mtgs
Maybe good with:
gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4 +4), gslen );
line 266:
266: // length of the GS data is stored as the first u32, so use that to run the copy:
Need correction.
# Encountered an error while loading savestate from slot 0.
# Since the savestate load was incomplete, the emulator has been reset.
# Error: Savestate data is corrupted or incomplete
# Filename: Tag: GS
FreezeTag( name );

Revision 1741

wxgui: Test revision for Arcum -- with the plugin enumerator running in a single
threaded model.
@arcum: The way it works, it queues up all the gui messages still during ExecuteTask(), so none of the messages are handled until all plugins are enumerated and control is returned to wx's message loop.
All right, got the same place, but now I have a location.
The crash is actually in PersistentThread::Cancel, when it gets to pthread_cancel.
And, in fact, I went into Panels::PluginSelectorPanel::OnEnumComplete, and commented out safe_delete( m_EnumeratorThread );, and all the plugins showed up without a segfault.
Of course, it then segfaulted when I click finish, and once I open it back up, if I choose plugins, it segfaults when I hit ok. But then, commenting out safe_delete is a workaround, not a fix.
Still, means I can play with pcsx2 a bit more in the wx branch.
That crash in safe_delete is unrelated, actually. I kind of half expected it to crash in win32 here, but since it didn't I went with it. The calls to pthread_join/pthread_cancel are using an uninitialized thread handle, since I never create the actual pthread. w32pthreads does a sanity check on the thread handle before diving off a cliff tho, so no crashes here.
Finish and Ok are also segfaulting for the same reason, most likely. The thread is canceled out from the destructor of the dialog box as well from OnEnumComplete.
So my guess is the unthreaded version works fine. I just need to correct it so that it checks the pthread handle for validity before trying to join/cancel it.
I checked the thread safety rules on loadlibrary, and it's supposed to be thread safe. But on the other hand, Linux doesn't apparently have thread safety on libc implementations, so that could be an unforseen complication.
Yeah, it seems like it's working without threads.
I tried inserting a thread-check, but it crashed on the threadcheck. :(
Inserting a few 'if (!DisableThreading)'s around got rid of both crashes, though.

Revision 1742

wxGui: Lets not delete the Enumerator thread if we aren't threading it.

Revision 1743

wxgui: improve single-threaded plugin enumerator for Linux (still a bit buggy)
Somehows the plugin enumerator manages to crash Xming on my CoLinux install with relative certainty when trying to enumerate in single-threaded mode (sigh). Seems to work fine in threaded mode. So I'm committing what I have, and I think it should work, and I'll double check it in windows.
Without the if (!DisableThreading) safe_delete( m_EnumeratorThread );,
it still crashes for me in PersistentThread::Cancel.
Now, if you add:
if( !m_running ) return;
to the beginning of PersistentThread::Cancel, that's enough to get it working for me. Don't know if I'm messing anything else up by doing that, though.
Woops, yeah that was supposed to be in there.
Figured, since you did that for PersistentThread::~PersistentThread, and it looked like the point of that variable was to keep track of whether the thread was started or not.
BTW, I was noticing the VU Clip Flag hack was missing from the list of game fixes. Is it being taken out, or does it need to be added?
I think it needs to be added. Initially I was eliminating sVU-only hacks since I was hoing to discontinue sVU support, but it's still wanted by cotton and rama. :)
All right. I was thinking of adding it back in, but didn't want to do anything that would have to be undone. Don't think they're hooked up right now anyways.
Wonder if I should add in the Mana Khemia hack in, while I'm at it? I'd like it in, but I don't really want too many game fixes in there...
Main issues I've noticed right now are that Linux will not load the bios (as far as I can tell, it's being fed '/' for the plugin paths; something went wrong around LoadPlugins, I think), and that the bios path doesn't change when you change the main path.
In fact, if you play around with it enough, you can get the same bios listed twice in that window. :)
Mana Khemia .. I think that was another sVU specific hack? I know one or both of them were anyway.
On LoadPlugins: Chances are the plugin paths aren't being save or loaded from configuration ini correctly, and so they're probably duds when it goes into LoadPlugins.
On BIOS: No clue. Haven't toyed with it that much. :p Admittedly I'm not a huge fan of wx's implementation of the wxDirPickerCtrl. It has some odd behaviors.
Mana Khemia is a Mpeg.cpp hack; it's related to the coroutine mess.
In the function mpeg2sliceIDEC, it keeps track of whether so_resume() has been called, and if it hasn't been called by the end of the function, calls it before finishmpeg2sliceIDEC.
It fixes Mana Khemia's crashes when going outside, and breaks Digital Devil Saga. It's a hack I came up with as an alternative to an earlier hack that just caused mpeg2sliceIDEC to never be called. Right now, to enable it, you have to uncomment a define in Mpeg.cpp.
The main reason why I've wanted to make it a gamefix is that right now, a number of people have hacked copies of pcsx2 specifically for that game. It's easier to manage if it's in the official version. (And, admittedly, it makes it easier for me to play Mana Khemia. ^_^)
Loadplugins: I'd assume loaded from, because the paths look right in pcsx2.ini.
Bios: Not sure either. I noticed because I switched it to local directory on the main screen, and it was still pointing to ~/pcsx2/bios on the bios screen till I checked and unchecked it. Not a big deal, though.

Revision 1744

wxgui: Add in a missed check on the threading. Update the game fixes panel.

Revision 1745

wxgui: Runs games. 'nuff said.
* Fixed some deadlock conditions by adding a message pump to semaphore waits
ont he main/gui thread.
* Many more config and init bugfixes.
* Implemented most of the new Boot menu.
Lots of issues still like, for example, no keyboard input, no working savestates, some crashes on exit, etc.
But besides that, it's pretty nice-workin.
Doesn't look like isoFilterTypes is defined anywhere. I'm assuming it should be something like:
const wxChar* isoFilterTypes = L"*.iso;*.bin;*.dump";
Oops! I deleted it by accident just before I committed. Will up in a second.
No problem. I'm still trying to figure out what's wrong with the paths, anyways...
As far as I can tell, BaseFilenames.Plugins[pluginidx] is returning '/' under Linux. Doesn't seem right...
Milestone! :p

Revision 1746

wxgui: removed dependency on afxres.h, added resource/manifest versioning info
to w32pthreads.v2.dll, and fixed a compile error.
Keep forgetting important things... >_<

Revision 1747

wxgui: bah msvc and its tendency to save everything *except* vsprops files when
you do a Save All.

Revision 1748

wxgui: my excitement in getting a game to run for the first time in months
clearly has shattered my ability to commit.
Still missing files here too.
Some days you just can't win... :(

Revision 1749

wxgui: fail.
win :3
I remember gabest going on a similar spree before mysteriously vanishing-

Revision 1750

wxgui: minor plugin binding fixes; this gets Linux booting to the point that it
gives me the standard "OpenGL Fail" error (co-linux limitation)
All right, I was able to boot into the bios with this revision, though the graphics were mangled.
Also, I had to go to the pcsx2 plugin screen before it would boot; it must not be enumerating them before that.
Telling it to run any iso also boots the bios. ^_^
Note: it has to be run from the command line, and not from codeblocks to actually have the ZZOgl window come up.
(And, of course, the GSnull plugin should work just fine in CoLinux, though you won't see anything. You could probably hear the bios sounds, at least... )
Yeah the plugins are currently loaded on the Core thread, which is probably bad. My next commit will have PCSX2 load them on the gUI thread instead, which Linux should be happier with. ;)
Given that gtk is picky about threading, that's probably for the best.
Irritating thing on not loading the iso is that it displayed the full location of it in the menu, so I know it knows where it is...
Currently everything boots through the BIOS. Tho if you still get the BIOS menu and no recognized DVD image, then that's a problem. If you get a memorycards + DVD screen (and you can try and re-run the DVD) then it means your bios doesn't like your DVD image -- like a PAL/NTSC incompatibility that might happen with v2.0 bioses.
Same thing should happen on regular old trunk pcsx2 tho.
Oh! And is Linux on your side reporting complete bupkis for CPU speed and core counts? I'm not sure if the crap values I'm getting are because of co-linux or something else.
No, they look about right.
And looks like it was just the "configure your bios" screen that was screwed up. Wouldn't be surprised if that's screwed up in the main branch, too.
I think it wasn't loading the isos because I hadn't set that up (since I didn't realize it was going through the bios right now.)
Now that I set it up, it segfaults, instead. Time for me to check the segfault handling code...
On second thought, given the message, that's in place. I'll try a different game.
It was game specific. Guess Baroque doesn't like being booted through the bios. Disgaea started up without an issue.
BTW, I suspect before the merge that it'd be a good idea to tag the current main branch...
Oh, and exiting pcsx2 or resetting pcsx2 segfaults, btw, but I think you knew that.
The one on exiting is in ProgramLog_PostEvent when checking to see if m_ProgramLogBox is NULL. Got to love it when it crashes on safeguards meant to prevent it from crashing. I'd presume it's trying to do something with the console window after it's gone...
Yeah, it's trying to do something with the console *after* ~Pcsx2App was called.
Specifically, it's trying to do the SysReset in ~Pcsx2App, which has a console message in it.
>> The one on exiting is in ProgramLog_PostEvent when checking to see if m_ProgramLogBox is NULL. Got to love it when it crashes on safeguards meant to prevent it from crashing. I'd presume it's trying to do something with the console window after it's gone...
Close. It's actually trying to do something with the wxApp and it's been deleted too by then. ;) I can add a test against wxTheApp != NULL and fix it.
Yeah, changing:
if( m_ProgramLogBox == NULL ) return;
if ((wxTheApp == NULL) || ( m_ProgramLogBox == NULL )) return;
in ProgramLog_CountMsg and ProgramLog_PostEvent does the trick.
hey Jake, I was wondering if you're going to resume your work on the R3000 Air compiler after wx?

Revision 1751

wxgui: sync with trunk (microVU + ee loadstore cycles + improved plugin
* Fixed crash on exit, caused by logging.
* Updated versioning in main window and console.

Revision 1752

wxgui: Hack in game fixes support. Fix a few minor compiler warnings. Fix Linux
after the last revision...
Sadly, I tested the game fixes by verifying that turning one of them on breaks one of my games... ^_^
And, yes, there are better ways to do the game fix support. For example, if we had the game fixes set up as a union as well as bit flags, the code to set a game fix could have been one line...
All of the options should be unions, in fact. I used handy macros to define them as such. :)
And I see that I haven't added the EmuConfig to AppConfig, so the emu options aren't being managed correctly by the App yet anyway. I'll get that fixed in a bit. (yes there will be 2 copies, the global one used by the emulator, and a local one managed by App hich it "applies" to the global EmuConfig only once the emulation state has been safely suspended and such).
Also I created some wikis for basic wx coding guidelines and stuff. I'll get those posted now. :)
Oh, right, like the ones in GSdx. Didn't notice that.
Oh well, this works for the moment. We can always recode it later.
My main motivation for changes to it is to make it easy to add and get rid of game hacks. The fewer places you have to change for it, the better...

Revision 1753

wxgui: Get the savestate menus ready to be hooked up.
While I didn't actually hook it up, everything's ready for it. I figured that if hitting Reset crashes pcsx2 right now, hitting save would, too, so I didn't bother.
But the codes all there, and even picks up on which savestate to work with.
And I arbitrarily changed the number of savestates in the menus to match the number available through the function keys. Since the f-keys aren't available right now, it seemed appropriate...
Just realized that I forgot to remove the (id == -1) stuff. It isn't necessary; I figured out what I'd been doing wrong, but forgot to remove the check...
1 line-by-line comment
line 200:
200: ConnectMenu(i, Menu_LoadStates_Click);
wx has built in range support in Connect(), so you can do this instead of using for():
Connect( MenuId_State_Load01+1, MenuId_State_Load01+10, wxEVT_COMMAND_MENU_SELECTED,
wxCommandEventHandler(MainEmuFrame::Menu_LoadStates_Click) );
We should create a ConnectMenuRange macro for it since we're using it a bunch now (there are three other instances at the top of ConnectMenus)
My first line-by-line didn't really come out like I wanted. I wanted line 199 and got 200. But it was fun to try! heh
Ah, right. Hadn't had to do that before, and the docs are pretty slender on Connect...

Revision 1754

wxgui: Fixed a crash when configuring the Firewire plugin from the Firewire

Revision 1755

wxgui: Get the speed hacks squared away.
It was functional, but the sliders weren't working properly on the top, and the checkboxes would clear themselves. Both have been taken care of.

Revision 1756

wiki: Added new pages for wxWidgets tips and other coding guides/strategies.
The Translation Guide is effectively a draft, but since I was committing several wikis at once I figured I'd roll it on in, so that we can see it as it is.

Revision 1757

wiki: Added some links and minor fixes to the RevisionReviewEtiquette
Just some minor grammar/spelling stuffs:
line 4: it's->its
line 12: an->and

Revision 1758

wiki: Fix unicode quotations, which showed up properly in the wiki preview box
but broke once the wikis were put on svn. >_<

Revision 1759

wxgui: Some quick cleanups of my earlier commits.
And with that, I'll stop committing for a few hours...
My next commit will probably break linux, because I'm removing the .h files for bundled images and setting up a script to generate them from the .png/.jpg originals. As soon as that's committed, I'll swap branches, and then we can work on getting the scripts re-set for Linux.
(shouldn't be hard, the build script is very simple, a 2-line bash script do the job)
All right. Seems like we could just make an image directory, and load them dynamically, though.
I don't really like that method because most of the images are pretty well fundamentally important to the emulator's running, and especially as we fancy up the GUI more with toolbar icons and such it will be more important to have built-in resources.
Right now the only things *needed* to have PCSX2 load are:
w32pthreads.dll (win32)
null plugins
Everything else is pretty well optional.
For example, it really annoys me when some programs "Require" language files and then if for some reason my english language file is missing or is outdated I get crap messages like "@5012" instead of text. And likewise I'd rather not have the PCSX2 gui come up blank as a white chalkboard if, for some reason, it can't find the resources needed for icons, background, and other GUI buttons and stuff. :)
There are points to that, I suppose.
I suppose I just like things easily skinnable. I could see the potential issues with the way it can be configured to look for files, though.
Oh it's already going to be skinnable.
In fact if you drop resources into a resources folder of some naming scheme I forget immediately, I'll use those instead of the built-ins. :)
Ah, so these, essentially, are the default images. Cool.
You know, it wouldn't be that difficult to set it up so that you could have multiple skins, and choose between them in pcsx2.
Not high priority, but could be fun. We could include some of the runners up to the background that won that way...

Revision 1760

wxgui: Updated to the new logo and about box pic (about box layout still sucks
tho). Redid the built in resources so that they're automatically compiled from
the original images, instead of having the bulky .h files on SVN (includes
updates to bin2cpp tool).

Revision 1761

wiki: uploaded images for a new compilation guide (work-in-progress) as provided
by n1ckn4m3. :)

Revision 1762

Goodbye old GUI. For you served us well!
... well not really.
I'm upping the new merged trunk now. It'll take a while tho (possibly up to an hour) because of all the changes and my slow upstream. >_<
No worries.
I just did the minor changes necessary to port bin2cpp.cpp to Linux. _stat to stat, _fcloseall to fcloseall, and replacing strupr, really.
I did contemplate rewriting it in Ruby for a few minutes, but decided I didn't really need to add a dependency, even if it would look nicer...
And it's up...

Revision 1763

Reintegrated wxgui branch into trunk.

Revision 1764

wiki: Completely re-wrote Windows Compile guide to be current, including all
current dependencies and SDKs, configuration of VS2008 Standard, screenshots of
the process. VS2010 and VC++2008 forthcoming.
Awesome work n1ckn4m3, I'm amazed by the detail and the clarity of your wiki :)
Thanks for the help
Awesome indeed.

Revision 1765

wiki: Wouldn't be a first commit without a typo :P

Revision 1766

Get bin2cpp to work on Linux. (Linux compilation is still broken.)
Basically, rebuild.sh has to be run before opening codeblocks, or it will complain about a bunch of missing files.
However, compilation will error out on the line:
EmbeddedImage<res_BackgroundLogo> temp;
Claiming that res_BackgroundLogo is not declared in the scope.
Because the shell script names them the wrong names, because I based it off the other one. All right, I can fix that...

Revision 1767

Correct the script, so that Linux is compilable. (If rebuild.sh is run before

Revision 1768

wiki: Updated compile guide for Windows to include all instructions necessary to
configure a build environment based on the freely available Visual C++ 2008
Express Edition and enable PCSX2 to run in the debugger of it.

Revision 1769

Made mVU Macro ON by default again (got turned off by wx merge).
Added microVU speedhacks to GUI.
Deleted microVU_Alloc.h from project file.
Note: No speedhacks appear to be working yet during emulation.
Forgot to mention I Added microVU_IR.h to the VS2008 project file.

Revision 1770

Fixed a crash when clicking "Exit" while emulation is in progress.

Revision 1771

Created project files for all the null plugins, and added them to codeblocks.
These haven't been extensively tested, beyond being sure they build.
And I haven't gotten them set up for Windows, though Code::Blocks is cross-platform, and could theoretically be used for both.
Still have to do this for the various Linux plugins that actually do things.
I already did OnePad, and tried on ZeroSPU2, but didn't get it picking up on soundtouch properly.
I'll probably create a project file unofficially for ZZogl at some point, after I do ZeroGS, and send it off to Zeydlitz, if he doesn't do one first.

Revision 1772

Reanming Tools to tools (better fix this now while the folder is insignificantly
in case you're curious, I didn't even bother with a makefile to compile bin2cpp.cpp. I just typed:
g++ bin2cpp.cpp -o bin2cpp
at a command prompt. ^_^
I figured with such a short program that there really wasn't a need for anything more elaborate then that.
Yeah, I noted .. but I couldn't really put the neat "dependency" check mark in the pcsx2 project file so that it'd automatically get rebuilt as needed. Except apparently it doesn't work anyway in Code::Blocks. Oh well.

Revision 1773

... and because svn can't do direct casing changes, it requires 2 commits. -_-
I'm going to fix the linux build system now. I have a plan!!
A cunning plan? ^_^

Revision 1774

Linux: Using Code::Blocks Custom Compile option to generate embedded resources
now. :)
Ok, I set bin2cpp to be a dependency of PCSX2, but it didn't seem to want to work for some reason. Not sure why. So bin2cpp might not be automatically built as it should, prior to PCSX2 being built. In that case manually build it. ;)
But it would be nice to get that part working. Then the whole build should be fully automatic.

Revision 1775

Linux: Remove code::blocks layout files (those are client/user files, not
intended for svn).

Revision 1776

wiki: removed the old compilation guide.

Revision 1777

wiki: and today is the day I learn that I've always misspelled Deprecated as
'depreciated' and didn't know I was spelling it incorrectly.

Revision 1778

* Added preliminary keyboard support back in (probably doesn't compile in
* Fixed a deadlock in thread cancellation.
* Muted some folder warnings when running pcsx2 for the first time.

Revision 1779

* Implemented Skip Bios (settings still not saved tho)
* Fixed a bug in how I was (not) handling pthreads return codes. It's errno
you need to check, *not* the function's return value. ;)
* Changed MTGS over to use the pthread_cleanup api.
Just tested, and on Linux, checking 'Skip Bios' and starting a game results in:
PCSX2 > # Initialize Scratch Pad ...
PCSX2 > # Restart Without Memory Clear Done.
terminate called after throwing an instance of 'Exception::ExitRecExecute'
(Don't have time to fiddle with it at the moment, though, unfortunately...

Revision 1780

Linux: Fixes some of those pesky linux compilation errors that keep cropping up.

Revision 1781

Linux: More fixes, because I got impatient and didn't wait for the compilation
to finish last time.

Revision 1782

Got rid of that old 'params' mess on console logs. Not needed anymore since
wxwidgets has nicer built in formatting options (never liked it anyway)
yeh i didn't like it either xD
same :)
Yeah, don't know how many times I forgot a param or two...

Revision 1783

Upgraded PCSX2 core and utilities to GPLv3.
Nice. Did you check if updating the GPL conflicts with the license of other open source libs we are using?
It's fine with wx, soundtouch, zlib/bzip2, and pthreads. I think that covers all of them.
(actually I don't think there's any scenario where v3 is more limited in license compat than v2. v3 is compat with almost every known open source license while v2 was actually incompat with all Apache licenses and various versions of the BSD license >_<)
OK good to know :P

Revision 1784

Updated to the new icon! So sleek...

Revision 1785

Use right AppIcon.png

Revision 1786

wiki: wxWidgetsCodingStrategies - Added note about sending events properly.

Revision 1787

Added / Changed some descriptions
Yay tooltips.
And yes I know tooltips need some text wrapping features. It's on the eventual todo list :)
That one ling got a bit long, I know.
Didn't want to screw up the layout :p
Actually, with regards to the MPEG Hack, it is already working. I changed it over from the define to the bitfield when I added it in...
Ah ok, I just didn't want people to go all like
"Get this wx revision, it has a mana khemia hack!!"
and then it doesn't work :P

Revision 1788

* Better icon! Transparency in Windows Taskbar icon is still bad, but I can't
figure out how to fix it (documented in code)
* Cleaned up the code of the Gamefixes a bit.
* More svn:native props -_-

Revision 1789

Update libpng.

Revision 1790

Fixed Linux up to compile in codeblocks again. Added Onepad plugin project file.
And yes, that change to interface.c in onepad is a hack. I figure the next time I change the interface on it will probably be to redo it in wxwidgets, anyways.

Revision 1791

Added libjpeg (version 7!)
Obviously this is a Win32-only kinda thing, since these sort of 3rdparty libs usually come in convenient shared linkable form in Linux already.
@arcum: I know gamefixes aren't working again I'm fixing it so that the ApplySettings command in CoreEmuThread works as it should, and then applying settings from dialogs will be thread safe :)
No problem. I know things are likely to break right now.
While were in the middle of the wxwidget changes is a good time to break safefiles, in fact, if we want to change any of the frozen variables, or get rid of anything legacy.
I know there are a few ints I've been meaning to change to bools for a while...

Revision 1792

Win32 project fixings: Removed the dysfunctional ZeroPAD from the Suite
solution, and cleaned up some options in the wxWidgets projects.

Revision 1793

Implemented plugin override command line options, and preliminary support for
proper EmuConfig ApplySettings.
doh, this revision will break configs in Linux >_<
... I was in the process of tring to troubleshoot some odd problems with Lilypad's configuration. Turns out LilyPad uses SetTimer (WM_TIMER stuff) and for some reaosn it's busted in wxWidgets.

Revision 1794

Fix for GSdx's config panel making PCSX2 minimize itself. (also revert
accidental linux config panel breakage)

Revision 1795

May or may not fix certain failure to bind issues. May or may not cause issues
in canceling binding when using mouse/keyboard to navigate the bind window when
the corresponding mode is set to disabled. May or may not result in Armageddon.
Probably not. I hope.
LilyPad, of course. No other part of PCSX2 could possibly be capable of causing Armageddon.
Works here in wxpcsx2. Hopefully it doesn't break anything in regular old pcsx2. ;)
Lol, I wonder what's with the ambiguity.
Works fine here on wx :)
Lack of MS specifications. I want to cancel binding if, for example, mouse mode is set to disabled and you click on another control (Like the ListView or something).
The old code used random extra WM_NOTIFY messages to help detect this. Microsoft doesn't provide any clear cut tampering with other control event.

Revision 1796

mVU: Experimented with some code to clamp every ADD/SUB/MUL/DIV operation.
Code is off by default, broke a lot of games...
This confirms my theory that the best way to handle clamping is to limit the
clamping to places we've tested fixes games.
"This confirms my theory that the best way to handle clamping is to limit the
clamping to places we've tested fixes games."
Yes it may sound hacky, but the whole idea behind clamping is a hack since we're effectively dealing with a loss of information.
And another point to make is that if a reg holds a NaN value, we don't know if that reg was initiated with the NaN as a valid value, or if another part of pcsx2 computed the NaN as an invalid result value.
For this reason, using double-floats or any other attempt will still have problems.
The only way to rid us of the horrible nan/inf/clamping problems, is either:
1) Every possible floating point operation was software emulated (ensuring that no NaN was due to an invalid floating point exception).
2) We have a CPU architecture that doesn't support NaNs and Infs, or allows us to turn it off.
Neither seems likely anytime soon.
So IMO, pcsx2 will have NaN/Inf problems possibly forever.
Which brings me back to my statement, the best way to handle this is on a game-to-game basis with testing.
And if clamping something fixes one game, and breaks another; then we will have to have special game fixes or game-clamp-profiles.
I feel a tad bad commenting on this since I haven't been doing anything Pcsx2-related in a long while, but:
It seems to me like functions that use the clampOp macro do not necessarily have an allocated 't1' reg - which is used by clampOp, leading to a bug.
Anyway, clamping worked fine in sVU (aside from the small issue where the clamped values were being written back to the source registers) so I don't see any reason why it shouldn't work fine anywhere else.
As you said, it's important to distinguish between "large PCSX2 values" and "actual NaNs", but this is easier than it sounds:
If an ADD/SUB/MUL/MAX/MIN operation has non-NaN and non-INF values as its operands, the result will be at most an INF, never a NaN.
For example, ADD/SUB only return a NaN in the "INF - INF" case (or when one of the operands is already a NaN) and MUL only returns a NaN in the "0 * INF" case (or when one of the operands is already a NaN).
For division and the like, special care for division by zero is needed, but that is already treated as a special case.
By the way, ADD/SUB/MUL/MAX/MIN will never even generate an INF if the rounding mode is 'zero' (which rounds overflows towards zero, producing the largest possible value instead of infinity), so no result clamping is needed then.
AFAIK, if all VU operations are operand-clamped and no bugs with the clamping exist, the results should be always better than with no clamping: a large incorrect value is better than a propogating NaN.
"It seems to me like functions that use the clampOp macro do not necessarily have an allocated 't1' reg - which is used by clampOp, leading to a bug."
when t1 is -1, then my clamp functions use my regAlloc class to allocate a temp reg.
also to confirm its not a reg-trashing problem, i also tested my clamp mode using just mVUclamp1(), which doesn't use any temp registers (and the problem is exactly the same).
so i know the clamping works, the problem is for some reason clamping on a few cases is breaking games.
(SSE_ADDSS and SSE_MULSS seem to be the picky ones).
"AFAIK, if all VU operations are operand-clamped and no bugs with the clamping exist, the results should be always better than with no clamping: a large incorrect value is better than a propogating NaN."
That was my thinking as well with this experiment, but so far its proving to not work out good.
There are still a few more cases where I haven't clamped, so I will finish implementing this idea and see how it works out.
But you also have to remember that even Extra clamp modes on sVU don't clamp everything.
"By the way, ADD/SUB/MUL/MAX/MIN will never even generate an INF if the rounding mode is 'zero' (which rounds overflows towards zero, producing the largest possible value instead of infinity), so no result clamping is needed then."
Yeh I remember what you told me about that; mVU using "normal" clamp mode only clamps operands (and not results) due to this.
(But it only clamps on selected instructions that have proven to fix games)

Revision 1797

Got rid of various obsolete files, and moved the codeblocks workspace file.
Yeah moving the workspace to the top-level folder was on one of my eventual todo lists. :)
I thought I remembered seeing it there, and, well, it makes more sense there and is more convenient.
I thought about moving pcsx2.cbp to the pcsx2 folder, but it seemed like too much hassle for the moment...
I thought I remembered seeing it on your to-do list, and, well, it makes more sense at the top level and is more convenient.

Revision 1798

Fixes some warnings and a compilation error in Intel C/C++.
We *really* should have CALLBACK specified on all the plugin CB functions, but it'd break backward compat with existing dev9, usb, and spu2 plugins. The point of using CALLBACK on all the plugin bindings is to allow a plugin and/or PCSX2 to pick their own default calling conventions for functions. But that methodology fails due to the lack of CALLBACK on the plugin callback functions. >_<

Revision 1799

Added more plugin project files.
Note: ZeroGS compiles, and appears to run from codeblocks.(I'd do ZZogl, but it's not in the tree, unfortunately)
SPU-X doesn't compile under Linux right now.
ZeroSPU2 compiles, but won't load in pcsx2 if you compile it from Codeblocks, because it isn't linking with soundtouch properly yet.
They way I determined it was a soundtouch issue, for reference when trying to get things like, say, spu2-x working, is that when it enumerates the plugins, it gives the following error:
wx > /usr/local/src/pcsx2/bin/plugins/libZeroSPU2.so.0.1.0: undefined symbol: _ZN10WavOutFileC1EPKciii
If you then run:
c++filt _ZN10WavOutFileC1EPKciii
it returns:
WavOutFile::WavOutFile(char const*, int, int, int)
Which is the unmangled name of the function it can't find. Which is in SoundTouch.

Revision 1800

Emulation options (speedhacks, CPU, etc) should work now, and fixed a few
memleaks on exit, and crash-on-close bugs caused by more mis-used pthreads
timedwait parameters.

Revision 1801

Two more lockup fixes, and changing plugins takes effect without restarting now.
I broke something in the either 1798 or 1800 that seems to be corrupting memory, and I have no idea what. I'm leaving for 2 days, so hope someone else can figure it out.
Whenever I hit esc and *usually* when I close the emu, it crashes in GSdx with memory corruption issues.

Revision 1802

Re-fixed bios skip hack, and fixed stack overflow when using CDVD plugins.

Revision 1803

Cleaned up Path namespace and moved it and wxDirName to /common/Utilities.

Revision 1804

Re-ordered the MSVC folder structure to split PCSX2 into two definitive
sections: [App]Host and [Emu]Core (the bracketed names indicate the "long"
versions which are generally used in the code to differentiate the functions and
classes). If the tentative layout is good then I'll sort the files on SVN to
match that layout.
(note: Patch.cpp/Patch.h is still the odd child out in this commit, as it's
destiny is to become a plugin)
Notice also I finally got rid of Misc.cpp and Misc.h -- a long-overdue clobbering of some fairly sloppy source files. ;)

Revision 1805

wiki: Added troubleshooting to catch 99.95% of build environment errors.
Removed C# from default install, added to troubleshooting/workaround section.
Removed reference to deprecated wxGUI build workaround. General clean-up.

Revision 1806

Fixed a compiling error.

Revision 1807

Fixed a compilation problem for release builds. I assume the functions in
GSState are currently supposed to be dev-build only? :)

Revision 1808

Did a cleanup and organized EmuCore's virtual folders.
@cotton: I think instead of putting MemoryCard and BIOS in their own folders we can leave them top-level and just put all the .h files in an Include folder (since at least for me the only time I ever load .h fils is through the msvc intellisense -- Ctrl+F12 and/or right click and going to references).
... Unless there was another reason besides display brevity for nesting them inside BIOS/MemoryCard folders?

Revision 1809

Corrected some missing GPLv3 headers that somehow got missed in my first pass.

Revision 1810

Highly experimental DS3 support added. Use newly added features at your own
risk. Requires libusb installed and DS3 set up as per instructions at
http://forums.pcsx2.net/thread-7582.html. Doesn't require
sixaxis64.exe/sixaxis.exe, but might have to fool around with starting/stopping
Pcsx2 or LilyPad's test device screen and the PS button on your controller until
the "1" light turns on.
One of these days, I'll remember to prefix my commits with LilyPad....
SixAxis probably won't work, since I have the product id hard-coded.

Revision 1811

LilyPad: Fixed DS3 motors being flipped, setup default motor bindings on
creation, and reduced delay to make sure pads have been initialized when testing
force feedback (Probably get rid of it all together once I implement a

Revision 1812

wiki: CompilationGuideForWindows updated image - removes c# as a
suggested/required dependency.

Revision 1813

gui: Now uses new plugins to check if selected plugins when clicking "Apply" on
plugin config screen rather than the old selected plugins.
*To check if selected plugins can be loaded

Revision 1814

Gui: Fixed fix. Last fix was close, but a couple lines too high. Oops.
Almost, yeah. It should just be before the if( pi->shortname != NULL ) check. My bad.
I wasn't sure if it was mattered while cleaning up the plugins or not. Thought not, but really didn't feel like spending the time figuring it out, as you'd probably know instantly.  :)
It's probably better yeah if I set LoadPlugins() to use a customized/specified conf source. Might be useful for other things down the road, like command line ops or something.

Revision 1815

LilyPad: DS3 no longer disconnects when vibrating. Partial workaround for a
DirectInput threading issue when vibration is triggered at the same time devices
are being added/removed - probably do something better at some point. Some
other DS3 related changes - change names of some controls, increased sensitivity
of boolean buttons values to more closely match the DS3 as well. Poorly
calibrated analog axes bound to the d-pad (Or buttons) may cause issues.

Revision 1816

Fix a few Linux things.
I'm sick right now (been so for a few days), but wanted to at least patch Linux up to compile again. I left a few changes I'd made before then, too, since I was doing a bit more prep work on getting spu2-x to work on Linux.
Hope nothing breaks, because I'm getting ready to head back to bed. (In fact, there are more changes that need to be made to spu2-x before it'll compile in Linux, but I left them out, because I didn't want to risk breaking anything)
I'm headed back to bed, though...

Revision 1817

Fixed a bug in BiosTools.cpp that caused Bios-Not-Found errors.
MemoryCard / Multitap Renovations:
* Memorycards should now support multitap (somewhat untested)
* Implemented a memorycard plugin interface, using the new API defined in
PluginCallbacks.h (still prelim and hackish)
* Memorycard settings are saved to ini!
* Multitap is now controlled by PCSX2 instead of the pad plugin (which means no
multitap until we implement the gui toggles to enable it)
I'm fixing some Linux compilation errors now.

Revision 1818

wiki: Made all screenshots clickable thumbnail links to make the Windows compile
guide about 900% more readable. (Thanks bositman + JakeStine :))

Revision 1819

Linux: Fixed compiler errors from my prev commit, along with a few verbose
warnings and a compile error in SPU2-X. (note, moved Linux's define of SVN_REV
macro to PrecompiledHeader.h for now, until a proper solution is implemented)
Oh, forgot to mention, this fixes the bin2cpp dependency problem too. bin2cpp will always build before it's used by codeblocks to generate embedded resources. :)
@arcum: btw lemme in on the secret to getting alsa to compile and I'll help on spu2-x sometime (it can't find the header file, and I sunno if it's a missing package or a missing compiler define -- I installed just about every alsa package I could find...)
Well, I use Gentoo, where they give it the obvious name of "alsa-headers" (and where you usually automatically have the dev files for anything you install...), however, I think that in Ubuntu it is 'libasound2-dev'.
In the build options I set asound up as the library to link to, so I'm pretty sure that would be it.
The other issues I run into compiling it are that it doesn't like inlining MulShr32, StereoOut32 clamp_mix, & SPU2_FastWrite (which is an error in debug mode, as you might recall from microVU), and sprintf_s & swprintf_s are Microsoft's.
Once that's out of the way, it compiles. Of course, it won't load, so long sessions using c++filt are in order...
It'd be great to get spu2-x multiplatform, though, and when we're giving pcsx2 a makeover is probably a good time.
Of course, I started working on it again because I was setting up project files for all the buildable useful Linux plugins. Otherwise I still have to keep the batch file around...

Revision 1820

Rewrote _gifTransferDummy for Path1 transfers (VU's xgkick), now it properly
supports wrapping around VU memory without any hacks (hopefully fixes some
Path2 and Path3 still use the old function since I need to do more research on
them and how pcsx2 is emulating them...
If this commit breaks anything let me know.
As far as I know, GIFtag transfers along Paths 2 and 3 can be partial, so the logic needs to consider both size (DMA-controlled) and nloop/eop factors. But that's just based on the old code, and I'm really not sure if that's handling real game logic sense, or just some mumbo jumbo that got coded in because everything else was so buggy.
Also, I see no errors in this code. Logic paths all look infallible from here.
Yeah that side was fine. i had written all the stuff required on the PCSX2 side, however a change is needed on the GSDX side for path1 transfers for it to work correctly, else it does startaddr - memend on the vu's which is incorrect for activision games like tony hawks and guitar hero 3+.
If you want to look at the change required, just look for the path transfers stuff in gsdx and make path 1 do the same as the others :P
That shouldn't be a problem. The code in GSdx is only invoked if the "size" parameter is incorrect (ie, mismatched to the actual concatenated/wrapped packet size). Cotton's implementation measures the size correctly and so GSdx doesn't cut the packet short or decide to do its own manual wrap-arounds.
So work on this has started :p

Revision 1821

LilyPad: Force feedback threading fix. DualShock 3s initalize much more
Still have issues with DS3 rumble - looks like only one motor can be enabled per
communication (Otherwise, always lose connection to the device and have to re-
enable it), and enabling one kills the other. Not sure what to do about this,
currently just flip between the two.

Revision 1822

LilyPad: DS3 tilt support. Why? Because it's there. Can't think of a sane
use for it, though.

Revision 1823

legacy ui: tweaked pay/keyboard handling, might fix some cases where esc
wouldn't work with certain pad plugins.

Revision 1824

legacy ui: merged cottonvibes' new GIFtag handler so that it's more testable. :)
Alright, it's indeed better to test it with the familiar gui (and savestates ;) ).
I'll be running my games when I get the time. Lots of real life stuff atm :p
Speaking of savestates, I'm working on those now! Along with other major revamps of memory and resource management. >_<

Revision 1825

wiki: Cleaned up a formatting error, fixed a typo in a command name (great place
for one), and removed Team System references.

Revision 1826

LilyPad: Minor improvement writing to DualShock 3 device - lights should
generally be updated fairly promptly now, rather than depending on how/when the
device is initialized. Also removed CRT dependencies, so the MSVC 2005 release
build compiles again.

Revision 1827

gifTransferDummy() now handles path2 and path3 transfers.
Hopefully doesn't break anything :)
eh I meant the new gifTransferDummy function.
The old one already handled those paths of course xD
PATH3 at least is broken, good luck on that one :p
Oh, games that use PATH3 include Persona3/4 and Suikoden5.
Ref will know tons more :p
(nevermind, forgot that I set it so PrepDataPacket didn't do the copies itself)
Oh I see, the Path3progress status vars *were* used in the other transfer. That's what broke things. You removed those on the premise they always get set to STOPPED, but that was when you assumed all transfers process until an EOP like on PATH1. But PATH3 can stop anytime, EOP or not, so the Path3progress status var updates need to be re-included.
Ok, so that was a rather small fix. Didn't think it'd be :p

Revision 1828

Reimplemented Path3progress status var, and set incPmem to count in QWCs
Dah, I did the braces wrong in the macro. Supposed to be (x)*16, not (x*16). Won't matter anyway since none of the inputs cause order-of-operations problems... but yea. Macros. >_<
(the sad part is that MSVC treats templates the same way)
Yep, this fixed my test games.
And the code still looks clean :)
hmm i see, yeh i forgot about partial transfers with path3 making the status var != Stopped xD

Revision 1829

Added some missing logic to gifTransferDummy() which takes into account
completing partial transfers.
For example, if a path3 transfer has a giftag with nloop = 30, and we only
'looped' 20 times, then the next time gifTransferDummy() is run for path3, it
will treat the incoming data as the rest of that gs primitive (instead of a new
giftag), finishing the rest of the 10 loops. (Then it just continues normally,
treating the next 16bytes of data as a new giftag...)
Its odd that I wasn't doing this before and games seemed to work fine, but might
be needed for a few games...
Sadly these changes made the function more complex; but I guess that's expected when you need it to account for more stuff.
Was the old dummy handler doing it this way?
And iirc GSdx does the same logic as well, what about that one?
Sounds reasonable to me though it should account for partial transfers this way.
Ah yes, lemme guess:
The old handler did this, and a bit more? :p
The game gran tourismo 4 crashed on going ingame with the rev before this.
With this rev, it goes ingame, but many graphic elements flicker.
It looks like before Ref made changes to vif1, just worse.
Other games I ran were all fine so far.
VIF1 is PATH2. There could be some bugs in how PATH is handled, both on VIF side and/or in cotton's new code. Cotton said that PATH2 was behaving erradically, and not getting EOPs (which is very bad -- on the real PS2 hardware that would have caused the GIF to perma-stall on PATH2, basically).
I'm going to remove the hasRegAD "optimization -- it's created way more code than it's worth. I think the whole of GIFtag will be faster without it now, and more importantly we'll not be able to use that opt with the new GS pluign anyway. ;)
Ok, I'm having trouble getting this to work and I don't have time to work on it right now.
But these are the problems I've noted:
a) we need to re-add the old code for StepReg(), because transfers *can* be partial all the way down to any arbitrary qword. path.StepReg() was there to serve the purpose of retaining that value.
b) We need to have a copy of nloop in GIFpath, and use that to retain nloop status between calls to dummyPacket.
c) We need to use that nloop value to decide if/when to load a new tag, and get rid of all the pathContinue hackery in the process.
I have most of this coded locally, but I've missed.. something. It can't boot the BIOS.

Revision 1830

Applied GIF PATH2/PATH3 fixes from trunk, and unbroke STGS from the last legacy
rev. ;)

Revision 1831

Legacy GUI: Revert to use sVU for VU0 macro for now, since mVU is missing some
clamping yet.
There's too much stuff going on at the same time currently, and we know the missing mVU macro clamps cause a few games to hang or error.
Proper clamping should be thought out a bit, brute forcing all those MUL and MADD opcodes would be slow ><

Revision 1832

Yay, craploads of fixups for the new gui:
* Lots of crashfixes and threading rules compliance (like using wxYield instead
of ProcessPendingEvents)
* Killed off some memory corruption
* Better error handling and reporting
* Much speedier suspend/resume during emulation
* Revamped entire savestate system to use a RIFF-style file format (untested,
will work on it soon)

Revision 1833

wiki: Removed instruction to add PCSX2_TARGET_COPY to System Variables
(unnecessary). Added information required to ensure gsDX debug builds are
enumerated and usable in PCSX2.

Revision 1834

Let's save the SkipBios hack setting, because people hate me enough already for
putting this off a week.
Don't spam the comments!! >_<
Don't spam the... ! eh, nevermind. :|
Wait, it doesn't work! :p
Huh? Spamming the comments seems to be working fine.

Revision 1835

Fixed a compiler warning from pcsx2.
Fixed some bugs I noticed in my gsDummyTransfer() funct; idk if it fixes GT4
since my game isn't running on pcsx2 anymore (its always been a pain for me to
get my version to work)
Anyways, going to rewrite the function again using a simpler algorithm thats
less likely to messup.

Revision 1836

Linux: Fix some of the standard issue compiler errors that come with any
changes. :)

Revision 1837

wxWidgets: Hooked up plugin config menus in main window.
LilyPad: Couple very minor string/menu changes, no functionality changes.

Revision 1838

LilyPad: Fix for some bizarre issue with wxWidgets involving property sheets,
Microsoft, spec violations, and gremlins.

Revision 1839

Re-fix win32 builds. Stupid C++ templated class inheritance fail.

Revision 1840

Added a GSopen2 call to the GS plugin API, which is used by PCSX2 to specify its
own window handle.

Revision 1841

Branch made for working on proper implementation of the new GSopen2 into GSdx.
I might make changes in this branch to implement GSopen2 in other plugins as well, if you don't mind...
(Yes, I'm thinking of setting up GSnull to use pcsx2's built in window...)
Yea sure, go for it.
Thanks. It's less hackish then the ways GSnull usually gets a window handle. (And it needs one for pad plugins to work.)
Looks like GSnull doesn't compile right now in Windows, and pcsx2 doesn't compile in Linux at the moment after the GSFrame additions.
The latters probably easy to fix, but I'll get some sleep before looking at it...
(The formers probably easy to fix, too; I just rarely check on it.)

Revision 1842

GSopen2: Current status...
* Software mode seems to work fine. Suspend and resume emulation work nicely,
without flaws.
* Hardware DX9 mode suspends but displays only black after resuming.
* Hardware DX10 status is unknown.
Drk or Feal87, I need some help on this if possible. I'm not very good dissecting D3D API behavior and I'm not sure why it's getting blackness when recovering from a suspended state.
Nice change but GT4 NOT WORK!! WHY???? Black screen video no work cannot live without gt4 video :(
Other than that, will try it out on DX10..oh wait does this gsdx still need those crappy ogl dependencies?
Pause in dx10 mode works, resume causes the GSdx window to do nothing.
Reset after all this recovers the GS window.
Pause in dx9 mode works, resume causes the vga driver to crash (from the looks of it).
PCSX2 crashes after that.

Revision 1843

Minor fixes for interlocking against the threaded plugin loader (running a game
too quickly could cause crashes)

Revision 1844

Linux: added missing files, and switched from my own WindowDisbler hack to wx's
built-in wxWindoweDisabler hack. :)

Revision 1845

Linux: IsRunning was crashing pcsx2. Also, jNO_DEFAULT isn't a good idea in
these two spots.
IsRunning was crashing on pthread_kill when you told it to start an iso before this change.
And jNO_DEFAULT isn't a good idea when the values can be changed by hand in an ini file.
Indeed, you are correct sir.

Revision 1846

GSdx: Fixed GSDialog so that it doesn't cause PCSX2 to minimize into the
background when closing the config box.
PCSX2: Reloads plugins a little less often.

Revision 1847

Hook up the save/load menus and make the Linux console output somewhat less
Not that saving/loading works properly in Linux, but now the menus act exactly as badly.
And the console change was because on Writes, it was writing "PCSX2 >" before every character...
that will dump 'PCSX2 >' to the emuLog.txt as well as the Linux console, which really wasn't my intention. I'm not even sure if the 'PCSX2 >' is that useful for avg linux folk. On CoLinux I have only one console and Code::Blocks likes to spam it as well, so I had to add some tag to identify it. :)
Oh, yeah, I forgot about the EE/IOP log dumps. Those write per char instead of per line. -_-
Err, by that I mean the actual DECI2 log output from the emulated EE/IOP kernels. And admittedly it'd be nice to have those prefixed differently anyway, with a "PS2" or something to know it's coming fromt he PS2 virtual machine and not PCSX2 itself.
Point; I was just getting irritated at at constantly dealing with output like this:
PCSX2 > Write-protected page @ 0x00259
PCSX2 > Write-protected page @ 0x0020c
PCSX2 > Write-protected page @ 0x00204
PCSX2 > rPCSX2 > ePCSX2 > aPCSX2 > dPCSX2 > /PCSX2 > wPCSX2 > rPCSX2 > iPCSX2 > tPCSX2 > ePCSX2 > PCSX2 > aPCSX2 > lPCSX2 > lPCSX2 > oPCSX2 > cPCSX2 > aPCSX2 > tPCSX2 > ePCSX2 > PCSX2 > mPCSX2 > ePCSX2 > mPCSX2 > oPCSX2 > rPCSX2 > yPCSX2 > PCSX2 > 4PCSX2 > 0PCSX2 > 0PCSX2 > 0PPCSX2 >
PCSX2 > oPCSX2 > pPCSX2 > ePCSX2 > nPCSX2 > PCSX2 > nPCSX2 > aPCSX2 > mPCSX2 > ePCSX2 > PCSX2 > rPCSX2 > oPCSX2 > mPCSX2 > 0PCSX2 > :PCSX2 > RPCSX2 > OPCSX2 > MPCSX2 > VPCSX2 > EPCSX2 > RPCSX2 > PCSX2 > fPCSX2 > lPCSX2 > aPCSX2 > gPCSX2 > PCSX2 > 1PCSX2 > PCSX2 > dPCSX2 > aPPCSX2 > PCSX2 > aPCSX2 > PCSX2 > 4PCSX2 > aPCSX2 > 1PCSX2 > 7PCSX2 > 8PCSX2 >
PCSX2 > oPCSX2 > pPCSX2 > ePCSX2 > nPCSX2 > PCSX2 > fPCSX2 > dPCSX2 > PCSX2 > =PCSX2 > PCSX2 > 2PCSX2 >
Yeah since I can't actually run games yet I never got far enough to see that. :p
I saw it, and figured it wasn't urgent, but it's been on my to do list.
There are just a lot of other things on the to-do list, like the bios skip hack not working, so it hasn't been a priority...

Revision 1848

GSopen2: synched with trunk to pick up various gui fixes.

Revision 1849

GSopen2: Fixed GSdx so that it complies with the implied intent of the PS2E
plugin API, where GSopen and GSclose retain the current GS emulation state.
This required a couple significant changes:
* Removed GSTextureFX classes
* Built shaders right into GSState classes, using GSStateDX as an interface, so
that all shader caches get auto-destroyed along with GSState.
In addition to being a bit of a code cleanup, it should be a bit more efficient
too since all of the extra dereferences to GSState from GSTextureFX have been
removed. :)
Wow, where did you pull this one from? :D
It seems to work exactly like the old version and in cpu limiting scenes it's 5% faster.
Great stuff :)
Nickname reports that sometimes pause/resume won't quite "catch" and he has to resize the window for it to start updating again. Have you experienced similar issues at all?
Nope, no oddities like that.
OH I should mention that oddity was specific to DX10 only.
Yep, no problems so far.
I didn't test much though, so should it ever pop up, I'll complain :p

Revision 1850

LilyPad: Switched to using pre-compiled headers, just for kicks. Compiles
significantly faster, though it's not exactly the limiting factor in batch
Changed intermediate debug build directory, for consistency.
Added another LilyPad-only build option, to compile without CRT dependencies, as
manifests are evil.
Finally nuked the VC 2005 project.

Revision 1851

Same changes to ZeroSPU2 & spu2-x's projects. ifdeffed out a few things in
Er, "some" changes.
Mainly, I figured out how to use SoundTouch properly in them.
I wonder why forceinline causes funny problems in SPU2-x, but never really caused any issues in pcsx2 up to know.
oh, also! Try Linux with threading enabled in the PluginSelectorPanel -- I fixed some mem corruption a few revs back, it might work now.
Well, it has on occasion, but I don't normally test everything in debug mode, and debug mode is where it starts generating errors about forceinline instead of warnings.
Also, I think that having a few levels of compiler optimizations in the project (whch I haven't set back up) gets rid of some of the forceinline errors when things get optimized out.
Realistically, we should probably have a define that sets up forceinline for Windows and inline for Linux, for cases like these, though.
Oh, and spu2-x is compilable right now. The generated plugin will error out when the plugins are enumerated, but that's because there are a few functions that need implementing...
Seems like threading works in the Plugin selector panel now, as far as I can tell...
>> well, it has on occasion, but I don't normally test everything in debug mode, and debug mode is where it starts generating errors about forceinline instead of warnings.
Ah, that's why yes. __forceinline in MSVC is stillignored in debug builds. GCC should be configured to macro it to nothing if NDEBUG is not defined.

Revision 1852

wiki: Added some new screenshots, courtesy of submissions from the Screenshots &
Videos topic on our forums. :)

Revision 1853

wxWidgets: Clicking on the sliders on the hacks screen now works.
Scroll rate is very inconsistent, but that's just wxWidgets doing what it does
best (worst?)...
Also fixed a minor bug in LilyPad version labeling.

Revision 1854

Re-re-re-re-fixed the BIOS skip hack saving on exit (plus lots of code cleanups
and some API changes to saving/loading settings -- more to come).
Linux/GCC: Disabled __forceinlining in debug builds. This is the intended
design, fixes many GCC errors in debug builds, and also mimics MSVC behavior.

Revision 1855

Disabling microVU (enabling superVU) gets saved to ini now. :)

Revision 1856

GSopen2: Added GLEW as a static library dependency. We decided it's small
enough to merit being packaged with PCSX2's 3rdparty libs, and it fixes GSDX
from needing GLEW32.dll.

Revision 1857

Small fix to remove an assertion in XAudio2.

Revision 1858

GSopen2: Fixed a bug in gsdx where it didn't properly handle changes to the GS
base register memory pointer.
I also removed a lot of windowed/fullscreen mode mess, although that part is a WIP. Time to finish that up now, hopefully.

Revision 1859

Moved the GIFtag from MTGS instance status to static status, since it needs to
be preserved as part of the PS2 virtual machine state (fixes problems when

Revision 1860

GSopen2: Simplified the multithreaded and irq callback parameter passing scheme,
and made them more "robust" so that they can be changed dynamically without the
GS exploding (important with the new correct GSState preservation across

Revision 1861

wiki: Added a screenshot of some other game to our front page, upon request.
Dunno, maybe someone else has heard of it...

Revision 1862

GSopen2: Fixed legacy mode compat and STGS operation.

Revision 1863

wiki: Updated DirectX SDK to August 2009 in documentation and links.

Revision 1864

GSopen2: Detect GSRenderer changes across GSopen/GSclose calls, and preserve the
GSState at the same time. Also added proper window closure code, so that STGA
mode (legacy gui only) doesn't cause the GS window to be frightfully sticky. >_<

Revision 1865

wiki: Added that Cg documentation and example source code were not required.

Revision 1866

GSopen2: synced with trunk, so that I can reintegrate. :)

Revision 1867

GSopen2: Merge failed to record these revisions for some reason.. >_<

Revision 1868

After hours of frustration getting my gifDummyTranfser() function to work the
way pcsx2 wants path2/path3 transfers to occur, I decided to just rewrite it
again using the old gifDummyTransfer() as a base.
Fixes GT4 corrupt textures.
Again tell me if this version breaks anything...
- SMT Nocturne works again
- GT4 glitches are all gone PLUS it doesn't seem to hang anymore in specific situations :)

Revision 1869

fixed a bug from my last revision...
this gif dummy crap really killed me.
its not even very complex but for some reason i keep bugging stuff :(

Revision 1870

A few dmacReg & gifReg changes.
Forgot to take out the line:
in Gif.cpp. I'll have to remember to remove it in my next pass.

Revision 1871

Reintegrated GSopen2 branch. Rundown of new features:
* Implemented proper shader management, fixes several bugs where video would be
lost or crash, and is a small speedup.
* Retains GS state across open/close, same as every other PS2E plugin now.
* Implemented GSopen2(), which is used by wx-pcsx2 to bind the GS output to a
window handle of pcsx2's choosing.
* Retained full backwards compat with the current legacy gui. :)
Question, what is GSopen2 API for GS plugin? What should I implement?

Revision 1872

A few more baby steps toward cleaning/fixing the GIFtag parser:
* used UPPERcase to denote the original hw register tag values from the
"running sum" copies in GIFPath.
* Renamed PrepRegs to PrepPackedRegs, and optimized it so it's only run when
needed (which is anytime new set of packed regs has come into play)
* Create a copy of NLOOP, so that we leave the original intact for possible
later referencing.
* Simplified the XGKICKs use of sizes. They just pass 0x400 now.
Linux doesn't particularly like GIFTAG tag being constant, btw.
/usr/local/src/pcsx2-1/pcsx2/MTGS.cpp:66: error: uninitialized member 'GIFPath::tag' with 'const' type 'const GIFTAG'
Commenting out the const takes care of it, but I thought I'd run it by you, especially since I still have to straighten out some changes in my current trunk that clobbered Kingdom Hearts...
Oh it just needs an empty constructor again, like the consts in the x86emitter a while back.
Oh, right, forgot about those.
Should be easy enough. Have to rebuild my current trunk first, though. Something got foobarred in it, completely outside of the changes to rbor and rbsr I was making...
Further testing reveals that Kingdom Hearts 1 is just broken in the trunk... :(

Revision 1873

GSdx: Fixes GSReplay renderer selection, and adds support for using -1 as a
renderer (uses the GSdx configured renderer, but only works if the current
working directory is set properly, otherwise the ini file won't be found).

Revision 1874

ZeroGS: Remove compiler errors under DXSDK Aug 2009.

Revision 1875

wiki: Updated to remove hard-coded table of contents to use googlecode's auto-
linking table of contents. Links are all the rage these days.

Revision 1876

wiki: Reformatted to make it much easier to read and easier to click through if
you're looking for something specific.

Revision 1877

legacy_gui: removed the localized plugins folder and replaced it with an
svn:external that checks out the trunk plugins instead (since only pcsx2 itself
has a gui branch).

Revision 1878

Disables MMX register allocation in the EErec; fixes instances of random TLB
misses in games like SMT:Nocturne and FFXII (initial benchmarks show it to be
same speed or faster anyway, heh)

Revision 1879

legacy_gui: synced GIFtag parser bugfixes from trunk. Fixes many problems
introduced in recent legacy gui revs, most notably some issues in Gran Turismo

Revision 1880

legacy_gui: Disable MMX register allocation the EErec. Fixes instances of
random tlb misses and hangs in several titles (synced from trunk)

Revision 1881

legacy_gui: previous 2 revs had a failed half-merge of GIFtag code (tortoisesvn
bugs.. >_<). Re-merged, and removed plugins external because they weren't
compiling anyway (also removed all plugins from the pcsx2 solution).
Plugins need 3rdparty and common dependencies that only have projects in the trunk, and it was too much work for me to merge them over just for the sake of compilation convenience. So I axed them. Use trunk to build plugins. :)

Revision 1882

More GIFtag bugfixes; PATH1's VU1 memory wrapping was measuring the end of VU1
memory incorrectly.

Revision 1883

legacy_gui: sync with trunk to pick up GIFtag fix. Hopefully the last of these
for a while >_<

Revision 1884

legacy_gui: helps if mVU isn't broken to the point of not working at all.

Revision 1885

xgkick fix for main trunk
This was pretty comical. All of us devs had mVU disabled today and none of us realized it, since typically we never disable mVU. So we didn't even know anything was wrong and we couldn't reproduce reported errors. :p

Revision 1886

- Optimization for gsTransferDummy to reduce idle loops.
- Added needed variables to _mtgsFreezeGIF().

Revision 1887

Rbor, rbsr, and other such things.
I assume FFX and stuff is all working fine for you again? Sorry about that. :(
Yeah, when I switched over to Windows, and was still having issues, I figured it couldn't be me. r1885 took care of it, though.
Though I never got around to fixing the const tag flag, come to think about it, since I'm working in Windows at the moment...

Revision 1888

Revert all changes involving the GIFtag parser rewrite. It was not bug-free yet,
so we'll handle it later in wx.
This reverted a few of your cosmetic changes as well, sorry for that :p
No worries.
To be honest, I don't think I did any cosmetic changes to those files recently anyways (though I think Jake did.)
All my recent changes have either been wx related or DMAC related...

Revision 1889

LilyPad: Fixed not adding manifests in debug builds, removed them from CRTless
Removed the keyboard disabled option, as using two different pad plugins is
really just a bad idea. Also finally got sick of people saying "I have keyboard
disabled, and the keys don't work! I urgently need help!"
Also will no longer let you enter config mode (And thus crash the program) when
emulator is running.

Revision 1890

fixed the arc the lad gif problem...
1 line-by-line comment
line 298:
298: if((path.numregs * path.nloop) < (size-1)) {
Forget a "!path.hasADreg" here? Or am I missing something elsewhere that makes it unnecessary?
I'm like 99% sure it's supposed to be there, but I've been so wrong myself already on GIFtag "fixes" that I'm afraid to make the change. lol

Revision 1891

LilyPad: "WM Keyboard" now actually uses GetAsyncKeyState(). Just simplifies
some dependencies on the window thread. Note that WM Mouse and raw input still
have those dependencies, and they can't really be worked around, unfortunately.
Also, just for kicks, made pausing while pressing "escape" check the pause
button in the menu.

Revision 1892

Some minor IPU changes.
Not absolutely sure a minor savestate bump was needed, but I figured it couldn't hurt to be sure.
I'm also not sure if checking for a sif stall is needed. Figured adding the code was easy enough, and I could take it out again if necessary. It just seemed logically like it should be there. I'll check and see if it ever gets called later.
@arcum: since savestates don't even work yet, no bumping in state versions is really needed. But! They will be working soon. I'm working on them now. :)

Revision 1893

Took out the optimizations in gifTransferDummy.
They broke games still (so3, same stuff as arc the lad earlier).
With this simplified version all the problematic games found so far work.

Revision 1894

Implemented keyboard accelerator tables and a hashed global command table
(should be ideal for eventual GUI extensions via plugin, and toolbars and other
fanciness). Removed Pause menu and replaced it with a Suspend/Resume menu.
Closing GS window behaves more nicely.
Projects: Removed FrameworkVersion descriptor, don't think it matters for C++
code. Removed all translation files, since they're grossly out-dated and need
to be remade anyway.

Revision 1895

int -> bool.
Since Jake indicated that savestate bumping isn't needed right now...

Revision 1896

LilyPad: Reverted keyboard messages back to windows messaging.
New method of ensuring thread safety. Device update code should always run in
GS thread, even if the emulator really doesn't want to let me (Basically ancient
versions of Pcsx2...Or any 3rd party emulators with their own version of MTGS).
Updates on PADpoll, PADkeyEvent, or PADupdate, if one is called in the right
thread. Updates in thread's WndProc otherwise. Overkill, perhaps, but I prefer
to keep things compatible.
Removed "Update in GS thread" option.
Windows Messaging/Raw Input keyboard event queuing should work a little better.

Revision 1897

Win32: Added stdout and stderr pipe support for the ConsoleLogger; such that
plugins using printf or fprintf will have their messages show up in the new-
style console log and in the emuLog.txt file.
I'm fixing Linux now. :)
No worries.
I'm still looking over the dmac area of the code to see if I missed any obvious changes...

Revision 1898

Linux: Fix compilation errors and warnings. There's still a lot of new warnings
in x86Emitter due to __forceinline being disabled in debug builds, but the
proper fix for those will come later.
I'd like to fix those warnings and fix the -zmuldefs problem at the same time (apparently GCC on the mac lacks the -zmuldefs option, but MSVC requires multiple definitions for __forceinline on templated class members to work .. sigh)
Look on the bright side. We don't even need -fpermissive any more; all the code that required it got rewritten at one point or another.
-zmuldef is a pain, though...
Oh, most of the "defined but not used" warnings can be suppressed by liberal use of __unused, btw. I snuck that attribute into the definition of __forceinline at some point, IIRC, so the lack of forceinlining may be bringing back old warnings I'd supressed...
Yeah it's really MSVC's fault for not properly utilizing LTCG. Even with it enabled, MSVC won't properly inline class members unless I make 100% sure the code is included into the source files that reference the class (which defeats the purpose of LTCG!).
I should check if VS2010 has the same problem. If not then maybe I'll hold off until VS2010 goes final, and just do a simple fix. The fix for current GCC/MSVC to be happy will require a bit of header file trickery that I don't look forward to.
Ok, yeah, VS2010 will completely resolve the MSVC failures on optimizing C++ classes. I tested it here and the codegen is a lot better. Constants are propagated as they should have been all along. So I'll be able to just define classes in a single file without the __forceinline, and it should be fine.
I may do it sooner than later. The real performance benefits of the emitter using forceinline is minimal at best.

Revision 1899

Legacy_gui: Some cleanups

Revision 1900

Same general cleanups (mostly to the VU interpreters), but on trunk this time.
:) Also Fixes Issue 417 (I hope)

Revision 1901

GSdx: Update delay load DLLs to match Aug2009 DirectX SDK (and yes you need the
new SDK to build GSdx)

Revision 1902

Fixes Issue 419 by checking validity of StdHandle values. Also:
* handful of minor code cleanups, and some warning removals for ICC.
* replaced the dualshock.png with a dualshock.jpg (120k smaller!)
* Updated the About Box, and added Zeydlitz / ZZogl to the plugin author

Revision 1903

Fixed a re-entry condition when trying to use the SysCoreThread::ApplySettings()
directly; and fixed some threading issues in the resume code too.
Dev Note: EmuConfig is now *const*, and can *only* be modified by a call to
ApplySettings(), which itself cannot be called from its own thread. This
protects against accidental thread-unsafe on-the-fly settings changes.
Amazingly we had only one such settings change in the existing trunk. I fixed
it ;)

Revision 1904

win32pthreads: Changed from _beginthreadex to CreateThread, which is the
preferred method of creating threads when using dynamic CRT linking.
* Assigned names to the threads so that they show up nicely in the debugger.
* Added more error checking in the new stdout/stderr PipeRedirection code,
hopefully fixing Issue 422 (but can't reproduce the error here to be sure).
Note on the pthread change: there's no functional or API changes, so the version number of the DLL wasn't modified.

Revision 1905

LilyPad: Quick fix to bug in the thread stuff from last update.
This apparently broke LilyPad's DirectInput handling with wxWidgets, according to rama. Removing the stateUpdated[0]--; supposedly fixes this (Though it will, of course, result in a lot of redundant reading of input).

Revision 1906

LilyPad: Another pair of fixes for related bugs in the thread safety stuff.
First could cause crashes when stopping/resuming/restarting emulation, second
would cause devices to fail to restart properly (Or, more accurately, restart
too early) when doing the same.

Revision 1907

wxWidgets: Added multitap toggles to config menu. Note that currently have to
enable multitap both in Pcsx2 and LilyPad for extra pads to work.
Also added suggested interface for plugins for whenever the plugin apis are

Revision 1908

Improved MTGS (added better suspend/resume support), and work on savestates a
bit (still not working tho)

Revision 1909

Just changed the config dialog a bit to prevent performance seeking users from
disabling timestretching (and then posting threads about bad sound :p ).

Revision 1910

Fix compilation errors from my prev commit.
Note 1: I took a poll on IRC and we unanimously decided to scrap the "Emu" attempt and replace it with "System" (or Sys for short). Currently there's still some ambiguity with some of the Sys functions that are defined in App, because I was getting myself confuse don what prefixes denoted what. Will clean it up eventually.
Note: I've added a System folder, which is where we'll house the Sys/Core emulation files. The ideal being that eventually /pcsx2 will be mostly just two or four folders: System, gui, and possibly Windows and Linux (for project files).
Files in GUI will have to prefix to include System includes:
#include "System/SysThreads.h"
... and files in System simply won't be able to include GUI includes. (by design)

Revision 1911

Fix compilation on Linux.

Revision 1912

Removed two redundant/unneeded conditional checks from GIFpath processing.
Did this as a separate commit since GIFpath changes love to break things. But it should be fine. The one conditional was redundant on PATHs 2 and 3, where the vuMemSize is set out-of-range anyway (never reached). And the other was optimized to use a NULL lookup table for register indexes 0x63 -> 0xff.
s_gifPath.Handlers[handler&0x3]((const u32*)pMem); << handles is masked &3, so it will never go >3, only entries 0..3 will be used. So if some game tries to use reg 0x64, it'll get reg 0x60 instead. I'm not sure if that's what you intended, or if it will actually affect anything, but I had t note it.
Oops, yeah that should be -0x60 now, instead of &3.

Revision 1913

Renamed memzero_obj to memzero. Been meaning to do that for a while. Also,
Savestates *almost* work, but it's just not going to happen. See everyone in 5
days or so. -_-
<JakeWork>sorry I couldn't get savestates working
<JakeWork>and like the code's all hacked up because I was in a hurry and terribly sleep deprived
<JakeWork>needs an overhaul to not suck :(
It's cool. Savestates are half working.
Make the best of your trip :p

Revision 1914

LilyPad: Experimental deadzone code. Old pressure sensitive button bindings
must be rebound (DS3 buttons, XInput triggers).
Currently anything below deadzone is mapped to 0. deadzone and above are mapped
as if the control's true zero is 0 and 1/sensitivity is fully down (As opposed
to deadzone being zero). May change in the future.
Modified precompiled header to fix no-CRT build.
List of bindings noew automatically jumps to new bindings.
Yes, I can't type.
Hmm, I've been getting this for a while now:
Opening PAD
Closing GS
PAD plugin failed to open. Your computer may have insufficient resources, or incompatible hardware/drivers.
Other pad plugins are fine ><
Make sure your GS plugin does *NOT* support GSopen2. There's a bug in Pcsx2 so that it doesn't give me a window handle when using a plugin that exports it.
Erm...Or maybe it's the other way around, anyways, pDsp is never initialized, so I get passed a HWND pointer.
Just checked...Looks like it's plugins *without* GSopen2 that are buggy. Pcsx2 tries to open the pad plugin before the GS plugin has even opened a window.
I check that I am passed in a valid HWND, as I actually need a handle to the window. Not all input APIs need it, but raw input and Windows messaging do, as well as most of the extra stuff: Disable screensaver, savestate number in title, etc.

Revision 1915

LilyPad: Give "credit" where credit is due...

Revision 1916

Workaround for bug in plugin loader with GS plugins that don't support
Alright, that fixed it for me.
The question now is why my GSdx doesn't seem to support GSopen2 ><
Dunno. I only managed to duplicate the issue because I had an old (r1763) SSE2 versions of GSDX around. The one that I actually use (r1894 SSSE3) supports it.
Alright, figured it out. My linker was set to drop GSdx in some other place, forgot about that :p

Revision 1917

Added warnings in case speedhacks are enabled.
Trunk probably has better tools for this.
And yeah, I know that enabling patches overrides the warning (Too much hassle to care for that, too :p )
Lol evil but nice :P
Finally got fed up with the crap reports with hacks on huh? :P
Sure, last thread was like 10 replies until the op finally mentioned "I turned haxx off, and now it works!!11".
Sigh :p
Great idea. Made a lot of changes myself to minimize pointless support requests.

Revision 1918

LilyPad: Fix for non-pressure sensitive buttons with dead zone < 0.0625 or so.
Sensitivities, rather

Revision 1919

LilyPad: Less sensitive (Higher pre-set deadzone) for copying analog state to
d-pad state when in digital mode.

Revision 1920

LilyPad: Default deadzone increased. Note that will only apply to new
bindings, or ones from inis made before I added deadzone support. Hope it's
high enough for most cases, but not high enough to break anything...
Yes, I know dead zone is not one word.

Revision 1921

Assorted header cleanup.
And, yes, one or two of these changes are totally pointless. Just didn't notice that I hadn't done anything else in those files when looking at the diff...

Revision 1922

Trying out different interrupt timings to fix a few games.
This is all pretty much voodoo, hence the tag in the source ;)
-Digital Devil Saga Videos (IPU died, had to skip vids)
-Ecco the Dolphin now boots again (froze on loading)
-Silver Surfer Pad detection works (had a timeout before)
Trunk will get these changes once they're confirmed and tested.

Revision 1923

GSdx: Force the plugin to terminate via PostQuitMessage() when running GSReplay
(fixes bug where GSdx would remain loaded in the background indefinitely).

Revision 1924

w32pthreads: minor optimization using _declspec(thread) for internal thread
handles, instead of TlsAlloc.

Revision 1925

* Implemented a combination static link and dynamic link system; threads still
benefit from DLL-level thread management, but speed-critical actions (semaphore
and mutex locks) can now inline their "accelerated" interlocks properly. Should
be a nice speedup.
* Implemented a highly optimized pthread_testcancel(), that typically performs
its test in a single cycle. :)
* Disabled static mutexes. They aren't needed in C++ code, and reduce mutex
locking overhead nicely.
* Use intrin.h for Interlocked functions, instead of pthreads' built in ones.
* Reverted my previous commit, since TLS isn't safe in DLLs. (oops!)
* Disabled pthread_spin API, it's not entirely cross-platform and shouldn't be
used anyway (bad threading model for modern computing)

Revision 1926

w32pthreads: add the missing project file. (thought for sure I added this >_<)

Revision 1927

More explicit C++ style type definition for PSXCLK, to ensure compilers avoid
mathematical overflows. :)

Revision 1928

Implemented 64-bit writes for Counter registers -- Fixes uLaunchELF!

Revision 1929

(work in progress -- some of this stuff still doesn't quite work as it should)
* Rewrote Savestate code, fixed lots of stuff in PersistentThread, and renamed
most "Emu"s to "Sys".
* Removed wxScopedPtr and whipped up our own ScopedPtr that doesn't use boost's
fail-style function names (and made it more thread-safe).
* Handling exceptions across threads: Added Clone() and Rethrow() methods to
BaseException, and added a Rethrow() to PersistentThread.
* Go rid of AppInvoke macros (those were nasty!)

Revision 1930

* Potential Bugfix: Core1's DMA IRQ trigger was being ignored in some
instances; might fix some hangs.
* Major code cleanups, using C++ structure member methods and functions.
* Improved gui / plugin api / core emulation code separation -- hoping to
switch to wxWidgets eventually.

Revision 1931

Not particularly tested, but fix Linux.
The reason why this wasn't well tested was that my home file servers acting up. I'm going to replace a hard drive during the weekend, but that's where all my ps2 isos are. (The hard drive that's acting up isn't the one with the isos, but the one with it's os, so I won't need to rerip them...)
I'm re-ripping a few of the ones I test the most to my local system, but I'll still be testing with less games then usual for a few days.

Revision 1932

Bring over the counters fix, and also make dev builds a bit more verbose on
unknown hw writes.

Revision 1933

SPU2-X: Fixed a huge bug in my last commit that broke most everything except the
bios -- Core indexes were set to -1 instead of 0 and 1 (heh). Also a Speedup:
Switched to a lookup table for dispatching SPU hardware register writes.

Revision 1934

wxWidgets (Win32): Disable debug trace logigng of Windows Messages, because it's
really! slow. And not! useful.

Revision 1935

GIFpath: Making a note about the BIOS using the packed register address 0x7f,
and disabling logging for that address, since it spams.
Code reviews are enabled for the general public again.
let the retarded comments commence once more !
nice work on the recent changes jake.
Yep, someone's been very busy, again.
before some commits like 6 o 7, i got almost perfect speed in many games, now i have the half of speed or less, but your work is amazing, please back the speed again :D
Gasp, let the spam begin...
pab_rally83 don't use the latest SPU2-X as said in 2 revisions already, it's bugged to death.
Nah, 2 bugs in it. One we already fixed, the other needs a bit more investigation.
thanks pcsx2guide :D, good luck
Continue with Gifpath increasing the compatibility.Thanks

Revision 1936

Fixed SPU2null.

Revision 1937

Legacy Gui: Get Linux working again.
Whops :p
np. Just hadn't been testing legacy_gui regularly, so hadn't noticed...
Do you get the wxWidget version of PCSX2 on linux working, arcum? I always have problems with the wx-headers. :< Don't really know if it's a distro issue (Arch), or pcsx2 issue.
It builds.
Currently, building a Debug build requires the debug version of wxwidgets installed, and a Release version requires a non-debug version of wxwidgets. I've been meaning to see if I can do something about that, because it's a bit inconvenient. (And as a result, I've been doing almost all testing on Debug builds.)
Issues you'll note with the Linux version currently: It crashes on exiting if a game was running, and skipping the bios doesn't work. That's in addition to the known issues on Windows...
That's good to know. Not really sure how Arch builds wx, need to find out :p One quite inconvenient thing about using Code::Blocks is that making packages for it is a mess, and requiring Code::Blocks to build it not clean at all. I'm the maintainer of pcsx2-svn, but I really don't know if I should just stick with the legacy_gui for a long time, or requiring code::blocks.
The headers are located under: /usr/include/wx-2.8/wx for example. Is that the case in your distro?
Looks like it. Code::Blocks is using:
wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags
to get the flags, which provides the location of the headers, but is obviously pretty specific about what version it's looking for.
And yeah, I'm still not sure what to do on the package side, because it provides issues setting up packages for Gentoo, too, which I use. Hopefully, I'll manage to re-rig up a makefile system at some point, strictly for packages that build from source.
Trouble is that I know the previous makefile system wasn't able to handle the way the layout of the project is currently, so there are going to be a bunch of hassles doing that...
Ok, it looks like wx is built without debug info in Arch.
wx-config --version=2.8 --static=no --unicode=yes --debug=no --cflags
-I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread
wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags
Warning: No config found to match: /usr/bin/wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags
in /usr/lib/wx/config
If you require this configuration, please install the desired
library build. If this is part of an automated configuration
test and no other errors occur, you may safely ignore it.
You may use wx-config --list to see all configs available in
the default prefix.
I'll try to get things working on my side, then.
Hmm ... Well, at least it doesn't whine about wx headers anymore, when I build as release. I get a different error though. Not sure if I should post here, or make a new issue, but hey. It looks trivial at least.
/tmp/pcsx2-read-only/pcsx2/gui/Dialogs/AboutBoxDialog.cpp:51: error: ‘res_Dualshock’ was not declared in this scope
/tmp/pcsx2-read-only/pcsx2/gui/Dialogs/AboutBoxDialog.cpp:51: error: template argument 1 is invalid
Yeah, it is. It never got set back up to generate Dualshock.h when the graphic changed, and I still had the old header around for it to find, so I didn't notice. I'll take care of it...

Revision 1938

Fix Dualshock.h on Linux.
Sweet :) Now, the wx version builds in codeblocks with Release build :D
Glad to hear it. It was one of these things where it built on my side due to a legacy file that it wasn't generating any more that was still in my trunk...
Hmm... Having weird problems, that my bios can't be found with the wx build, even though I point it to the correct folder :V Is it a way to brute force it in the .ini file or something?
It should be noted that I tried to copy over a wx-PCSX2 into a legacy_gui PCSX2-folder and run it from there.
Under [Filenames] in pcsx2.ini, the BIOS line says:
in mine (noting that I'm running it in /usr/local/src/pcsx2-1/)
Also, I've had issues with it not defaulting to the right folder unless I uncheck and check the Default button below it before. Not sure if that's fixed or not; issues on initial setup are hard to reproduce...
Indeed. Can you copy-paste your pcsx2.ini, so I have something to work with? :)
Sure, though I'd sure you'll need to modify at least some of this:
Looking closely, looks like I took SCPH-50001_USA_Con_0170_20030325_v9_[C898DF82].rom0 and SCPH-50001_USA_Con_0170_20030325_v9_[EB7CA0AA].rom1 and made copies of them named rom0.bin & rom1.bin in the bios folder[1]. It's possible it might be detecting the names incorrectly...
[1] And, obviously, totally forgot about it.
Yep, that's what it is. Symbolic links to *.rom0 and *.rom1 named rom0.bin and rom1.bin should suffice till it's taken care of.
In fact, looks to me like it's just filtering out anything not ending in *.bin.
Does anyone have a bios file not ending in *.bin? rom1, rom2, and erom files are not primary rom files, so they should generally be ignored when enumerating. Although I guess there's no real harm in enumerating "everything" like the old PCSX2 did. Maybe someone uses .rom for an extension on the primary bios rom file?
Mine don't end in bin, for whatever reason.
I seem to recall that when the bios extracting program generated a bat file, I renamed it to be a 7z file and extracted the files, since I didn't have access to Windows at the time. It's possible the bat file may rename things.
Perhaps I should rerip and see how things look. I just got my ps2 set back up, so I can actually do that if need be...

Revision 1939

Bring in cdvdGigaherz (step 1).

Revision 1940

Undo my little mess. Fix it next commit

Revision 1941

Whoops missed 2 files.

Revision 1942

Properly add the project stuff so it "fits" with the build system used on all
the other plugins.

Revision 1943

Remove custom settings from the vcproj which were already globally defined in
the vsprops.
Fix a silly bug too, and silence a warning.

Revision 1944

Fix error on release build.

Revision 1945

Unbreak Debug too.

Revision 1946

Just a tiny cosmetic change in the plugin name string.
Ok you can comment now, I'm not commiting anythign else. XD
Alright thanks. I'm going to delete my other comments so as not to spam this. But will you guys look into it?
Well i'm not the one who codes gsdx, that'd be Gabest, so it's mostly up to him. I'm sure he will check it, at one point or another.
Thank you very much. I haven't seen him around for a while though... I'm getting worried.
Nah, he's just not very active. Some time ago he was gone for like a year. A few weeks are nothing. :P
In the meantime go back to the revision that worked. I've told you in the forums before, this is NOT a simple fix.
Bringing it up every day lowers the odds of it being worked on, you know? ;)
Thanks for upping this, gigaherz. We now have working CDDA support :)

Revision 1947

SPU2-X: Fixed some more major bugs and typos; most sound *should* be working
again now. Added a hackfix for a crash in the BIOS cased by what *should* be
correct handling of IRQAs.
Notes on this revision, for Rama and anyone else interested:
The "current" DMA functionality of testing only the current core's IRQA is in fact what SPU2-X has been doing since the dawn of time, which is why that weird BIOS hackfix wasn't needed. So right now "hacked" mode is basically the status-quo for what we've been doing all along. Translation: The hack shouldn't break anything that wasn't already broken.
I re-added code for the original ReadInput, which can be commented out in case you want to regression-test it. The BIOS CD Player in particular needs tested, if someone can do that for me. I'm still waiting on a new DVD drive for my PC, and I'm too lazy to make an audio iso and mount it with Deamon Tools :p

Revision 1948

Added some DebugBreak generation (INT3 / 0xcc) to the PsxRec, for catching null
pxsRegs.pc assignments from the recompiler (enabled in DEBUG builds only).
These are usually more context-useful breakpoints than the assert() check in

Revision 1949

Win32 build system:
* Re-enabled function-level linking in the shared properties sheets (applies to
debug and devel builds, and is ignored in release builds). Can't remember why
it got disabled in the first place, but whatever errors it was causing seem to
be gone now.
* Removed the wxWidgets 2.9/3.0 copy of wxScopedPtr (wx/scopedptr.h), since we
have a new superior implementation of our own.

Revision 1950

Lots of new code maintenance stuffs:
* Completely new assertion macros: pxAssert, pxAssertMsg, and pxFail,
pxAssertDev (both which default to using a message). These replace *all*
wxASSERT, DevAssert, and jASSUME varieties of macros. New macros borrow the
best of all assertion worlds: MSVCRT, wxASSERT, and AtlAssume. :)
* Rewrote the Console namespace as a structure called IConsoleWriter, and
created several varieties of ConsoleWriters for handling different states of log
and console availability (should help reduce overhead of console logging
* More improvements to the PersistentThread model, using safely interlocked
"Do*" style callbacks for starting and cleaning up threads.
* Fixed console logs so that they're readable in Win32 notepad again (the log
writer adds CRs to naked LFs).
* Added AppInit.cpp -- contains constructor, destructor, OnInit, and command
line parsing mess.

Revision 1951

SPU2-X: Fix CDDA playback, which got broken a few revs back; and remove
regression test code (ReadInput is pretty well confirmed to be good now,
anything still broken is because of something else).

Revision 1952

Linux: Minor fixups!
Also! One of the benefits of the new pxAssert macros is that we no longer need to rely on wxWidgets debug builds for debug/assert functionality. It's not entirely ready yet, since the new pxOnAssert() still needs its own popup window handlers to replace wx's (wich don't exist in release builds of the lib, annoyingly).
So hopeflly we'll be able to nip that linux debug/release annoyance in the bud here soon.
Sounds promising.
The two main issues I'm seeing on the Linux side at the moment are that the skip bios option doesn't work, and that exiting is causing assertions if the emulator has been started. (Both of these have been issues for a while.)
A few games crash on startup, but I normally don't launch those games via the bios, so that could be a result of that bug.
I've been fixing my home file server for the last few days, and it's left me not doing much coding, partially because most of my isos are on it. It's almost back up and running, though. Just have to figure out why samba isn't sharing anything on the network after my reinstall...
can I ask one question?Where can I download these versions?I know it is a stupid question but forgive me.
@[email protected] & mercer550 if you want compiled new versions for windows, then visit http://www.emudreams.pl/
But do remember they're still not done.
Don't expect to play games on these, there isn't even a framelimiter yet.
>> The two main issues I'm seeing on the Linux side at the moment are that the skip bios option doesn't work ...
doesn't work here either so don't feel bad. I dunon why I can't keep it working. :p I'm going to *really try* to get savestates working today tho, and then start tidying up some of the little things again, and then get the framelimiter implemented.
@arcum: On crashes, I'm pretty sure I need to force-disable EBP allocations in the EEcore recompiler for linux to be stable. I'm using C++ exceptions now as an optimization for exiting the recompiler, and linux implementation depends on EBP (Windows uses SEH, which works without EBP). The EE core clobbers EBP though, so if ou happen to try to exit the rec when you're in a block that's changed EBP, it will probably fail >_<
Unfortunately zerofrog never allowed for ebp to be disabled, because apparently he hated debuggers. He has a switch that disables allocation to eax+ecx+ebp all at once, but that's major overkill. I'll see what I can do.

Revision 1953

Bind the cdvd's newDiskCB properly when changing CDVD sources; and more
jASSUME->pxAssert change-overs.
This worked :)

Revision 1954

Minor fix to r1953.

Revision 1955

Linux: We don't need no stinkin' muldefs! (fyi, turns out the solution was to
use the "inline" keyword on class member prototype definitions, yes that simple

Revision 1956

legacy_gui frees itself of the shackles of -zmuldefs as well! (not actually
tested since I could never get legacy gui to build on my linux distro here)
Tested it, and it builds...
zedron says the legacy gui here still gets some muldefs on GTK code. That's outside my jurisdiction tho. If you disable -zmuldefs from the makefile they should show up, if you feel like fixing them.
Zedron needs them fixed for the Mac build because OSX's ld lacks the -zmuldefs "feature". Either it builds clean with no muldefs, or it fails :(
I'll check it. I probably didn't do a full rebuild, since I was on my way out the door...
Actually, come to think of it, the fact that -zmuldefs is still the configure.ac file probably has a lot to do with it working, doesn't it?
Assumed that was already done. Oh well...

Revision 1957

Better fix for zmuldefs. Less warnings in MSVC and GCC both. :)

Revision 1958

wiki: Updated for w32pthreads.v3.dll

Revision 1959

Renamed PCSX2_ALIGNED to __aligned and removed the need for excess parenthesis
and oddball qualifiers. Left the old macros in Pcsx2defs.h for now, just in
case. Redid some of the storage organization of microVU and iFPU consts and
temporaries while I was at it, using structs instead of naked vars -- should
improve cpu cache behavior a wee bit.
_aligned fits better with some of the other defines we're using, I think...

Revision 1960

Two minor cosmetic fixes from the __aligned switchover.

Revision 1961

Added a gamefix that should fix the messed up camera views in Gundam games like
"Mobile Suit Gundam Seed Destiny: Rengou vs. ZAFT II Plus" and the other ones
that had this problem.
No need to set roundmode to nearest anymore, just use the gamefix.
also i think i also have to add this fix to iFPUD.cpp stuff, i'll do it
btw, this fix is untested because i don't have the time today to test it w/o
working saved states.
okay its not working yet.
i'll fix it tomorrow...

Revision 1962

More zmuldef stuff for the legacy gui.
The change to LnxSysExec is a bit of a hack, really. What I should have done is just abstracted out the file selection code. Or at least renamed the variable and kept it local.
Didn't feel like putting that much time into gui code that we've already removed, though. :(
In any case, this ought to straighten out zmuldef for the legacy gui. Most of it was just stuff being included in Linux.h that really shouldn't have been.
Two of the variables weren't even used. I'd just kept them around in case I felt like redoing the logging dialog, because it would have been a bunch of typing to redo...

Revision 1963

Fix Linux. (While things in [] in inline assembly in gcc may look like variable
names, they are actually labels that I've set to look like the variable names to
ease readability. Unfortunately, labels can't have periods in them...)
I figure "Row0", "Row1", "Col0", and "Col1" is readable enough here...

Revision 1964

Linux: Added more correct __asm__ qualifiers and conditions; including
__volatile__ on a lot of asm code (it should really be the default behavior and
non-vlatile the specifier, but whatever >_<), and added register clobber
specifiers. Might help unbreak some of GCC 4.4's optimization problems,
although VIFdma's uber-hack SSE optimization looks like a real problem.
Read VifDma diffs for laughs.
Also! I changed RecExecute, so maybe everything's broken, or maybe it works fine. Please test that for me (I still can't quite run that far in linux).
Oh, and we could explicitly map the yuv and sse2 stuff to ecx and edx, (c and d), but it should do that for us regardless, so I left it generic.
Unfortunately, I'm going for everything's broken. On Atelier Iris 1, the dolby animation shouldn't be bright pink, and most of the games I tried crash early on, and have distorted colors in movies.
I'll mess with it some more, though.
Oh, and something I spotted a while back, but forgot to mention; starting Dark cloud 1 currently gives a "Impossible block clearing failure". :)
Not a new issue to this revision, though.
Well, the color issues are local to the yuv2rgb.cpp changes. Not sure about the segfaults yet.
Windows version possible brocken?
iR5900-32.cpp(691) : error C2061: error de sintaxis : identificador 'emms'
Yea FMV breakages would be the fault of the yuv/rgb code. I see what I scewed up. I'll work on fixing that (small bug).
The segfaults could be any of the changes I guess, so regression test until you find the asm change that causes it and let me know which.
... and I'll fix windows builds in a minute,
I'm doing so. Just thought I'd verify that it was the yuv/rgb code on the color changes first. Seemed obvious (which is why it was the first thing I checked), but it pays to be certain...
I'm regression testing, that is.
Hopefully finding the cause of the crashes might shed some more light on what causes other crashes.
.. and I see I forgot something important in iR5900-32.cpp regarding EBP.

Revision 1965

Fix win32 compilation error, and fix Linux FMVs and (hopefully) some segfaults
too, likely caused by not saving EBP.
That took care of the colors issue. The segfault I was looking at looks like it's from an earlier revision. Didn't expect it to be because it's a game I test often.
I'm currently in process of determining the revision...
I switched what directory I was compiling the trunk in due to some unsaved changes in my main trunk. Turns out I had an old copy of ZZOgl in there that was causing the crash.
I'll do more testing to see if anythings crashing that shouldn't be, but I think that was it...
ah, good. For a minute I was fearing the __aligned changeover would be the cause... >_<
Think that was it. ZeroSPU2 wants to crash FFX, but I'm not going to worry too much about that right now...
Actually, the FFX issue looks like an intermittent one. I'll worry about it later, though, since I need to get some sleep...
At a guess, issue 327 , actually. :)

Revision 1966

Minor buildsystem changes (remove some warnings and add function level linking
option to all 3rdparty libs)

Revision 1967

Win32: Improved batch files for clean_msvc and preBuild, using %~dp0 to fetch
the folder/location of the command script.
troubles compiling code under linuxx86 gcc 4.3.3 with new pxAssert and etc implementations i got error
expected primary-expression before ‘,’ token
compiler not like much define x(p) x2(p, pz);
i am missing something? (svn trunk is fresh)
so far seems okay in dev build but it's still going on..

Revision 1968

More Vif register stuff.
Forgot I'd made the bios change, but it should be harmless.
The IopHw changes are because I started to clean up IopHw.cpp, then decided to make sure I wasn't revising something that was just going to be rewritten later, or was there just for reference.
And, yeah, more of the same register changes I've been doing.
(And yes, these are the changes I had sitting in my main trunk I was referring to.)

Revision 1969

More MSVC/Win32 buildsystem fixes: Made is so you can now optionally unload all
3rdparty libs (after building at least once!) and still build the rest of PCSX2
and plugins without linker errors. This is useful for reducing the memory
overhead of working in the MSVC IDE, and reduces the size of the .ncb file and
the bugs that come with it.
Oh forgot to mention! I also added more cleanup files to the MSVC buildsystem, so using clean_msvc should be a less frequently-needed occurrence. The build system now cleans things like bsc, pdb, and ilk files when you select "Clean" (which are typically the sources of rebuild failures).

Revision 1970

Still doing register stuff.
I decided to add a few helper functions to the register unions. I just thought this makes it a bit easier to read, though I've only done the stat ones as of yet.

Revision 1971

Don't believe we really need an xml parser in pcsx2. I've moved it to 3rd party,
in case we want it at some point. Removed the xml loader code as well.
Speaking of that, someday I'd like to turn patch handling into a plugin.
We talked it over on IRC repeatedly and everyone pretty well agreed it should be a plugin, since there's quite a few ways to handle patches and cheats (dialogs, UIs, file formats, etc).
A patch plugin would be a simple interface too, it'd just query the patch plugin at the same few pre-defined points (one in vsync, and I think one other elsewhere?).
The other one would be right after the executable loads, giving it the CRC and all.
I remember seeing the preliminary code hit svn for that. I thought it was a good idea, too. That way people can build special interfaces to their hearts delight on it. I could even see cheat plugins for specific games appearing. (I'm almost certain Final Fantasy X would get one.)
And it looks like it tries to apply patches both in cdvdDetectDisk and in cdvdReadKey. With the same copied and pasted code, in fact...
I'd wanted to get rid of the xml code for a while, though. I just kept getting distracted by other things.
Note: Sorry, not the same copied and pasted code. It's slightly different.
Incidentally, Jake, the Skip bios being broken right now appears to actually be most of the options being broken. I don't think anything set in g_Conf->EmuOptions ever gets to EmuConfig.
Noticed because I chose SuperVU and got microVU...
Agreed on both, the xml loader (old idea to patch every ps2 game with roundmodes is old :p ) and the Patch plugin idea.
Yeah, I'm working on saved states again, and will fix the settings along with. I got distracted this weekend doing project maintenance work on asserts and other macros and buildsystem crapola that's been bugging me, but I'm back on track now. :)
np, just wasn't sure if you if you'd traced it that far. Doesn't matter that much to me, because skip bios doesn't work in Linux even when the settings work. (It starts to boot the bios, then throws a "ExitRecExecute" exception. At a guess, it should be exiting the bios at that point instead of quitting).
And I'll admit to being easily distracted myself...
>> (It starts to boot the bios, then throws a "ExitRecExecute" exception. At a guess, it should be exiting the bios at that point instead of quitting).
That's good, in a way. It's not being caught where it should be because of EBP being used by the rec. So if we can successfully turn off EBP allocation, then SkipBios should start working. So it's an easy test of EBP/working exceptions.
Which should be useful. Irritating when testing games, but at least we'll know when ebp allocation is off...
Oh, I noticed that the issues exiting in Linux after emulation starts are from when it does a reset of the emulator. Once Pcsx2App::SysReset is called, the emulator basically goes into limbo, and will crash on wxYield the next time to try to reset, exit, or start back up emulation.
(If I choose reset, it does the same thing, and never gets past Pcsx2App::SysReset in Menu_EmuReset_Click...)
They're savestates, not saved states! (Yeah, I know the latter makes more sense :p
/End Spam
Syntax Error on Line #2. Expected ) before /End

Revision 1972

legacy_gui: Some small fixes courtesy of Zedr0n..
* fixes using Run->Execute as the first action after starting the emu.
* Slightly cleaner muldefs fixes (macs must really hate muldefs!)
.. forgot to tag it as linux only. >_>

Revision 1973

Linux: Experimental fix for exception propagation out of the recompiler; this
version is based on the theory that the cause is GCC optimizing out exception
handling because it sees the inline asm "call DispatcherReg;" as a no-throw().
So I removed the asm and replaced it with a direct C++ invocation. This should
work since the new rec never exits except via catch() clauses anyway, so
pushing/popping clobbered registers isn't needed.
@Arcum: Give this a test with the bios skip force-enabled, and see if the exception works properly.
It does, in fact, work properly, so that must have been it. (Which tells me that a few games that currently crash on startup aren't doing it because of not starting through the bios, but I'll look at that later.)
Looking good, though we'll have to be careful about mixing assembly and exceptions...
Yeah, this case was exceptional (pun!) because it was asm code *inside* a try/catch block. I could have also fixed it by exporting the asm code into a separate function and specifying noinline. So I don't think it'll be a problem anywhere else. So long as GCC doesn't "think" i can optimize out the catch handlers, it should be fine.
On crashes: Post some stackdumps in an issue or something, when you have time. We'll see what we can figure out.
I know I had more then one game crashing, but concentrating on the one that I know about first, it looks like iVif decided to become temperamental again, because it's a reoccurrence of the issue I worked around previously on it (only without mask being 0).
Works fine if I set it to always call "UseOldMaskCode", but I hate to have Linux specific code if I don't have to...
BTW, happened upon this article, and thought it might be of interest:
Out of curiosity, any reason to keep pushing and popping the registers for DispatcherReg on Windows here? Seems like if it isn't necessary any more, we may as well not do it any more on either platform...

Revision 1974

wxWidgets/Win32: Keep wx from including <windows.h> into every app/gui related
file; reduces window.h global namespace pollution and speeds up compilation
times a little bit.

Revision 1975

Savestates work! Not much else does yet (settings, etc), but at least this
monkey's off my back. I can work on tying up more loose ends now. :)
And there was much rejoice.
And cake. Grats on finally getting that big issue out of the way.
The cake is a lie!
Nice job with savestates. At last :P
Glad to have savestates, but saving in Linux crashes ZZogl and ZeroGS currently. Not sure if it does in Windows or not; I'll have to check.
Having dealt with no savestates for a while, this doesn't have to be an immediate priority, though.
Here's a stack trace, using ZZOgl r184:
Saving savestate to slot 0...
filename: /usr/local/src/pcsx2-1/bin/sstates/4D2CAC9D.000
Saving GS
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xe9bffb90 (LWP 5807)]
0xf0866532 in glBindTexture () from //usr//lib/opengl/nvidia/lib/libGL.so.1
(gdb) bt
#0 0xf0866532 in glBindTexture () from //usr//lib/opengl/nvidia/lib/libGL.so.1
#1 0xf0aca7aa in ZeroGS::CRenderTarget::Resolve (this=0xec7025b0) at targets.cpp:277
#2 0xf0add97c in ZeroGS::Save (pbydata=0xe8c4d87d "") at targets.h:73
#3 0xf0aa2a3c in GSfreeze (mode=0, data=0xe9bff048) at GSmain.cpp:1245
#4 0x080f9658 in PluginManager::DoFreeze (this=0x942fa90, pid=PluginId_GS, mode=1, data=0xe9bff048)
at /usr/local/src/pcsx2-1/pcsx2/PluginManager.cpp:1048
#5 0x080f97ae in PluginManager::Freeze (this=0x942fa90, pid=PluginId_GS, [email protected])
at /usr/local/src/pcsx2-1/pcsx2/PluginManager.cpp:1091
#6 0x08119cac in SaveStateBase::FreezeSection (this=0xe9bff144) at /usr/local/src/pcsx2-1/pcsx2/SaveState.cpp:289
#7 0x08119f3d in SaveStateBase::FreezeAll (this=0xe9bff144) at /usr/local/src/pcsx2-1/pcsx2/SaveState.cpp:346
#8 0x08115d64 in StateThread_Freeze::ExecuteTask (this=0x9614e18) at /usr/local/src/pcsx2-1/pcsx2/RecoverySystem.cpp:102
#9 0x082d496d in Threading::PersistentThread::_try_virtual_invoke (this=0x9614e18,
method=&virtual Threading::PersistentThread::ExecuteTask()) at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:206
#10 0x082d4ea5 in Threading::PersistentThread::_internal_execute (this=0x9614e18)
at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:291
#11 0x082d4ef5 in Threading::PersistentThread::_internal_callback (itsme=0x9614e18)
at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:305
#12 0xf781efcb in start_thread () from /lib/libpthread.so.0
#13 0xf77a3b5e in clone () from /lib/libc.so.6

Revision 1976

Resolve some Linux/GCC errors.

Revision 1977

Linux: Revert to using the old masking code in iVif at all times, until we can
figure out why the other masking code frequently crashes under Linux.
I did some disasm checks of the codegen in 4.40, in both debug and release modes, and it looked perfectly fine. Are you still using 4.3.x? or 4.4? It could be a bug specific to 4.3.x.
In any case we could make this routine an emitter function, and all problems would be solved. :p
Last time I rebuilt my chroot, I installed gcc 4.3.3. I actually have to unmask gcc 4.4.1 if I want to use it, because they haven't marked it as stable on gentoo yet. [1]
I can install gcc 4.4 and test with it; it'll just take a while. [2]
Making it an emitter function is probably a good idea, though... :)
[1] Since gentoo[3] is source-based, they usually don't unmask versions of gcc till they have most of the packages that don't build with it fixed...
[2] Again, gentoo installs everything from source. And gcc builds take forever. I usually do them when I'm going to be doing something else for a while...
[3] Gentoo being the Linux distribution I use.

Revision 1978

Linux: some more minor tweaks to project files and compilation errors (release
mode only)

Revision 1979

Linux: oops... committed the asm dumping switch by accident

Revision 1980

Assorted minor VifDma changes.
Not a big commit. Think I've made a few of these changes several times, and then lost them when reverting bigger changes, so I thought I'd commit them now.
Interesting to note that several of the section labels in VifDma were wrong, though.

Revision 1981

Chop up VifDma into a few pieces.
Basically, all the Vif0 and Vif1 functions now have their own files, and can be looked at and compared side by side.
I also added templates to some functions in VifDma.cpp.
I'd like to have a lot less duplicated code in VifDma, and separating it so you can see what's duplicated seemed like a good way to start.
1 line-by-line comment
line 1130:
1130: vif1Regs->stat._u32 = (vif1Regs->stat.test(~VIF1_STAT_FDR)) | (value & VIF1_STAT_FDR);
warning C4805: '|' : unsafe mix of type 'bool' and type 'u32' in operation
This is a meaningful warning, and I don't think this code is doing what it's intended to do. I'm not sure where the actual change occurred, yet but figured I'd note it here for now, since you probably remember the code changes better.
I recall thinking that that didn't look right yesterday, but was on my way to bed. I'll revert that line. (It's from r1970, btw. )

Revision 1982

Get rid of a few Windows compilation errors.
Well, warnings, not errors, but you know what I mean.

Revision 1983

SPU2-X: fix a memory leak that dropped a few Kbytes of memory on every
suspend/resume (it's been there for ages too; SoundTouch object wasn't being

Revision 1984

Fixed a memory leak in the MutexLock object.
Well, this is interesting. _CrtSetBreakAlloc( spot ); was obviously a Microsoftism, so I ifdefed it out.
The fact that pcsx2 now starts emulation the moment I open the program, and then crashes due to CDVD being null is odd, though...
... That's pretty random. I'd suggest doing a full clean/rebuild if you haven't already.
Yeah, a full rebuild took care of it.
That was strange, though.

Revision 1985

Revert one of my changes from r1970.
That was not a spot where it actually was a test, so shouldn't have been changed; I just got a little carried away... :(

Revision 1986

Linux: Fix compilation.

Revision 1987

wxWidgets/Win32: Added a private heap allocation feature, which directs all
wxString and wxObject allocations through a Windows private Heap (should reduce
fragmentation and multithreaded contention when allocating/freeing blocks)
(and fix some oddball compilation errors in spu2-x in rare circumstances)
Looks like you forgot to add HeapAllocator.h
2>c:\src\pcsx2\3rdparty\wxWidgets\include\wx/string.h(178) : fatal error C1083: Cannot open include file: 'wx/msw/HeapAllocator.h': No such file or directory
2>Build log was saved at "file://c:\src\pcsx2\3rdparty\wxWidgets\build\msw\Win32\Debug\wxAdv28\BuildLog.htm"
2>wxAdv28 - 1 error(s), 0 warning(s)
same for me , Cannot open include file: 'wx/msw/HeapAllocator.h'

Revision 1988

Minor cleanups -- removed unnecessary "using namespace std;" declares, etc.
crap! I was intentionally trying to avoid committing my copy of lilypad. I have no idea what's wrong with it and I wanted to finish up my outstanding changes and figure out how I ended up with some weird totally different version of the project file.
And I committed it anyway >_<
Oh I think I see what it did. It just re-arranged the x64 and x32 builds arbitrarily. Makes it look like all kinds of stuff changed, but really nothing changed. MSVC just decided to move the Win32 builds to the top and the x64 builds to the bottom... -_-
So it's safe. Just a pointless change more or less. Stupid msvc :p
Yea, noticed one of my earlier commits flipped their order for no good reason, too. Kinda funky.

Revision 1989

wxWidgets/Win32: Helps when I include the necessary files (HeapAllocator.cpp /

Revision 1990

wxWidgets: Bugfix to the private heap, caused by me recovering the wrong file to
commit to svn. -_-

Revision 1991

wxWidgets: helps if I fix *both* string and object allocators. I'm a commit
spammer tonight. -_-

Revision 1992

Made hwDmacSrcChain & hwDmacSrcChainWithStacks a bit easier to follow. Misc
other changes, mainly register related, or making use of existing constants.

Revision 1993

Settings work again!
* Switched the SysCoreThread to a static (fully persistent) thread.
* Added some listeners for when the CoreThread status changes
* fixed some slowness in savestates, and the emu will now stall until
savestates complete, if you try to exit too quick (avoids savestate corruption)
Finally ^^. Now i can play Mana Khemia. Thanks a lot.
Ah and I wondered what broke the settings :p

Revision 1994

Fixed: Savestate bug when saving caused erratic freezeups.
Fixed: More savestate slowness, and less savestate memory hogging.
SPU2-X: Fixed crash bug on using savestates while suspended.
@rama: and I'm wrong, wizard no hang. I misread the log. Eveyrhing looks fine there.

Revision 1995

Quick save menu fix.
The fix for this was pretty obvious, so I only tested this to the extent of saving and loading a couple saveslots in Windows.
Confirmed. Thanks arcum :)
No problem...

Revision 1996

Fix GSdx game patches not loading when bios skip hack enabled.
Long time no see. I`ve tested the latest WIgui. Interesting that Steambot Chronicles boots in new WGUI but still crashes with the PCSX2 svn betas. And btw, if you play STMB the demo works just fine with GSDX10 hardware... only the ingame is with these glitches and that slow speed...

Revision 1997

A couple misc changes. Converted a few more lines to the new register format,
fixed spelling in a few comments, and so on...

Revision 1998

Fix minor mistake in my last commit.
2 line-by-line comments
line 139:
139: if (sif0.sifData.data & 0xC0000000) // If NORMAL mode or end of CHAIN, or interrupt then stop DMA
This here really needs fixing. Wanna help? :p
line 271:
271: if ((sif1dma->chcr.MOD == NORMAL_MODE) || sif1.end) // If NORMAL mode or end of CHAIN then stop DMA
It should look mostly like this I assume.
Keep in mind comments are often misleading. The comment on line 138 is mine, though. I've been saving some of the trickier ones for last, and while I know how xxx#dma-> works, I haven't really looked much at sif#.sifdata yet.
The li9ne in question is basically saying 'if either of the last two bits of the tag are set'. The last bit is the Irq tag, so a Tag::IRQ(sif0.sifData.data) would be in order for that. (which would be the interrupt mentioned)
Not sure offhand what bit 30 of that tag is, though.
And I suspect that the code may be wrong there, but am not totally sure. My guess at what it should be is:
if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))
But that's not what the actual code does right now. Wonder if it breaks anything if I substitute that?
li9ne -> line
Yay for uneditable comments.
I'm all for testing this out.
Give me some more "versions" of what it *should* be, and I'll test them here :p
"if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))"
I'm running this version currently. So far so good (no changes in compat yet).
if ((sif0.sifData.data >> 30) || Tag::IRQ(sif0.sifData.data))
is about what it's doing now.
But I'm more inclined to go with my first version, after trying a few games without any issues. Trouble is, I'm not sure what games make heavy use of Sif0...
if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))
if (sif0.sifData.data & 0xC0000000){}
else Console.WriteLn("waa");
^ no "waa" in any games yet though :p
"Trouble is, I'm not sure what games make heavy use of Sif0..."
They all do, it's running constantly for like everything :p
Makes things easy then. :)
Though I should say "how many games are relying on us checking bit 30 of the tag in sif0dma". It could be most games just set the irq tag to stop dma in sif0...
Yeah, from some testing it seems you're right and games just set the IRQ flag.
Ah yeah, and I've found the revision that adds the high level emulation part.
Could be a good reference :)
So far, it does seem like you could practically just use:
if (Tag::IRQ(sif0.sifData.data))
Suspect it would break something, somewhere, though.
Tested a good dozen games or so with no issues, and no signs of anything other then the interrupt being needed.
I'm off to bed...
Ok, this testing session brought something up that I find a bit odd.
The docs talk lots about the stall control feature of the DMAC, but when logging for that, the flag is never set..
(I was checking for any "dmacRegs->ctrl.STS" occurance.)
Ok, I'll continue here :p
Don't have any time to really work on it right now, but just did some quick checks, and I see what you mean. STD is also involved with flow control; wonder if that's being set?
Hmmm... just noticed this line:
if (tag[0] & 0x40000000) sif0.end = 1;
Which is "if bit 30 of tag is set, set sif0.end."
I'm assuming that tag[0] ends up in sif0.sifdata.data, so this would make:
if (sif0.end || Tag::IRQ(sif0.sifData.data))
be about the same as the current version. And the fact that if doesn't test for normal mode corresponds to the comment two lines above this code. ("Note... add normal version here")
(And I'm actually getting ready for work. I just give myself enough time to do things like reviewing source code when getting ready. ^_^ )
One further thing. Had a chance to doublecheck, and bits 28-30 of a dma tag are the id of the tag. (Knew that at one point, just forgot about it last night, and was having trouble getting into my reference material.)
So testing for bit 30 is saying "if the tag is either refe, call, ret, or end", only sif only uses refe and end. It's basically a rather ugly way of testing for the transfer to end, since both of those tags do end the transfer.
By rights, it should probably have a case statement like the one in Sif1Dma...
Well, I did a slew of tests surrounding this code.
Couldn't get any games to behave better than usual, which is a worse result than what I get with voodoo cycles for interrupts :p
So yeah, I guess the code is working (Just looks like it wouldn't. really. :p )
Yeah, the code's working either way. It'd probably be easier to read if we go ahead and substitute either my first or last variation, though.
Eventually, I think that whole function probably needs rewriting...

Revision 1999

SPU2-X: Minor bugfix to suspend/shutdown code which caused SPU2-X to hang in
very rare occasions.