PCSX2 Wiki

PCSX2 Documentation/Google Code svn repository comments archive 2000 to 2499

Revision 2000

GSdx: Fixed a couple memory leaks.
kaboo...
nice memory leaks and crashes are really evil bugs^^
on a secondary note yay 2k commits^^
Castrat...
For a moment I thought Gabest returned for r2k... That would have been epic. Nevertheless, congrats! Go out and have a beer!
Jake.Stine
Hmm, I could have recycled the texture instead of deleting it, although in that particular case it probably doesn't matter much. Those textures aren't too high on the reuse frequency, I suspect.
heatbla...
Cheers for 2000 rev!
tsxp...
Grats on the 2000th revision. I'm very happy to see this still going :D Good commit as well.
coolraju...
Grats on reaching 2K milestone
system.compiler
still love it.happy 2k revision

Revision 2001

LilyPad: Minor fixes to alt-F4 detection code.
pcsx2gu...
Hey chickenliver, did anyone on IRC tell you about the config dialog bug? I'm getting the configuration screen twice each time I use it. So if i press config for Lilypad, even if I press OK or Cancel in the first config screen, a second one follows right after each time. Any changes made to the first config screen also don't save. Any ideas? :P
mattme...
Nope. You aren't using two different versions of LilyPad with the legacy gui, are you? They may even end up with the same display name.
pcsx2gu...
Crap you're right. I could almost swear it happened in WX too where you actually don't select 2 input plugins but I just checked and it didn't :P
*stabs himself

Revision 2002

The saints may come marching in, but the cpus shouldn't be. I've removed some
march flags that shouldn't be there. I also made a change to Sif.cpp that was
discussed in r1998.
arcum42
Basically, the march flag is intended to be used to tell the compiler what type of cpu you have, so it can optimize it for that cpu. To my knowledge, it doesn't stack, so having several of them set isn't a good idea.
A nice march flag to put in is --march=native, actually, because that detects your processor and optimizes it, but that is gcc 4.3+.
And the Sif change *should* do the same thing as previously, and has been tested on a number of games, but it bears watching.
arcum42
-march=native, that is. One dash, not two.
Jake.Stine
Also, it probably breaks things if the arch flag enables SSE optimizations.. :/
arcum42
Or if you're compiling on a system with a different cpu then you plan on running pcsx2 on...
t27049...
well, i will suggest use -march=i686 and -mtune=native together (have the ability to run on most cpu arch and enabling optimizations for a specific cpu)

Revision 2003

Another experimental fix for GCC/Linux exception propagation out of the
recompiler; using inline asm to invoke a jmp to an external asm function (to set
up stackframe pointers), plus disabling EBP in the recompilers (which is just a
plain bad idea in any reality or alternate universe).
Jake.Stine
@Arcum: Any luck yet?
arcum42
Not really.
In fact, DispatcherC instead of Dispatcher causes it to stop catching ExitRecExecute, so it crashes when I start emulation...
Jake.Stine
Gah. What the hell? This is turning into a nightmare. GCC doesn't want to even let me know how to make this work. When I did an asm dump, it just gave me a shitload of horrile GAS macros in place of the stackframe setup code so I couldn't even see what it's doing. And the macros are implemented internal to GAS depending on the platform it's compiled to so like I'd have to dissect the source to figure out what the macros translate to.
(and the macros have horrible syntax and lots of weird parameters so chances are only a GAS expert could figure any of it out anyway).
Totally impossible.
If it wasn't for the fact that it requires a LOT of code to make a substitute (using the old method of exiting the rec via a series of propagating booleans, for example), I'd just give linux the old slow implementation back and say "make GCC suck less for decent emulation speed!" ... but that'd be like 5-8 #ifdefs or something. Yuck.
arcum42
Yeah. Not sure what is causing it. Best I've managed is doing this (Which I can reset pcsx2 with):
--- pcsx2/Counters.cpp (revision 2003)
+++ pcsx2/Counters.cpp (working copy)
@@ -434,6 +431,13 @@
}
}
+#ifndef _MSC_VER
+void LameFakeForceDispatcherReg()
+{
+ g_EEFreezeRegs = false;
+}
+#endif
+
__forceinline void rcntUpdate_vSync()
{
s32 diff = (cpuRegs.cycle - vsyncCounter.sCycle);
@@ -448,7 +452,11 @@
{
eeRecIsReset = false;
cpuSetBranch();
+#ifndef _MSC_VER
+ LameFakeForceDispatcherReg();
+#else
throw Exception::ForceDispatcherReg();
+#endif
}
VSyncEnd(vsyncCounter.sCycle);
Jake.Stine
Well that's not really doing anything. g_EEFreezeRegs doesn't have anything to do with resetting, and in fact it's already set to false within the context of the rcntUpdate calls (hmm! which is a bug in fact, I should fix that!) .. so really that patch is the same as just commenting out the throw. I'm surprised it doesn't just crash when it leaves the EventTest code, since a rec reset should invalidate the recompiled code buffer (which means EventTest will return to a bunch of 0xCC's).
... the only other alternative is using SetJmp/LongJmp, although technically using those from the context of a pthreads routine with cleanup handlers (which we have!) is disallowed. I *think* it'll work on Linux because it has a native pthreads implementation that probably doesn't rely on setjmp/longjmp to implement pthreads cancelability. But I'm still no fan of breaking the rules here, so I guess it's not really a possibility anyway.
Jake.Stine
Ok, here's another experiment for you to try... let's add an explicit clobber list to the jmp:
__asm__ __volatile__(
"jmp DispatcherReg\n"
: : : "eax", "ebx", "ecx", "edx", "esi", "edi", "xmm0", "xmm1", "xmm2", "xmm3", "xmm4", "xmm5", "xmm6", "xmm7", "memory" );
I dunno. Just shooting at invisible dots in the sky now. :/
arcum42
Generated another seqfault.
And I'm pretty much trying random things at this point (as my code sample showed). I'll admit to wondering if the interface between the *.S files and the C++ files causes issues, given that all the assembly functions are wrapped in extern "C"...
Jake.Stine
Nah, I already eliminated that possibility. And for that matter, the one exception being thrown when doing BiosSkips works (or worked anyway). And the only difference between that and the exception thrown from the rcntUpdate_vsync is a couple nested function calls.
... and oh! I do see why removing the throw entirely works for resetting. I moved the EventTest call to a static function outside the context of the recompiler. Didn't think about it at the time, that it would fix that particular problem. I was just optimizing the branchtest code for the common case.
So yeah commenting out the throw in rcntUpdate_vsync would be an acceptable hackfix for now, although we still need to solve this mystery. I'll never be able to implement a quality PS2/MIPS realtime debugger without it.
arcum42
Alright, I'll put a hackfix in for the moment then. It'll let us pause and get a fresh perspective on it, anyways.
Jake.Stine
Well what we do know:
The outer try {} in recExecute works, but *only* for the singlely-nested call to exit the BIOS stub. Removing or adding try{} blocks, or adding a nested call to the DispatcherReg breaks that.
The inner try{} hasn't worked at all yet, but its behavior changes from "lost" exceptions to complete segfaults depending on the function nesting and try{} nesting.
So clearly it's SOMETHING to do with the callstack, but GCC's x86-32 callstack implementation doesn't appear to be documented anywhere that's indexable by google. (and it needs to be x32 -- x64 callstack is completely different).

Revision 2004

Hack! Make Resets work in Linux by not throwing an exception that is supposed to
be thrown, because gcc seems unable to catch it for some bizarre reason.
arcum42
Actually, it specifically has a grudge against ForceDispatcherReg & ExitRecExecute. I can throw an OutOfMemory error from that function, and it gets caught.
Jake.Stine
... well the OutOfMemory error is being caught in an entirely different location though, right? Or did you make an additional handler for it in recExecute() ?
Jake.Stine
"It was a very unfortunate oversight to require 16byte stack alignment while ABI only specifies 4 byte. This problem has been fixed in gcc 4.4 and above. You can safely use -mpreferred-stack-boundary=2 with gcc 4.4 and all stack variables will be properly aligned. However, we can't change the default back to 4 byte since it will break the existing libraries/applications which expect 16byte aligned incoming stack."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
I think this might be relevant to our problem.
Jake.Stine
Read the last couple posts in that thread, and I'm quite sure now the stack align assumptions of GCC is our problem here.
I had wanted to enforce 16-byte alignment of the recompiler's stack anyway, since the new rec makes it reasonably easy to do in an efficient manner. I'll toss it in and you can see what differences it makes. :)
arcum42
Well, tossing -mpreferred-stack-boundary=2 looks like it took care of the iVif issues. Still seeing the exception issue, but the iVif one had been bugging me, so...
Jake.Stine
Yeah there's a good chance the exception handler code (which uses glibc stuff) still needs 16 byte aligned stack to work reliably, or something. This is a major screw up by the GCC people mostly because they NEVER DOCUMENTED IT.
arcum42
Yeah, it is. But these are the same people who won't give us __naked, and have given us so many other issues.
I'm surprised gcc hasn't been forked...
arcum42
Though technically current gcc is actually a fork that was merged back into the main project, so it has been forked.
Anyways, I'm going to get some sleep...
Jake.Stine
Ok, confirmed that stack alignment is still our problem on exception handling. GCC relies on it even with the preferred-stack-boundary setting. I'll work on implementing an aligned stack for the recompilers. I might branch it since it'll require a handful of rec changes and could break things for a while. :p
Jake.Stine
>> Yeah, it is. But these are the same people who won't give us __naked, and have given us so many other issues.
You know there's some very brutal irony there, because iirc one of the rationales for not having __naked was that "the programmer typically can't utilize a function with no setup stub in a safe manner." Ironic considering that GCC itself has been generating dangerously unsafe setup/call stubs into functions for years.
And also I'd have a much easier time tracking and fixing this problem if I had naked functions at my disposal.
Well, fortunately we do -- we can use the emitter. :D I'll set up a branch for implementing aligned stack, and I think I'll make it the default on windows and linux alike. The overhead of aligning the stack is very minimal, I think, and it won't hurt anything to have windows and linux subject to the same aligned stack checks and balances (the mac also requires aligned stack).
Jake.Stine
In other news, I'm pretty sure this is a big reason why we're having crashing bugs with O2 and O3 optimizations.
arcum42
That was one of the other things I was thinking about, because I recall all those wacky crashing bugs that were introduced to pcsx2 when gcc 4.4 came out, since I had to do obscene things to the flag list to get any optimizations at all.
And if it gives any perspective, RMS[1] wrote gcc initially, and still is the head of the team developing it.
[1] Richard Stallman. If you've read anything about the FSF and origins of open source software, you've probably seen his name.
Jake.Stine
Yeah I met Richard Stallman once, in person*. I attended the FSF Conference in Boston in 1996 or 97. (*along with Linus)
GCC 4.4 optimization problems are likely a combination of automatic SSE vectorization causing 2 problems: killing our coveted SSE registers outside FreezeRegs safety, and stack alignment failures. There could be other assumptions the optimizer makes about stack alignment too. >_<
Anyway, still working on setting up a branch. Had some other outstanding changes to the gui I wanted to commit first tho. And! While we're at it I'm thinking we should import Zedr0n's NASM conversions of the asm/S files. The Mac port requires it because GAS on the Mac is fail, and it also unified aVif into a single file (!).
arcum42
That's cool. I don't end up much at conferences or conventions, so most of what I know about him is second hand.
I'm just browsing through Sif.cpp right now, since after that whole business with (sif0.sifData.data & 0xC0000000), I got a bit curious. I might do some cleanup on IopHw.cpp, too; I was looking through it recently, and it needs it.
Importing Zedr0n's nasm conversions is a good idea. Eventually it'd be nice if the Mac port was in trunk, and we had Zedr0n as part of the project, really. Of course, he'd need to be up to the current revision before we could really do much of that.
Jake.Stine
I think IopHw.cpp is unused, so don't waste your time. I rewrote it into IopHwRead and IopHwWrite. The old IopHw is just there for regression testing (not really needed anymore, the new code is clearly solid).
Jake.Stine
Actually I take that back, I think IopHw is still used in some places.
But yeah, the new IopHwRead/Write functions basically replace IopHw content *and* the IopRead functions in IopMem.cpp (which is the part I never updated on this branch - my R3000air branch has them all connected tho).
arcum42
That's part of why I'd been dragging my feet on it, actually, was because I wasn't sure how much of it is actually used, and was planning on checking that before doing too much on it, because I knew you rewrote part of it.
Looks to me like there are at least a few functions being used in it, though, so if I do a cleanup, I'll concentrate on those...
arcum42
Part of why I was looking at it was because of the whole HW_DMA#_CHCR/TADR/MADR mess. There are a bunch of defines I want to rework or get rid of, and that's one of the main places that uses them...
arcum42
And I don't even want to think of what bringing the R3000air branch up to date is going to take, next time you go back to it. Don't think it has any of the wx code in it currently.
Jake.Stine
It shouldn't be too hard. One of the reasons I put it aside was because I finally hit a point where I realized if I went any further I'd introduce major merging issues post-wx.
Probably the most annoying part will be handling some of the file movement and renames (which is why I haven't yet done a more aggressive move/rename regarding the core files).
mattme...
Kinda off topic, but Richard Stallman is very annoying. So much as mention "non-free" software around him (Or on an email list that he just happens to be on. A list that has nothing to do with the FSF), and you get lectured and yelled at, and he suggests you use a, generally vastly inferior, "free" app instead, with a vastly different feature set. Or possibly write your own "free" implementation from scratch. He's like a crazy religious fanatic screaming at unbelievers on the street.
Jake.Stine
>> He's like a crazy religious fanatic screaming at unbelievers on the street.
"like" that on the internet, yes.
"is" that in person, both in appearance and in behavior. (I do not jest)
mattme...
I've seen him on campus, but never talked to him. He scares me.
The whole free software thing does have logic behind it, and I believe in releasing source code when you can, but zealotry is *not* the way to convert people to your cause. I mean, if you're a religious zealot, at least threatening people with hell might help in that direction, but with just "free" software to work with, about all you can do is gibber irritatingly until normal people just avoid talking to you.
Jake.Stine
... well admittedly he didn't scream so much as just incessantly lecture on the evils of being an unbeliever.
arcum42
It's one of these things. He's done a lot to help the open source movement, given how much code he's written that's in common usage, especially in Linux.
OTOH, the way he acts drives people away from open source and Linux. And using open source everywhere is rather extreme. I don't have an issue with buying software if there isn't anything that suit my needs out there for free, and I don't feel like writing something equivalent.
But, in any case, a person who lectures you about the evils of non-free software, a compiler that lectures you about not following the C++ standards to the letter; I can easily see one being created by the other...

Revision 2005

Set the preferred stack boundary to 2 for the moment in Linux, and disable the
old iVif code, as this takes care of the iVif issues.

Revision 2006

GSdx: Recycle the m_merge texture instead of deleting it; and made a note about
a debug assertion that happens in XS2 (probably nothing useful, but no harm in
making a note for future references)
heatbla...
I`ve tested Wild Arms Alter Code: F. Works fine but there are those huge black triangles on the ground... mmm missing textures.
ramapcsx2
Vif unpack error, we know about it.

Revision 2007

cdvdGigaherz:
* Plugged up some various thread sync issues with the sector cache (caused
problems mainly on startup.init and during disc change detection)
* Added a thread sleep to the ReadThread when the dvd tray is empty or open
(speedup).
* Replaced a thread sleep with an Event when waiting on pending events
(speedup).
jacol...
great work jake

Revision 2008

Worked on SIF0dma a bit.
arcum42
Nothing too major here, really.

Revision 2009

Recompilers:
* Removed EBP push/pop stuff from the recExecute of the R5900 and R3000A both
(not needed anymore since we disabled EBP in iCore).
* Moved the legacy j8ptr and j32ptr buffers to iCore, since they'll go obsolete
at the same time iCore does; and nothing outside PCSX2 references them.

Revision 2010

User Interface:
* Fixed and added better Emulation/System menu updating. Suspend/Resume is
more consistent, and Reset grays itself out after being used.
* Entering plugin configurations auto-suspends the emulator.
* Changing plugins in the Configuration PAnel takes effect now without a
restart.
* Added preliminary support for an ExtensibleConfirmation Dialog box (contains
a sizer you can add content to, and also has an optional "[x] Do not show this
again" checkbox).
Bugfixes:
* Added some mutex protection to cdvdNewDiskCB; "just in case."
* Resolved several recursion and deadlock scenarios when (very!) rapidly
suspending, resuming, and resetting the emu.
Developments / Code Cleanups:
* Renamed SysCoreThread ExecutionModes: Suspend/Resume are now Opened/Closed
(which more accurately reflects the fact they opena nd close the plugins, and
helps avoid ambiguity with the "Paused" state).
* Added Exception::ThreadTimedOut, which is now thrown from Semaphore::Wait
when recursive wxApp::Yield() calls are detected, and a deadlock occurs
(basically cancels the current action which, most of the time, allows for full
recovery).
* Major Threading namespace cleanups, documentations, etc.
* Removed wxScopedArray (scopedarray.h) and replaced it with a better
implemeneted ScopedArray class.
* Removed toUTF8 class, which I only added a couple weeks ago because I didn't
realize wxCharBuffer had an implicit typecast to (char*).
* Implemented more Source/Listener events for Pcsx2App. CoreThread events are
sourced properly now, and added SettingsApplied and SettingsLoadSave Sources.
arcum42
Two quick things:
In Mainframe.h, on line 91, 'MainEmuFrame::' got left in accidentally.
And in PluginManager, on line 670, receiving a wxCharBuffer in Console.Writeln is enough to crash pcsx2 on opening in Linux.
arcum42
Never mind, looks like you're ahead of me.
pcsx2gu...
Wow gigantic commit! Took me like 30mins to just check out the diffs 0_o
Will test later :) Good job jake

Revision 2011

Fix release mode build compilation errors from the prev rev.
Jake.Stine
I noticed I can't build pcsx2 anymore in GCC 4.4 -- I get errors missing some of the __sync__ functions. I think I need to re-enabled one of the march flags for it to work (testing now).
arcum42
Strange; I'm building it without issues in 4.4.1. Though I've only really been testing the Debug build, for the most part, since I haven't felt like recompiling wxWidgets.
If a march flag works, you might see if adding -march=native to 'Other Options' works as well...
arcum42
Just a question on the threading code:
In the final else statement in Threading::Semaphore::Wait(), is that do... while statement supposed to be:
do {
wxTheApp->Yield( true );
} while( !WaitRaw( ts_waitgui_interval ) );
That is, is this supposed to be looping until sem_timedwait stops returning errors? This seems to be where the Linux version spaces out at exit...
arcum42
In fact, checking errno, when Linux goes into an endless loop, it's on this error:
[ETIMEDOUT]
The semaphore could not be locked before the specified timeout expired.
arcum42
Pcsx2 in Linux exits properly if I change the function to just be:
void Threading::Semaphore::Wait()
{
if( wxThread::IsMain() && (wxTheApp != NULL) )
{
do {
wxTheApp->Yield( true );
} while( !WaitRaw( ts_waitgui_interval ) && (errno != ETIMEDOUT) );
}
}
this isn't necessarily a proposed patch, but hopefully it'll give a better idea of where the issue is.
arcum42
To be fair, it looks like this works too:
void Threading::Semaphore::Wait()
{
if( _WaitGui_RecursionGuard() )
{
if( !WaitRaw(ts_waitgui_deadlock) ) // default is 4 seconds
throw Exception::ThreadTimedOut();
}
else if( wxThread::IsMain() && (wxTheApp != NULL) )
{
do {
wxTheApp->Yield( true );
} while( !WaitRaw( ts_waitgui_interval ) && (errno != ETIMEDOUT) );
}
}
It's just that besides the while loop issue, calling WaitRaw() while ( !wxThread::IsMain() || (wxTheApp == NULL) never comes back.
Jake.Stine
On 4.4 : --march=native didn't work. -march=i486 or anything higher did work. Could be specific to 4.4.0. I haven't upgraded to 4.4.1 yet.
On Threading:
What you did was effectively disable the semaphore wait, changing behavior of all threading in PCSX2 and possibly causing many race conditions. This fixes the Linux on exit bug only because what's happening is *another thread* is stalling indefinitely and the main/gui thread hangs on that.
What the code does is wait until the semaphore is signaled (which happens by some other thread typically). But we can't block with a single WaitRaw() because it causes the gui to become non-responsive. So instead the code loops (indefinitely!) and gives Yields() to the GUI every 100ms. That allows the GUI to be responsive.
Jake.Stine
So! The problem is whatever's happening in some other thread that causes it to not trigger its semaphore. Actually the other thread might not even be hanging,, it could just be "skipping" the semaphore for some reason.
Information that would be helpful to me: The hanging wait happens from a PersistentThread::Cancel or ~PersistentThread destructor? It should be one of those two, I need to know which.
Oh and #2: %73.76 likeliness this is an aligned stack issue causing pthread_cancel to "miss" the cleanup handlers when exiting directly from recompiled code, since it's possible the cleanup handlers are implemented using exception-style stack unwinding.
arcum42
Still odd that it was saying that some of the sync functions were missing till you did that, since all the march line was doing would be turning on some optimizations.
And the _sync_ functions have been there since gcc 4.1, iirc, so I'm not sure why they'd give issues.
And, yeah, there's a reason why I don't make commits involving threading. I figured that code would have introduced issues. I was just hoping it would yield some information, since the crash was after the point you're able to run in Linux. (Though you could probably replicate it running with GSNull, thinking about it...)
And it looked like the hang was happening after PersistentThread::Cancel called m_sem_finished.Wait();, and it made it to the last else. I wasn't checking for ~PersistentThread now that I think about it, though, so I should doublecheck...
Jake.Stine
Correction! -march-native works fine. I hadn't added it to both pcsx2 and utilities correctly. copy-paste fail.
Jake.Stine
Also, it's documented on the internet in a lot of places that GCC bases the addition of __sync_ functions to the .o files on the architecture target. Pre-386 CPUs didn't have interlocking, and GCC uses static inline insertion of the function (rather than external object linking) so that all __sync_ functions inline.
So if you don't set -march-i386 or better, it just doesn't insert the code (brilliant).
arcum42
Nice.
Oh, and we can turn on -march=native in trunk if you want. Just keep in mind that anything older then gcc 4.3 won't compile with it on.
And I checked, and the thread that was trying to cancel did indeed end up in WaitRaw from PersistentThread::Cancel, called from CleanupMess.
The other thread running got to WaitRaw from StateCheckInThread, called from ExecuteTaskInThread in MGTS.cpp.
arcum42
MGTS? Bah.
MTGS. My kingdom for an edit button.
At least, if nothing else, this has taught me the proper use of 'info threads' and 'thread #' in gdb...

Revision 2012

Hack in a frame limit toggle on F4 and TAB using a global int. :p
nahuel36gg
I was waiting this until wx implemented. For that reason i was using legacy gui. Now i can test wx
=)
lemuel2010
Great Hack, ramapcsx2.
chane2k1
great, i was using the legacy gui as my main until this was implemented. i hated having to activate and deactivate it in the .ini. does this also toggle frame skipping like it used to or just limiting? thanks rama.
heatbla...
Great! I`ll test it ASAP!
ramapcsx2
Only limiting for now, since that was the easy part (code was all there).
The skipper needs some real work (tm) :p
heatbla...
Limiter is enough. My games were running way too fast on my dual core @4GHz. Now I`ll get the desired 60fps! Thanx!

Revision 2013

Quick fix for duplicate keystrokes coming in from LilyPad when using keyboard
input Raw or DInput modes.
mattme...
Pad API really is a bit of a mess. A pad plugin could, if it wanted, completely eat keyboard messages. I used to do this, as it just seemed like a good idea, until Gabest modified GSDX to read the keyboard directly itself, which resulted in LilyPad breaking GSDX keyboard shortcuts, under certain keyboard input modes. Other pad plugins don't do this, of course.
Now you're saying with wxWidgets, you don't even want actual keyboard events?
mattme...
Or should I start eating keyboard events again?

Revision 2014

Win32: Attempt #1 at bugfixing the stdout/stderr redirection; Switched from
CreateNamedPipe to CreatePipe.
tom.mat...
Man, Don't overwork yourself!

Revision 2015

Bugfixed some of the ini creation code on startup.
Bugfixed a memory leak when running blockdumps.

Revision 2016

Cleaned up the redirection code a bit trying to figure out why does it refuse to
accept the redirection for stdout, but not for stderr.
The error still happens but at least the code is a bit cleaner.

Revision 2017

More cleanups and comments on top of gigaherz's work, and added a stdout pipe
concatenation thingie due to Windows liking to send 1-character messages to
begin every new message written to the redirection pipe.
desa...
I have one problem witch all beta versions of PCSX2 0.9.7. In all games compatible with older version of pcsx2 (0.9.6) is game's speed too high, higher than is normal... (25% - 50% higher). Is it normal? Will it be fixed??
Jake.Stine
No, it won't be fixed. We just like it that way. :p
Seriously, it'll get done once other things are mostly stable. And, for now, you can like hit the TAB key and enable/disable framelimiting anyway.
arcum42
The faster we emulate games the better, right? ^_^
No, there are just a number of things not implemented in the wx version yet. Framelimiting, patches, the profiler, the debugger, the Run Recent menu, memory dumps, some of the configuration menus, and everything on the logging window, to name a few.
In fact, I was looking at the logging code and noticing that not all the options listed in the window line up with the flags on varLog. (Though some might have different names, possibly.)
In any case, things are in a transitional phase. And the main parts of the emulator are working...
Jake.Stine
Yeah I'm not too unhappy really, except for Linux stackframe issues (which I'm still working on here -- I finished porting R5900 to the emitter last night, but still have to workout some bugs before I up the branch).
Once we get the stackframe issues solved, and I finish one more round of "Thread marry-go-round" (doing a final pass of implementations into Threading/PersistentThread that I'd been putting off), then it'll be almost free reign on implementing tertiary gui features and all 'dems :)
arcum42
Yeah, if it wasn't for the savestate issues with ZeroGS/ZZOgl, and the stackframe related issues, I'd be relatively[1] happy with the state of pcsx2.
I don't really use patches, for the most part, and the profiler, debugger, and memory dumps didn't work on Linux anyways[2]. Suppose having logging working is really the most vital tertiary function that's missing for me[3].
Though a working debugger would be nice, admittedly.
And I'm looking forward to seeing the R5900 branch. That was fast work...
[1] Though having a command line buildsystem would make me happier, admittedly; I just don't see it as a priority till we get close to a release.
[2] The debugger might have been partially functional at some point in Linux. I'm not entirely sure. It was broken when I got to it.
[3] Which is why I was looking at the code. I was thinking of starting to hook it up, with 30+ wxCheckbox variables. :)
desa...
yeah, TAB works... But still lower FPS in most games than lastest official 0.9.6 beta r1888. But it'll be definitely fixed in stable 0.9.7, I think.. :)
Good luck for development! PCSX2 is the best software! Play PS2 games on cumputer?? Before PCSX2 it was impossible...(other emulators sux...) Respect for all devs!!!
Later, I would like make slovak translation but I can't C or C++...:/

Revision 2018

Tested the cycle changes extensively on legacy_gui, they are fine.
So bringing them over to pcsx2/wx now.
They're tagged with "voodoocycles" in the source, to easily test for regressions
(or improvements!) :p

Revision 2019

Quick fix for GSdx10 crashing when entering/leaving fullscreen on pcsx/wx.
Ideally this should be reverted one time, it really made a difference in fps for
some DX calls heavy games.
ramapcsx2
pcsx2/wx.
The other one is here: http://www.pcsx.net/
xD

Revision 2020

It seems trying to second-guess win32api plays against you, so it's best to
assume it worked when the functions say it did.
(Fixes the stdout redirection for me.)

Revision 2021

SPU2-X:
New default values for soundtouch, fix the sound quality somewhat.
Also got rid of a small configuration dialog glitch.
chuuey
hey rama, thanks for update on this, but for some reason i'm getting bleeping sounds in ffxi and i'm not sure when it started but it was fine on earlier revs, for example when i load a savegame i get this big sort of boom sound, and after the all the sounds are making strange noises for a while and they they are fine but when i change zones they appear from time to time, any clues? I can try to record it if you want to check it out ;)

Revision 2022

More threading improvements:
* Added TimedLock to MutexLock
* Use MutexLock::TimedLock as a replacement for some sloppy semaphore use in
SysCoreThread and PersistentThread.
* Minor fixes to thread cleanup when exiting the App
* Added some extra deadlock protection to the blocking Wait and Lock functions
for Mutexes and Semaphores.
* Moved MutexLock and Semaphore implementations into their own files.

Revision 2023

Linux: Minor fixes for prev commit.
Jake.Stine
Ah crap, stupid rapidsvn committed the crap pcsx2.cbp I had been experimenting with locally.
What I wouldn't give for an svn client in linux that a) didn't suck as bad as dsvn, and b) still allowed me to checkmark the files I want committed.
Because hell if I'm going to use commandline svn and manually type in each filename.
arcum42
RabbitVCS, maybe?
Haven't tried it, but the screenshot looks like a gnome clone of tortoisesvn.
http://rabbitvcs.org/
Jake.Stine
oh good, I'll give it a try.
Jake.Stine
yay RabbitVCS is cool! I'm happier. But only until I find something new to bitch about.
arcum42
Glad to hear it.
If they had extensions for other file managers, which seems to be in their future plans, I'd try it. But I don't think they support Thunar yet, and I'm running XFCE 4 instead of Gnome right now, so I don't have Nautilus at the moment.

Revision 2024

aligned_stack branch: Preliminary work for having the recompilers align the
stack to 16 bytes, to appease the expectations of GCC and Mac OSX.
Done:
* EEcore aligns stack on entry and performs routine checks of ESP and EBP
integrity.
* Dispatchers are recoded using the PCSX2 Emitter.
Todo:
* Convert all C-code function calls from the recompiler to use the new aligned
stack setup.
* Implement stack-alignment checks and emitter-based dispatchers for the IOP.
Jake.Stine
Obviously I haven't actually tested compilation in linux yet, but hopefully it should be pretty painless since it's all emitter based now. :)
arcum42
Compiling wasn't too bad, though I had to remove aR5900-32.S from pcsx2.cbp.
Running it, OTOH, was a bit more problematic. I actually got an assertion immediately on starting emulation:
Opening plugins...
Opening GS
/usr/local/src/aligned_stack/pcsx2/System/SysThreads.cpp(248) : assertion failed in StateCheckInThread: Invalid execution state detected. (false)
Call stack:
[00] pxOnAssert(wchar_t const*, int, char const*, wchar_t const*, char const*) /usr/local/src/aligned_stack/common/src/Utilities/Exceptions.cpp:75
[01] SysThreadBase::StateCheckInThread(bool) /usr/local/src/aligned_stack/pcsx2/System/SysThreads.cpp:249
[02] mtgsThreadObject::ExecuteTaskInThread() /usr/local/src/aligned_stack/pcsx2/MTGS.cpp:253
It gives me an option to ignore the assertion, and if I do, it terminates when throwing ExitRecExecute. (Which is irritating, but I'd almost half expected it...)
Jake.Stine
There shouldn't be any relevant changes to the threading system compared to Trunk. Does the current trunk revision also give you the same problem/assertion? If not, that's very odd. :S
arcum42
Hmmm... looks like it does. Hadn't gotten around to testing the latest changes yet past making sure they compile; I was more interested in the branch.
Currently the trunk gives that exception, then runs properly if you ignore it. So, while a concern, that part should be irrelevant to the branch.
Jake.Stine
Ok the Assertion in mtgsThread is baffling, but not really important. I'll ponder it.
As for the exception throw, I'm going to make a commit shortly with an idea on that, which might fix it. And then afterward I'll look into getting gsNull working here so I can troubleshoot better.
arcum42
Oh, and just to mention, since that assertion is only thrown in the skip bios code, I tested it without skip bios on, and was able to boot into a game without issues.
Jake.Stine
Ah, thanks for that. Maybe I can reproduce it in windows then. :)
arcum42
No problem.
Just occurred to me when I was looking at where ExitRec and ExitRecExecute are called. I tend to keep skip bios on, unless it isn't working for some reason, because it saves time, so hadn't really thought about turning it off.
Jake.Stine
Yeah, and that's good really for this. The ExitRec exception is a predictable and easy to trap one, so when we get it working there's a good bet we're golden (I hope!).

Revision 2025

aligned_stack: fix attempt #1 for RecExit. Changed the jump to a call, which (I
think!) should give GCC the stackframe setup it expects to see when trying to
throw an exception.
Jake.Stine
I went ahead and fixed the makefile to use -march=aligned. We can worry about retaining better legacy compiler support from the (future) CMake scripts. Codeblocks projects will be bleeding edge. :)
Jake.Stine
Also! If the bios booting works now, then go ahead and try to "mix" it up a little. Make an __exitRec() function and call ExitRec from that, for example. Just to make sure it's actually working and not just lucking into an aligned stackframe.
I'll go fix the skipbios threading issues now. :)
arcum42
No difference on this version from last revision, unfortunately.

Revision 2026

Added some missing semaphore/mutex resets, and bugfixed the emitter when using a
certain type of complex indirect sddressing ( ie, ptr32[addr + (eax*4)] )
Jake.Stine
I couldn't reproduce the assertion failure in windows, even through SkipBios. I'll see about getting gsNull working and try that.
arcum42
Now that's irritating.
After this revision, it now just hangs at the spot where it was throwing the assertion before (Right after opening GS).
The change to ThreadTools.cpp is where the hanging is coming from, btw. If I revert just that change, it gives the assertion as before, then continues properly.
arcum42
Oh, and GSnull ought to compile straight out of the codeblocks project, btw.
Jake.Stine
yeah it did, but dunno still if it'll *work* (still waiting for GCC to rebuild all .. takes like 15 mins on co-linux ><)
Ok do me a favor in the meantime: Comment out this line in mtgs.cpp:
SendSimplePacket( GS_RINGTYPE_CRC, crc, 0, 0 );
(line 790)
And try to boot. You'll be missing CRC info, but it shouldn't deadlock or assert anymore (I think!).
Jake.Stine
... and if that works then I'll prepare a proper fix. :)
arcum42
Afraid not.
Seems like Linux wants to give more then it's fair share of headaches right now.
Jake.Stine
I got gsNull to work (sorta). Long enough for my CoLinux to run out of memory and crash. lol. I'll have to expand the memory config and what not.
But it did at least open plugins before that happened.
arcum42
Ah, good.
And, yeah, to fully run the emulator, it's going to need a decent chunk of memory.
Oh, and just so you know, if you run pcsx2 with gdb to debug, it gets the signals before our signal handlers do, so you'll find yourself having to repeatedly type continue every so often to do debugging when the emulators actually running. (Or rather, return seems to repeat the last command, so you'll type continue once, and then keep hitting enter.)
Jake.Stine
Ok can reproduce the deadlock fine, and am troubleshooting. Codebocks gdb interface doesn't appear to want to let me switch thread stackframes while debugging, but I'm managing with breakpoints well enough. I should have it fixed shortly :)
arcum42
You can always run it from a commandline interface:
From the bin directory do:
'gdb ./pcsx2'
Set up breakpoints with break [line number/function/address]. Or you can always just hit ctrl-c to stop it.
run - to start it.
then, after it breaks:
info threads - to tell you what threads are running
thread # - to switch between threads (with the number from info threads)
bt - to get the backtrace for the current thread,
arcum42
Oh, and 'continue' to start it up again. I've found the built-in help useful, too.
arcum42
Hmmm... New trick I found:
handle SIGSEGV noprint nostop
Takes care of having to type 'continue' every 5 minutes.
Jake.Stine
Yay I got PCSX2 to boot in CoLinux :D
Pretty sure I have the threading issue fixed. Still reviewing my code, and going to do some hard tests (lots of rapid reset/suspend/resumes).
arcum42
Great!
Of course, it's probably a good idea to test in Windows, too, just in case. You know how that goes...

Revision 2027

wiki: Fixed an issue related to the fact that google's TOC doesn't differentiate
between same named headings, causing a few links to be incorrect.

Revision 2028

wiki: Fixed the rest of the TOC issues that I happened to overlook the first
time. Thanks Lana!
shadowladyngemu
Lol silly google indeed.

Revision 2029

More thread sync fixes (these mostly only showed up on linux, because of threads
starting a lot slower); fixed by including a startup signal to let the creating
thread know when the worker has aquired its persistent locks.
arcum42
Looks like that's the deadlock when starting issue taken care of.
It being a timing issue makes sense. That is one of the big things that would vary between platforms.
Jake.Stine
Yeah. In windows threads start almost instantly, almost in blocking fashion, so a few lines of code in the thread run before the pthreaD_create call even returns. In linux they're just added to the bottom of the scheduler or something, and it doesn't even get to them until a couple hundred instructions have run on the main thread.
arcum42
I wonder if something similar is causing the issues when exiting pcsx2?
I could see canceling the threads potentially varying the same way...
Jake.Stine
The actual problem with exiting (in win32) is nested window message/event handling, I think. I try to handle messages on all sem and mutex waits to avoid having the gui become unresponsive, but when that's done while exiting something the exit procedure gets borked.
For example here, on random, the SysCore thread gets restarted while it's waiting for a close, and then bad things happen.
However, on Linux I think it's just the pthread handler failing to successfully cancel out of Recompiled code or something. >_<
arcum42
Sounds like it's going to be a pain.
Noticed that Resetting isn't working properly now, either, btw. (Namely, if you reset, it suspends emulation, and the gui locks up if you try to Resume it.).
At least GSNull's working out properly. Feel free to make any modifications to it that make things easier for you. Though I don't particularly recommend implementing GSOpen2 on it yet, because, in my experiments with it, it was crashing ZeroPad/OpenPad[1].
One of these days, I'll get around to fixing that.
[1] I think I have a fair idea why[2], I just wasn't having much luck working around it.
[2] The pad plugin expects a XDisplay, and gets a GtkWindow. And, yes, ZeroGS actually uses X11 instead of Gtk for its window. I'm assuming it was easier to implement.
arcum42
The reset issue isn't anything critical, btw. I just happened to notice it, and wanted to make sure I mentioned it.
One rather frustrating thing I realised: I went to see if some changes to gifMFIFOInterrupt made any difference in emulation, and thus far, I'm having trouble finding games that actually call the routine.
I'm starting to wonder how much code we've got that to all appearances is used, but never, or almost never gets called in practice...
Jake.Stine
>> And, yes, ZeroGS actually uses X11 instead of Gtk for its window. I'm assuming it was easier to implement.
ZeroGS uses glX, so it needs an x11 handle for that. I was hoping the native window handle in GTK would be an X window handle, but I guess that would have been expecting too much. ;_;
Jake.Stine
>> I went to see if some changes to gifMFIFOInterrupt made any difference in emulation, and thus far, I'm having trouble finding games that actually call the routine.
... I think that's because we don't even emulate the GS FIFO. We have our own MTGS, so we just tell the GS FIFO that it's always empty. That way the EE never bothers to waste cycles stalling/handling FIFO requests.
Jake.Stine
To explain in depth, the GS has a FIFO of its own that GIF packets typically cycle through, so when doing direct writes to the GS, the EE queues up a few bytes and, on occasion, may have to wait for the GS to catch up if the GS lags behind in processing. But I'm not sure if that's the same thing as the MFIFO or not (but my hunch says it is).
So we just hardcode the GS FIFO to always return empty (it's pretty much always been like that since like 0.9.0 or something).
arcum42
My solution for the ZeroGS thing was going to be to get the XDisplay handle from the GtkWindow, since, obviously, Gtk uses X11. It's possible to do, but I didn't have much luck with it.
Oh, and I actually meant mfifoGIFtransfer, but it's still the same issue. That was actually called in 2 places, one of which is hardcoded to 0. I thought it might be called by the other, in Sif, but it's only called if dmacRegs->ctrl.MFD == MFD_GIF, and I'm not sure that ever happens.
Makes sense, though. Sounds like it's one of these areas, like the cache, that we can get away with not implementing. And I recall seeing something about Fifo not being implemented when I was doing a few things in the ipu code, but didn't immediately make the connection...
Main reason why I was looking at it is that I was looking at how gifstate is used. It's set to one of 3 states ( 0 - 2), but then has a fourth state of empty that it sets by toggling a bit, independent of the two.
Trouble is that gifstate is often directly set, clearing the empty state, and the three places it's tested aren't tested properly.
I was going to separate it into a separate variable and freeze it. Trouble is that the only place that checks whether it is empty (incorrectly) is mfifoGIFtransfer.
I might separate it out but not freeze it. Looks like every function using it has fifo in the name. :)
arcum42
I'm not sure if dmacRegs->ctrl.MFD ever equals MFD_GIF in that function, rather, though I suspect a few flags may just never be set...
arcum42
Oh, and "has a fourth state of empty that it sets by toggling a bit, independent of the *other three states*".
I need to proofread my comments more.

Revision 2030

Yet more thread sync fixes, mostly to do with rapid reset/resume/suspend/exit
actions.
Jake.Stine
Ok I confirmed the remaining linux thread sync issues are caused by the Recompiler breaking it's ability to exit the thread and do proper cleanup. So time to merge this into the aligned stack branch and start doing some debugging :D

Revision 2031

wxWidgets/Win32: Bugfixed wxLog getting perma-suspended when calling
YieldIfNeeded

Revision 2032

aligned_stack: sync with trunk; some bugfixes to the stack prep on entry; and
re-enabled the esp/ebp integrity assertions.

Revision 2033

Gave the frame limiter some smarts so it can sleep the EEcore a bit if there's
nothing to do for a while.
ramapcsx2
Works perfectly. Really nice implementation, too! :)
pcsx2gu...
Great job there :) This should make multitasking with PCSX2 running so much better...plus it's now energy friendly :P

Revision 2034

aligned_stack: no real progress... just reached a point where I need to move
dev over to my windows so I can have real debugging/disasm/memory dumping
ability. (this is the most horrible job I've ever undertaken, btw)
Jake.Stine
FAIL.
Ok not entirely. What I did figure out is that GCC exceptions aren't going to work, ever. But I got everything else working relating to stack management (tho to do so optimally required some cleverly evilness).
Im trying to use setjmp/longjmp now as a substitution for exceptions.
(also, something's still "wrong" with pthread_cancel I fear -- The hang on Reset+Resume is caused by the SysCoreThread never executing its cleanup, which should be neigh impossible -- I'll investigate more).
Jake.Stine
AND! Someone in LinuxLand will owe me a huge solid if I get this crap to work.
arcum42
Believe me, it's appreciated.
And remember, it's not like there are any deadlines or anything. If you get too frustrated, feel free to work on something else for a while, or "test" a few of your games in pcsx2.
And I guess we'll just have to make sure we don't call exceptions in certain areas of the code. That's frustrating...
Jake.Stine
Ok I confirmed that pthreads on gnuc use C++ exceptions to cancel threads, which (unfortunately) don't work because GCC insists on using non-standard, overbearing, compile-time-constructed stack unwinding mechanics, just to save an extra cycle or two on the creation of C++ instances.
(meaning it's literally impossible for me to make exceptions work across the recompiler's stackframe, because we don't know at compile time what the recompiled code entry/exit/unwind addresses are -- and even if we could know this info, it's tons of code .. and very complicated at that).
So what I'm going to do instead is use a manual cancelation flag on GCC that does a longjmp to a point outside the context of the recompiler, and then do a pthread cancelation check from there.
Beautiful, eh? :)
Jake.Stine
>> And I guess we'll just have to make sure we don't call exceptions in certain areas of the code. That's frustrating...
Eventually I'll set up a set of macros or functions that dual-purpose as either setjmp or exception (for gcc or msvc respectively). Under GCC it'll longjmp to a point outside the recompiler and then re-throw the C++ exception from there. It's a hack, but it'll work for what I want it for (Which is eventual "spot-on" debugging of the PS2 Virtual Machine right from the context of the recompilers).
Jake.Stine
The other drawback of G++ exceptions:
* They can't propagate across plain-C-compiled code (you must use -fexceptions on the C code, but if it's like pre-built library code you're screwed).
I don't think that's a big worry for us, and I think GCC now comes with all of glibcbuilt with -fexceptions enabled by default (but I'm not sure and, as usual, that could be platform/distro dependent).
Jake.Stine
Bawahhawahahaha!
I've just about fixed everything now. :D
Suspending, resuming, cancelling, throwing, catching, etc.
(though I haven't yet done the second part of the stack alignment yet, which is to implement proper cleanup for cdecl CALLfunc stuff in the recs and/or switch to __fastcall)

Revision 2035

aligned_stack branch progress!
* Implemented setjmp/longjmp method of escaping recompiled code, circumventing
the deadly pitfalls of the g++ exception mess.
* Use longjmp to jump to a "safe" location (outside recompiled code) for
suspending and canceling the SysCoreThread (see StateThreadCheck_LongJmp)
* I'm the stack daddy mack. That's right. Uh huh. Uh huh.
* Test for m_detached in PersistentThread::IsSelf, since Linux likes to recycle
thread handles in a hurry (like, as in, consecutively)
* Fix a deadlock in the Consoole Log (seems to be GTK+ specific, and in fact
I'm pretty sure wxApp->Yield() isn't thread safe and thinks it's recursive even
when it's not)
Jake.Stine
To explain my Yield suspect: It has one of those RecursionGuard() thingies in it, and I suspect it's being called from multiple threads in parallel and then the RecursionGuard falls out of sync (it's a static var shared by all threads). Because what happens is afer a few resets and suspend/resumes suddenly Yield says it's called recursively even though the stackframe clearly shows it's not.
I'm pretty sure I only call Yield for the main thread in PCSX2, but I might have missed an instance. If PCSX2 is covered then it means wxWidgets is doing it internally somewhere and we can't do anything but try and work around it. Fortunately, if it's not properly fixable then it's only going to be a problem in case of rapid abusive start/restart/suspend/loadstate/savestate kinda stuff. (and most of that stuff just safely "gives up" and goes back to the message pump if the action deadlocks on the yield).
And everything else in Linux appears to be working. *crosses fingers*
kaboo...
"* I'm the stack daddy mack. That's right. Uh huh. Uh huh."
... what happened there?
also will there we a benefit for windows users after this branch is completed?
jaens...
I'm curious about something. The safe location is in a function that hasn't yet returned when you use longjmp... right?
arcum42
It's running beautifully. I only see one thread-related issue, and it's easy enough to wallpaper over.
For whatever reason, the following assertion pops up several times (once for each thread, I'd imagine). If you ignore it, reset, exiting the program, suspending, resuming, etc, work fine:
/usr/local/src/aligned_stack/common/src/Utilities/ThreadTools.cpp(431) : assertion failed in _DoSetThreadName: Thread affinity error. (IsSelf())
Call stack:
[00] pxOnAssert(wchar_t const*, int, char const*, wchar_t const*, char const*) /usr/local/src/aligned_stack/common/src/Utilities/Exceptions.cpp:75
[01] Threading::PersistentThread::_DoSetThreadName(char const*) /usr/local/src/aligned_stack/common/src/Utilities/ThreadTools.cpp:431
Now, _DoSetThreadName only actually does anything in Windows. So my fix would be to move the #ifdef right below the assertion above the assertion and not worry about it. ^_^
Jake.Stine
>> I'm curious about something. The safe location is in a function that hasn't yet returned when you use longjmp... right?
The safe location is a function outside the scope of recompiled code. So it looks like this:
void recExecute()
{
// Sets the jump and handles the resulting longjmps too (setjmp is fun that way)
StateThreadCheck_LongJmp();
// And now enter the recompiler (this is the part that breaks g++ exceptions)
EnterRecompiledCode();
}
... so from code called inside the recompiler, I have to longjmp to StateThreadCheck(), which itself has a "valid" unwindable g++ stack. This allows pthreads to issue "cancel" to the thread. :)
Jake.Stine
>> also will there we a benefit for windows users after this branch is completed?
Not really, other than I'll be able to spend less time doing Linux-specific hackups for a while.. ;) This branch is almost entirely for Linux and Mac users. I'll leave the aligned stack rules in place for Win32 also, but I doubt it will be any faster or slower.
The concept of aligned stack on x32 architecture is like fail anyway. On x64 forcing an aligned stack is a speedup, but on x32 not really (I might blog on this since I spent like 35 hrs learning it, so I could realize in the end GCC is fail and has special compile-time mechanics to it's exception unwinder, so I can't bind to it with dynamic code *anyway*).

Revision 2036

Change a few project options and get rid of _unused.
arcum42
I added back in -march=i486 due to braindead compiler behavior, and added back in the stack boundary flag.
And _unused is used, so I got rid of it, since we don't really use it.

Revision 2037

A few changes to Sif, SPR, and Gif I've had sitting around.
arcum42
If it seems like nothing actually uses the new gifempty variable, it's because I haven't hooked it up yet...

Revision 2038

Second half of __unused removal -- comment out (remove) names on unused
parameters as per the guidelines of some C guideline that all compilers adhere
to (this suppresses the same warnings __unused used to suppress).
Minor cleanups to Counters/Gif.
Jake.Stine
OH and this should fix that thread affinity error on _SetThreadName in Linux as well (forgot I included that :p)
arcum42
Right, forgot about that.
And I'll copy ThreadTools.cpp into the aligned_stack branch, and see if that takes care of it... :)

Revision 2039

wxWidgets/Win32: Cure wxWidgets of some over-joyous re-allocation of formatted
strings which was (presumably) added because of limited memory constraints on
portable devices (which doesn't apply to PCSX2).
Jake.Stine
Also, for apps that don't make much use of printf() this wouldn't have been an issue. However PCSX2 does, especially when doing logging, so this gets rid of a lot of extra worthless Heap allocations (nearly 2-4 per each log write, in fact -- although that would have been less after my next commit which will improve the logging system considerably).

Revision 2040

Cleaned up the comments in the EE Memory Map :)
dyorgio
very good :), this project is the best!

Revision 2041

* Improved the framelimiter sleep mode more (less cpu used and more responsive
to fps fluctuation near the 60fps line at the same time)
* Added timeBeginPeriod() to improve the Win32 kernel scheduler resolution
(improves sleep accuracy and thread responsiveness)
* hackfixed some code that made exiting pcsx2 "slow" sometimes.
Jake.Stine
Actually in one of my next commits I'll include some logging of the framelimiter's exact error post-sleep (and possibly include a handler). The extra code wouldn't be a burden on slower machines since it'd only b relevant to computers running way over-fps anyway.
shadowladyngemu
Nice never liked those fluctuations in 60fps hope this helps.

Revision 2042

GSdx: Possible fix for DX10 leaking memory.
Jake.Stine
Merry christmas, rama :p
(assuming this works, which it probably doesn't)
heatbla...
Great news!
dyorgio
The OpenGL render in GSdx plugin is ok?
this can be ported for linux?
this project : http://pcsx2-mac.quant0r.com/
use OpenGL in your port od pcsx2 to mac.
But, ZZogl is a abandoned pluging.. :(
really is a shame the team pcsx not have a mac :-)
peskalbe...
good news, great job.
When can we download new plugins for the emulator
Jake.Stine
Well the memleak fix doesn't work, so suppress the excitement for a while longer.
>> The OpenGL render in GSdx plugin is ok?
Nope, doesn't work at all.
>> But, ZZogl is a abandoned pluging.. :(
No, ZeroGS is abandoned that this time. ZZOgl is updated (but not on our svn here for the time).

Revision 2043

superVU bugfix: Disable x86 regalloc since disabling EBP allocation causes some
kind of problem with it (fixes God of War2, and is probably a speedup also --
not that it matters since sVU is mainly there as reference for solving NAN/INF
problems). Also, removed a bunch of code that's no longer needed thanks to EBP
being removed from regalloc.
dozafix1992
Nice, now Champions RTA also works with sVU too. :)
However, im not 100% sure if it was this revision.

Revision 2044

Brand new approach to console logging, should be a lot more efficient, and is
relatively deadlock-free. Also fixes most of the scrolling issues from prev
versions.
Jake.Stine
this took literally 10 hrs of programming without breaks to figure out. It was nearly impossible to get the damn thing to behave the way I wanted. (and I have no idea if it works in linux at all, although typically linux rich textboxes are much less annoyingly stupid than win32 ones)
Jake.Stine
Well I did take a couple breaks to write some posts to the forum. ;)
Jake.Stine
Also, the one thing that's still missing from the console log is proper efficient handling of the console when it's closed, although that should be very easy compared to this >_<

Revision 2045

aligned_stack: Finished conversion of all CALLFunc and _callFunctionArg1
functions to aligned-stack safe __fastcall invocations; only IOP's psxExecute
and dispatchers remain to be done. (rev is fully functional in this state tho,
on win32 at least)
dozafix1992
Stop commiting, i can't keep up with compiling ;)
Besides, what do 'we' get once this branch is finished?
tatsuy...
Nice job, alot of code changes. Just to let you know as of the early r2k revisions Ace Combat 4 crashes at intro, used to run fine. Still does it as of r2044, perhaps someone that knows how to compile can test it in r2045 if they have this game.
Jake.Stine
>> Besides, what do 'we' get once this branch is finished?
A working MacOS-X port. Yay? :)
Jake.Stine
>> Just to let you know as of the early r2k revisions Ace Combat 4 crashes at intro, used to run fine.
A more precise revision would be helpful here. None of the devs have Ace Combat 4 as far as I know.
tatsuy...
>>A more precise revision would be helpful here. None of the devs have Ace Combat 4 as far as I know.
Ok so I found r2008 and that is the last version I can find that it runs ok with. Starting at r2012 it crashes, I am unable to find r2009, r2010 or r2011 anywhere, sorry.
tatsuy...
Looking at the changes of r2010 I'll guess that its possible the break might of originated there as there was alot of changes done.
Jake.Stine
More likely r2009, since it has changes to the core emulator. r2010 is mostly a GUI/framework commit, with the only core emulator changes relating to a change in the string lib (which, if broken, would probably break *lots* of stuff).
By the way, try both microVU and superVU, and see if the same problem happens in both.
tatsuy...
Still crashes with superVU in r2012 and above. The fault module is pcsx2.exe not GsDX if you were wondering.
pcsx2gu...
Can't replicate it here. I have the JAP version of Ace Combat 4 (Shattered Skies) and both microVU and superVU work fine with the game in the latest revision. Is your crash only with superVU?
tatsuy...
I have the US version it crashes with microVU and superVU in the revision posted above and the latest r2054 revision. Tried coping all the latest plugins from r2054 to the r1972 legacy GUI and no crash there so its not the plugins.
tatsuy...
Checking "bios skip hack" lets the intro play for about 1 second with sound and all but still crashes at the exact same moment, thought I'd throw it out there. This is with r2073.
pcsx2gu...
So why are you adding the comment to r2045 exactly??

Revision 2046

aligned_stack: synced with trunk, to bring in the new console code for
additional testing under a (properly working!) linux.
Jake.Stine
Woohoo! Gcc compiler bug! But I found a workaround. >_<

Revision 2047

aligned_stack: Linux has never worked so well!
* made a workaround for some obscure GCC templating bug
* Fixes the assert from PersistentThread when starting the emu
Jake.Stine
This is working so well now I think I can go ahead and merge it over into trunk, after I fix up a couple silly compilation errors in MSVC in this revision.

Revision 2048

aligned_stack: Implement full compliment of stack alignment options for the IOP
(untested in gcc/linux yet); and fix a compiler error in MSVC.
Jake.Stine
geh, I broke it just before comitting as usual >_<
Deleted part of some unused code, but not the other part.

Revision 2049

aligned_stack:
* Added -fno-strict-aliasing to the ever growing list of gcc optimizations that
can potentially cause perfectly good C code to generate entirely broken results.
* Removed the preferred-stack=2, since this branch *should* run fine without it
now.
* Have Release builds in Linux SIGKILL when encountering an unexpected SIGSEGV.
* Fixed some deadlock issues with the new console logger (it introduced cancel
points, which is a good thing! unless you're the EE recompiler and you swallow
up any attempt by GCC to cancel a thread)
* Compilation error fixes.
Jake.Stine
Debug mode runs fine, with or without the EBP stackframe setup code. Release mode crashes fairly instantly (haven't had time to troubleshoot why). I can't remember if you said release mode always crashes or not -- and I never bothered to test it until now.
Going to leave this in branch for a little while longer, and if everything seems ok here then I'll merge.
@Arcum: In specific, please test the VIF/SSE crash thingie, with the preferred-stack option disabled as it is now. I think that's a good test of whether or not it's "officially working" as it should.
Jake.Stine
Oh and my above comment is entirely referencing linux. Win32 debug and release modes both work fine, as usual.
arcum42
While the iVif issues were unreliable, I tested a few areas I recalled crashing, and they seemed to be fine without the preferred stack option. Though, oddly enough, I accidentally tried testing with Peops for a sound plugin, and it started stalling out in the exact places that iVif would have crashed.
Don't usually even test with Peops, though, and it works fine with ZeroSPU2. Peops isn't exactly a plugin I'd advise using anyways...
Jake.Stine
Yeah I think that's just a fluke. Peops has stalling issues in general. I never got it to work half decent when I first experimented with PCSX2 a year ago. ;)
But goodie goodie. I'll sync and merge.

Revision 2050

GSdx:
Fix Xenosaga 2 and 3 fog effect, not sure it's handled correctly but at least
it's handled.
ustve...
something real
Sheena.F...
Finally a fix for xenosaga 3!
Sheena.F...
Tested, it's still not perfect but definitely looks better than before.
kaboo...
WTF sheena==```??? XD looks somehow exactly like the name of sheena from Tales of Symphonia she was cool Oo
now I can finally start playing Xenosaga^^
heatbla...
I am on Zarathustra on Xenosaga3... No problems with the game. Maybe some graphical issues when activatina certain skills lihe Hilber effect and some of the Testament`s moves... But it was quite well playable.
Sheena.F...
@kabooz: Actually I did choose this name from Symphonia
Yes the game is quite playable. I'm currently in the Durandal. Just a bit graphic issues here and there, especially when you summon erde kaiser and some other ones like heatblazer mentioned.

Revision 2051

GSdx: Fixed a memory leak in m_weavebob when changing interlacing modes (same
thing that caused the m_merge leak -- I chose to delete instead of recycle since
I doubt the texture would be useful for anything besides the 1-time interlacing
setup, so no point cluttering the pool with it).

Revision 2052

Why didn't I think of this sooner? Added a pre-alpha announce when starting
PCSX2 0.9.7 for the first time.
Also: Minor fixes to the console logger (Win7 report of corrupted cursor)
kaboo...
great absolutely ingenious !
Zeydl...
Well, the most horrible thing, that I need to do a svn reverse and dislean after every try to compile new pcsx2, otherwise 1736 crushed when trying to read plugins directory with newly compiled plugins.

Revision 2053

aligned_stack: sync with trunk, preping for merge.
Jake.Stine
.. oh and *now* I realize GT4 doesn't work. >_<

Revision 2054

Reintegrated 'aligned_stack' branch. General summary [interesting to Devs only,
really]:
* EEcore recompiler aligns the stack on entry for all platforms.
* IOP recompiler aligns stack for GCC/Mac by default (can be force-enabled for
all platforms via compiler define)
* Added setjmp/longjmp to the EEcore recompiler, used by GCC to exit the
recompiler in efficient form (Win32 platforms use SEH).
* aR3000a.S and aR5900.S removed and replaced with x86Emitter generated
dispatchers.
* All C functions called from recompiled code use __fastcall (simple, fast,
retains stack alignment in neat fashion)
Jake.Stine
I fixed the GT4 bug before committing. Hopefully things are good :)
(Rama will have to do some benchmark comparisons .. not sure how the aligned stack stuff will impact it)
Jake.Stine
Crud, I totally neglected the stack alignment on the VUs, thinking it wouldn't be needed for some reason. But the VUs do call some MTGS functions, so it needs to be considered.
kaboo...
good job now we "only" need a fast compatible OGL graphics plugin and then almost everyone is happy
alright after the gui is finished almost everyone is happy
@jake since you wanted to finish the gui before you concentrate on your R3000A branch I wanted to ask if you have already a plan for how you'll pick up the project
just curious Oo
arcum42
Glad to have this merged in. I did just notice that the function keys aren't responding, though. I'll have to play with that one a bit...
Jake.Stine
>> Glad to have this merged in. I did just notice that the function keys aren't responding, though. I'll have to play with that one a bit...
Oh, crud. That's because the handler for keyboarding is in StateCheckInThread. But StateCheckInThread has the thread cancellation point in it, so I had to longjmp to the safe spot outside the recompiler to call it. Jumping out of the rec on every vsync is unnecessarily slow, but would fix the problem.
A better fix might be to change the code around a bit so that the setjmp/longjmp belong to SysCoreThread instead of iR5900, and then it would perform the longjmp to a spot recorded in ExecuteTaskInThread() -- the spot right before calling cpu->Execute.
That probably makes more sense.
arcum42
It probably does make more sense in SysCoreThread. And I can deal without f-keys for a little while if need be. Main thing I'm missing is the ability to adjust ZZOgl's settings on the fly right now.
You know, it's a shame pcsx2 has no real way of knowing what the graphical plugin is doing with the function keys it has reserved. It'd be nice if it was abstracted where plugins just passed pcsx2 something along the line of what CommandDeclarations has in it right now, and pcsx2 took care of implementing it.
Then we could do things like having those commands also be dynamically added to the menus, for example. And it'd be more flexable then telling it that it can handle this range of function keys, and nothing else.
Not really related; it's just something that's been bugging me for a bit. Goes under the category of "ideas for the new plugin api", I suppose.
Jake.Stine
@Kabooz: No idea. I'll jump that hurdle when I get there.
I'm never worried though. I've not had a piece of code I couldn't make work in like 10 yrs now. I'll do the merge by hand if I have to. Most of my changes were entirely new files anyway -- I didn't really change all that much in the rest of PCSX2 on that branch.
Jake.Stine
I take that back. I tried to unravel IPU from the evils of the Coroutine once, and I failed. That's about it though.

Revision 2055

GSdx:
Added a somewhat more accurate upscale option via GSdx.ini. Not tested much! :p
ramapcsx2
accurateScaleMulti = x
where x should be 2, 3 or 4 (everything else will be ignored)
ramapcsx2
Oh yeah, if accurateScaleMulti is 2,3 or 4, then it overrides the d3d internal res.
kaboo...
I hope it works as good as I think it does O.o
and if it does it maybe could be integrated in the plugin menu O?o
ps... google code is stupid they write "delete" but mean "hide"
zantezuken
As far I can see there is no that annoying black border in VP2 anymore, but well.. there is still "ghosting" in Gow2 when upscaled.
serban.a...
well it doesnt work for me...no matter what d3d internal res i use ( usually 2048x2048) and no matter if i set accurateScaleMulti = x (2 or 3 or 4),the games in wich i have problem with black lines..look like they're on native resolution.
ramapcsx2
It works, it just doesn't magically fix every problem with upscaling there is (but half of them) ;)
serban.a...
games that i tested are resident evil dead aim,forbidden siren 2,and death by degree
zantezuken
@rama
What games this feature fixes?

Revision 2056

Revamp the FreezeRegs functions.
pcsx2gu...
Broke compiling in Windows :P

Revision 2057

Just cleaning up the changes in r2056 a bit.

Revision 2058

GSdx:
- The Xenosaga fix was wrong, this is better.
- Disabled the pitch conversion code, it's too broken to be used :/
heatbla...
:) Thanx should have played the game now to express the full quality... guess I beat it without express the pleasure of graphical sweetness... Next time then :) Now if only Steambot Chronicles....
heatbla...
BTW I`ve already reported the hang in Bakugama Battle Brawlers and the emu crash on Front Mission 4. Hope that helps with the newest plugins/svns
Sheena.F...
there's still a graphical issue when summoning erde kaiser.

Revision 2059

Compilation errors fix: MSVC needs 'extern' qualifiers on functions declared as
__forceinline, otherwise it assumes static/local scope when it compiles them.
pcsx2gu...
Thanks for the quick fix Jake :)
arcum42
Interesting. I realized that I'd forgotten the extern keywords after my last commit, but didn't realize that it broke MSVC, so I was just going to throw it in whenever I got to my next commit...
kaboo...
interesting indeed, I had the problem but I wanted to update my VC++ 2008 to SP1 before I started blaming someone for braking windows compiling

Revision 2060

One last pass on the register freezing code for now, and remove the remnants of
the iVif workaround code.
arcum42
Don't worry, this one was tested on Windows.
dozafix1992
Nice, now the logger is not anymore like:
Opening PAD
Opening SPU2
Ope...
Closing PAD
Closing GS
Closing GS
<hangs>
And it also shows more then a gray window.
Or it was fixed by a simple reboot, who knows ;)
bigdeak
Nice refactoring in the mmx and xmm :3
arcum42
Thanks! I'm rather happy with how the refactor went myself. I think the new version is easier to follow, and more self contained, as well...

Revision 2061

GSdx:
- Worked on the configuration dialog, bringing in the scaler option
- Changed the DeviceSize code to use Jake's kinda better method. Fixes some odd
resolution games :)
Castrat...
Is MSAA available through the config panel now, or is that considered too unstable/leaky?
serban.a...
yeah that should be included too:)
ramapcsx2
It leaks memory somewhere, highly unstable yet.
heatbla...
There are some graphical issues in Wild Arms 5 on some enemies.
eliotfur
Somewhere between r1969 and this one GSDX began to stretch Silent Hill 2 vertically (vertical size is 2 times smaller)

Revision 2062

w32pthreads: Fixed some minor bugs in the pthread_testcancel optimization I
implemented some weeks ago; ifdef'd out some code that was specific to
__CLEANUP_C mode.
Jake.Stine
No changes to the API, so DLL version wasn't changed.

Revision 2063

Reorganized the exception/signal handlers, setjmp/longjmp, and SysCoreThread
stuff:
* Exception/Signal handling now uses an EventSource, so that multiple handlers
can be registered. This is in preparation for (eventual) more complete MIPS TLB
support in the VTLB memory model.
* Improved code isolation, so that recompiler-specific code is primarily in
iR5900-32.cpp (cleans up Counters.cpp and SysCoreThread.cpp)

Revision 2064

Fix the usual myriad of Linux compilation errors.
Zeydl...
I am deeply sorry, but for me you don't fix every compilation error: from r2062 (that was buildable) I have following errors:
Compiling: ../gui/MainFrame.cpp
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp: In constructor ‘MainEmuFrame::MainEmuFrame(wxWindow*, const wxString&)’:
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:315: error: invalid conversion from ‘void (*)(void*, wxCommandEvent&)’ to ‘void (*)(void*, wxCommandEvent&)’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:315: error: initializing argument 2 of ‘EventListener<EvtType>::EventListener(void*, void (*)(void*, EvtType&)) [with EvtType = wxCommandEvent]’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:316: error: invalid conversion from ‘void (*)(void*, wxCommandEvent&)’ to ‘void (*)(void*, wxCommandEvent&)’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:316: error: initializing argument 2 of ‘EventListener<EvtType>::EventListener(void*, void (*)(void*, EvtType&)) [with EvtType = wxCommandEvent]’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:317: error: invalid conversion from ‘void (*)(void*, int&)’ to ‘void (*)(void*, int&)’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:317: error: initializing argument 2 of ‘EventListener<EvtType>::EventListener(void*, void (*)(void*, EvtType&)) [with EvtType = int]’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:318: error: invalid conversion from ‘void (*)(void*, IniInterface&)’ to ‘void (*)(void*, IniInterface&)’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:318: error: initializing argument 2 of ‘EventListener<EvtType>::EventListener(void*, void (*)(void*, EvtType&)) [with EvtType = IniInterface]’
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp: In member function ‘void MainEmuFrame::ApplyCoreStatus()’:
/home/ruslan/pcsx2-new/pcsx2/gui/MainFrame.cpp:520: warning: unused variable ‘valstate’
Process terminated with status 1 (2 minutes, 27 seconds)
8 errors, 7 warnings
Jake.Stine
invalid conversion from:
‘void (*)(void*, wxCommandEvent&)’ to
‘void (*)(void*, wxCommandEvent&)’
.. I just needed to print those out lined up so I could be certain they were in fact identical. Sigh. What the hell does GCC want me to do now? Drain a goat of blood?
david.jennes
Dunno if I've mentioned this before but Jake, have you thought about using llvm-gcc as a compiler? It's getting quite mature (it's available as a compiler on mac along with gcc) and gives way better error messages than gcc, so it could be preferable in cases like these :-D The only thing I'm not sure about is if it's able to compile pcsx2, since you guys sometimes use some voodoo c++ :-P
Oh and if you ever give llvm a try (and it works), make sure to also run the clang static analyzer which finds errors in your code (leaks, uninitialized vars, etc...)

Revision 2065

Attempted fix for GCC compilation errors in previous revision. Also:
* Removed some unused sealed class container mess that liked to cause
compilation errors on GCC 4.2
* Added a macro for efficient invocation of static recompiled code buffers.
Jake.Stine
Random shot int he dark here. Sometimes using "typename" fixes ambiguous type mismatch errors in GCC. Let's hope for the best.
arcum42
Don't really have time to troubleshoot it right now, but I was able to replicate the issue on this revision.
It only happens if I switch over to gcc 4.3.3, though. It compiles fine on gcc 4.4.1.
Jake.Stine
Yeah I don't have 4.3 handy to test with at the moment. It seems like it's a likely compiler bug tho. I hate coding work-arounds for compiler bugs. >_<
Jake.Stine
@arcum42:
Anyway, you can try removing __fastcall from the typedef in EventSource.h (And all dependent functions). I assume that's the cause of it. If so we'll ned to make a macro and ifdef it for GCC 4.3.

Revision 2066

GSdx: Some fixes.

Revision 2067

Emitter rewrite, part 1 of 5 (or so...): Re-tooled SSE arithmetic instructions
to be class/template free.
Jake.Stine
When all said and done, emitter will generate much more efficient code, and should allow PCSX2 to compile/link significantly faster.
Jake.Stine
To explain why: C++ Standard actually *prohibits* compilers from optimizing const class initializers, which is why I had to do mad templating in the original emitter to get it to generate half-decent code. I decided to undo the whole mess, use a little extra copy/pastes and macros, and use C-style array initializers instead. This produces much more efficient end-result code.

Revision 2068

SPU2-X: Added SVN revision info to the SPU2-X name reported back to PCSX2, so
that it shows up in the plugin lists. (previously only did so in dev/debug
builds, now does it for release too).

Revision 2069

Emitter rewrite, Part 2 of 5: Converted SSE comparisons and SSE conversions to
constructor-less structs.
(also includes some header file prepwork for my next wxWidgets windows.h commit
fix)
mahmoudk...
jake ....u r a legend
i love you man

Revision 2070

wxWidgets/win32: Removed another sneaky inclusion of Windows.h into wx's global
namespace.

Revision 2071

Attempt for the GCC 4.3 compilation errors introduced in r2063/2064, by
selectively disabling __fastcall for the functions being used as listeners...
hope it works. >_<
arcum42
Looks like it compiles just fine on 4.3 now.
Reason why I have 4.3 installed is because gcc 4.4 just recently got unmasked, so when I set up my chroot, it came with 4.3, and gentoo slots major releases of gcc, so I would have had to explicitly remove it if I wanted to get rid of it.
Oh, and you might look at line 205 or so of Pcsx2Defs.h. We already have a GCC_VERSION define set up there that might be useful, from when 4.4 came out and I was having issues. We should be able to do something like:
#if defined( __GNUC__ ) && (( GCC_VERSION >= 40300) && ( GCC_VERSION < 40400 ))
Oh, and shouldn't one of the:
# define __evt_fastcall
's be:
# define __evt_fastcall _fastcall
?
Jake.Stine
oh woops. I removed it to test and make sure it compiled error free in both modes. Forgot to undo it before committing :p

Revision 2072

Implemented Aligned Stack for microVU and superVU (mVUs is currently ifdef'd for
GCC only, since implementing aligned stack for other compilers that don't
automatically assume it requires some complexity and overhead).
Jake.Stine
Oh I'm an idiot. I forgot sVU is an external asm file. Fixing :p
heatbla...
:) Good svn! I`ve tested it with many games. BTW why does patch enabler tick does not save when exiting? Patches are not working btw. I have a patch for skipping the AKsystems logo in GGXXA.CORE but it does not work in the new guix.
Steambot chronicles still crashes emu :...( and Eternal Poison is still black-screen.

Revision 2073

Aligned Stack for sVU in linux/gcc (missed the .S file in the last commit).

Revision 2074

Fix the trunk for gcc 4.4 (haven't looked at 4.3 yet), and add a few log changes
I hadn't committed yet.
arcum42
Checked, and 4.3 is fine.
maurizio...
some error on the last svn on the VifDma.cpp commit
VifDma.cpp
..\..\VifDma.cpp(181) : error C3861: 'VIFUNPACK_LOG': identifier not found
..\..\VifDma.cpp(169) : see reference to function template instantiation 'void ProcessMemSkip<0>(u32,u32)' being compiled
..\..\VifDma.cpp(185) : error C3861: 'VIFUNPACK_LOG': identifier not found
..\..\VifDma.cpp(189) : error C3861: 'VIFUNPACK_LOG': identifier not found
..\..\VifDma.cpp(193) : error C3861: 'VIFUNPACK_LOG': identifier not found
..\..\VifDma.cpp(197) : error C3861: 'VIFUNPACK_LOG': identifier not found
arcum42
Oh, right. I see what the issue was. It only would have broken release mode, and I was compiling in debug mode.
If you add the line
#define VIFUNPACK_LOG 0&&
somewhere between lines 183 and 221 in Debug.h, it should compile. Once the big compilation job I've got going finishes, I'll commit a fix.

Revision 2075

Blind commit. Should fix my last commit.
arcum42
And the system update I was doing broke my copy of my chroot, so I have to fix that before doing any more commits...
arcum42
Namely, I was updating X11 and my nvidia drivers, and that can be picky about the ones in the chroot matching the ones outside of it.

Revision 2076

Account for GIFtag register 0xEE, which is (un)used by .hack//Infection [removes
console spam].
jfre1...
Yay. .hack infection loving always welcome.
heatbla...
Will not freeze with SPUX plugin? No need to use Pete`s anymore? It that appears, the fix will be good for Wild Arms 5

Revision 2077

Replace assert() with pxAssert() in pcsx2 core and recompilers.
Rationale: assert() is not thread safe on win32 (the modal popup can block user
input or hang the program), and is neigh useless on Linux (just does a
DebugBreak/Trap). Furthermore, pxAssert() registers stack traces and supports
more detailed textual descriptions. I considered just #undef/#define on the
assert macro, but MSVC's assert.h also does #undef/#define so it'd be too prone
to accidentally calling MSVC's problematic version if some nested header
included <assert.h> (which many do).
Erik.O...
Great work but I found one mistake:
memsize is not declared in Release-Builds but it is used in various pxAssert (VifDma.cpp)

Revision 2078

Fix Dev/Release mode compilation errors from prev rev.

Revision 2079

Small bugfixes to settings handling at startup, fixed a memleak when opening
multiple dialog boxes, and some other minor interface code cleanups.

Revision 2080

Fix some 'o dat Linux thang!
Jake.Stine
Ironically arcum's blind commit earlier today worked in msvc (where _fastcall is valid), but didn't work in Linux (undefined). And then I added a heap 'o breakages of my own on top. :p
arcum42
Oh well, that's why I explicitly said it was a blind commit. That was the point that I realized it would be a while before I had my chroot working properly again, so I knew I wouldn't be able to test it.
It's my own fault, really. I decided to finally iron out some issues in X11 that I'd previously solved by rolling back a version, and get it working properly so I can stay current.
I did, and it works beautifully; and everything that uses opengl is broken now in my chroot. I even managed to break a few things that don't, like codeblocks.
So it'll likely be a few days before I commit anything. It's what I get for staying on the bleeding edge most of the time...

Revision 2081

SPU2-X: (experimental) New reverb implementation using a more correct
downsampler, as borrowed from "sexypsf."

Revision 2082

LilyPad: Bugfixed cause of occasional hangs and lost input. Also, I've
implemented an experimental fix for Issue 458 (laggy/sticky controls every 10-20
seconds).
Wagnar...
Issue 458 seem Fixed to me:)

Revision 2083

* PCSX2 paths save to ini correctly now (sometimes they'd save as blanks).
* Added some comments for the Dialogs::ExtensibleConfirmation class.
* Removed a redundant call to PADupdate in the MTGS (not needed anymore in the
single-PAD plugin design added in pcsx2wx)

Revision 2084

SPU2-X: Slightly better algo for the new reverb. :)
ramapcsx2
This runs slightly faster on xenosaga 2's sampled music.
Good job. :)
ramapcsx2
Oh, except it disabled reverb / made it inaudible :p
ramapcsx2
Ok, wasn't this rev but 2081 already.
maurizio...
something wrong for me
Linking...
Creating library C:\Development\Project Source\PCSX2\\bin\plugins\SPU2-X.lib and object C:\Development\Project Source\PCSX2\\bin\plugins\SPU2-X.exp
Generating code
c:\Development\Project Source\PCSX2\plugins\spu2-x\src\ConvertUTF.cpp : fatal error C1382: the PCH file 'c:\development\project source\pcsx2\plugins\spu2-x\src\windows\win32\release\spu2-x.pch' has been rebuilt since 'c:\Development\Project Source\PCSX2\plugins\spu2-x\src\Windows\Win32\Release\ConvertUTF.obj' was generated. Please rebuild this object
LINK : fatal error LNK1257: code generation failed
Build log was saved at "file://c:\Development\Project Source\PCSX2\plugins\spu2-x\src\Windows\Win32\Release\BuildLog.htm"
SPU2-X - 2 error(s), 0 warning(s)
maurizio...
a clean rebuild solve the issue

Revision 2085

GSdx:
- More work on the configuration, preparing for some reorganization.
- 8 Bit textures default to off again, since there are issue reports (mainly
from ATI users).
- Add a gamefix that allows users to set an amount of "bad" frames to be
skipped.
Add gamefix_skipdraw = x to the GSdx.ini to enable. (More work on this soon)
ramapcsx2
FFX fans:
Set gamefix_skipdraw = 1 to get rid of the blur in battles ;)
zantezuken
If it is what I thought, skip value 3 should fix some GoW2 NTSC issues :P
1/3 for Radiata Stories
2/4 for GoW2 PAL
ramapcsx2
This gamefix skips drawing single textures based on a analysis if they're problematic.
A game scene might consist of some 10000 draws or so (if it's simple :p ).
Out of these 10k draw calls, it may find a fog or depth texture.
At that point it will skip drawing the next x textures.
Sometimes x is just one, sometimes it's a series of textures. Hence the variable number to skip.
eliotfur
Hmmm... Can we hope for something good in the future?..
Rama, will you be the main GSDX coder now, since Gabest has gone to the real life?..
ramapcsx2
I'll keep working on it, yeah. But it's Gabest's project.. :p
keb...
awesome fix
wow, is gabest really gone or just taking a break?
sorry for the offtopic
powerzx78
Something is bothering me:
1)why some games like GOW(ntsc and pal english) hangs at different fmv's?
2)are there any ideas how to fix problem with fmv's in GOW 1 and 2?
jadjkor...
thnx men, earlier revs of gsdx worked beautiful on my ATI
hope these fix makes them work like this again!
please see these screenshots of GOW 2 at 1600 x1600 internal res.
http://i546.photobucket.com/albums/hh438/jadjkorn64/GSDX1332mSSE2AMD64DX101600_16005.jpg
http://i546.photobucket.com/albums/hh438/jadjkorn64/GSDX1332mSSE2AMD64DX101600_1600.jpg
http://i546.photobucket.com/albums/hh438/jadjkorn64/GSDX1332mSSE2AMD64DX101600_16003.jpg
thanks a lot.
jadjkor...
My specs.
ATI HD 3850 ddr3 512mb ram dx10.1 ps 4.1
AMD athlon 64 x2 6400+ black edition OC 3.33ghz
4GB ram ddr2 800 4-4-4-12 dual channel
windows seven x64 7600
video plugin gsdx sse2 1495
cdvdolio 0.1.
pcsx2gu...
This is NOT the place to ask for support. Visit the forums to get help and do not spam the googlecode comments.
jfre1...
Any big changes on the way for gsdx out of curiosity? ie further fixes to sps issues in games? Ghost Hunter and Arc the Lad have been suffering badly from those for a long time now.
zantezuken
Sps issues isn't gsdx thingie.
jfre1...
Majority of the time anyway
zantezuken
Hm, noticed weird slowness in SO3 battles: FPS drops significally when executing special move or any other special effect animation appears on the screen.
Used skipdraw 3 (required value for SO3) and accurate scaling x3
Does not happens on GSdx r1058 (well, FPS still drops but not so much).
Tested on PCSX2 r1724.
Jake.Stine
>> Used skipdraw 3 (required value for SO3) and accurate scaling x3
This uses a rough equivalent to 3072x3072 internal resolution. Expect major slowdowns on certain GPU intensive scenes, even if you have a video card forged in the belly of Mt. Doom and enchanted by Elves.
ramapcsx2
Exactly :p
DaRKCo...
this really fix the FFX battle blur! thanks rama
zantezuken
>> This uses a rough equivalent to 3072x3072 internal resolution. Expect >> major slowdowns on certain GPU intensive scenes, even if you have a >> video card forged in the belly of Mt. Doom and enchanted by Elves.
Err.. why 3072x3072? I thought it x3's internal, native game resolution which is 640x448, so, more like 1920x1344?
Why it is 3072x3072? ;<
ramapcsx2
To account for the worst case, when games request render targets of 1024*1024.
However there seems to be even higher rt's (I have a homebrew .elf that uses 1920 * 1080), so we'll probably need some compromise.
Working on it.

Revision 2086

SPU2-X: More reverb work (mostly).
* Fixed some bugs from the prev rev that ended up disabling all reverb
completely.
* Expanded reverb buffers to x4, as per Neill Corlett's recommendation; this
should give reverb a lot more "body"
* Implemented what I suspect is correct behavior for EEA register handling.
When set to zero, effects are disabled. This fixes nasty reverb and feedback
loops in Digital Devil Saga.
* Reverb down/up mix buffers are now processed even when effects disabled;
fixes the reverb being cut off prematurely during the BIOS splash screen.
* Fixed some silly clamping bugs (should fix distortion problems in some
titles)
Jake.Stine
I ended up pasing in some regression testing code back into this revision, but I doubt it's needed anymore. I was beating myself up trying to avoid nasty reverb feedback loops in Digital Devil Saga and then while analyzing some buffer data it dawned on me what it's actually doing. :)
Hopefully my hunch is right. I put a console printf in; if a game uses EEA==0, SPU2-X notifies that it's disabling reverb. So if you come across a game that *wrongly* disables reverb and that's printing int he console, let me know.
chuuey
i'm having a lot of issues with sound in ffxii now, i could record a video but froma aside sound bleeps all over the place, now comes in the strange humming sound from both channels o.o
ramapcsx2
FF12 has feedback coming in very slowly. It gets out of hand though after around 10 seconds.
I can't test my favorite reverb game though, since savestates are broken now :/
zantezuken
Remember rama: savestates are dirty! Use clean MC save! :O
Jake.Stine
>> I can't test my favorite reverb game though, since savestates are broken now :/
Turn off spu2-x wavfile logging, that should fix savestates. There's a bug where it tries to write to logfile before the files have been opened. If that doesn't fix it, who knows.
Jake.Stine
Anyway issues are mostly because of the *4 buffer indexers, which frankly don't make any sense. All of the values written to the addresses are clearly direct index values and shouldn't have *4'd, but I figured I'd try Neill's suggestion anyway. It works well for the BIOS reverb, but I had a feeling that was lucky chance.
Jake.Stine
Oh never mind, I modified the SPU2-X state variables; that's why the savestate broke. I forgot to update the version number. I fix.

Revision 2087

LilyPad: Better fix for the stuck pad keys ( Issue 458 ). Fully re-implemented
the GS window message pump stuffs. :)
mattme...
Oh...Right...Problem was that I never set padReadKeyUpdated[3] (Which I use for the WMA_FORCE_UPDATE calls) to 1 after each pass, but I still check it at the start of the loop. Or at least that's what it looks like
Jake.Stine
Well you had a comment somewhere that says WMA_FORCE_UPDATE's stateUpdated value should "always be 0" ... which makes sense since messages are only posted if they stateUpdated for the respective device type has already timed out.

Revision 2088

LilyPad: Minor fix for redundant initialization of critical section.
Jake.Stine
man that lilypad thing was frustrating. I explicitly tested Rama's hack the other night repeatedy, and it didn't help, and I even tried commenting out several stateChecked var checks (I spent like 3-4 hrs troubleshooting before I decided to comment and commit). I can only imagine I was running thr wrong DLL or something, although I tried to make sure and double check the console periodically to make sure it was loading the right one.
And then last night all my similar tests yielded different results. >_<
Geh, oh well. I figured it out in the end.
heatbla...
Good rev. BTW do you know the bug in some games when you are unable to use diagonals? Note at Magna Carta and Full Metal Alchemist. There is down diagonals but no up diagonals....
mattme...
Jake: Yea, you did indeed. Been planning to get around to this, but I've been pretty much out of commission due to the flu for the last couple weeks.
heatblazer: Beats me. It might be how your controller or DirectInput handles diagonals as opposed to how PS2 controllers do. PS2 controllers obviously have no published specs on such things, making it hard to figure out what's going wrong. Of course, DirectInput isn't exactly fully specced out either. Could be a sensitivity issue, too. Just no clue.
heatbla...
I am using x360 controllers and Logitech Chillsteram both x11 input. I am having that problem for an year but forgot to report...
mattme...
Ahh... XInput. Even worse than DirectInput. Blame Microsoft.
heatbla...
I am blaming MS. That trouble does not bug me, just post it to know the issue. Hope to have been helpful.
mattme...
Problem is Microsoft's specs don't seem to explain the behavior of its analog sticks. As I don't have an XBox 360 controller, basically makes it impossible for me to fix.
Yes, someone could test extensively and give me the results, but no one has so far, and I'm too lazy to give instructions that have a 98% chance of being ignored, so...anyways... not going to be resolved in the foreseeable future.
heatbla...
Don`t bother. I am not that hard gaming. And besides, I have PS2 controller. I just want to make the repport :") Your Pressure and Lily are the best!
pcsx2gu...
The xbox360 diagonal problem is pretty much known. You can fix it by setting the sensitivity of the analog axis to about 1.375
heatbla...
@ pcsx2guide thanx for the info. I`ll try it ASAP
maurizio...
strange issue , but i need someone that confirm. Game is Front Mission 5 , i mapped L3 and R3 with the '1' and '2' key , the R3 work (rotate the image during the strategy view) but the L3 did not work. Could someone test it on other game ?

Revision 2089

SPU2-X: Revert Neill's x4 buffer indexers -- Fixes feedback. Update savestate
version to fix prev savestates.
Jake.Stine
Ok, I'm done with reverb for a while. :p
I made some notes in the source file for tweak points on reverb volume.

Revision 2090

The Digital Devil Saga reverb fix "fixed" too much. It's gone :p
Jake.Stine
Yeah that damn game. I have no idea what mystery register it's setting to disable reverb. It clearly has no reverb in the talking scenes on the PS2, but it sure has plenty in SPU2-X >_<
ramapcsx2
It fits the game, so it's cool :p
Jake.Stine
Well most of the game should have reverb, I'm pretty sure. It's just the realtime rendered FMV parts that have reverb when they shouldn't. It's just puzzling figuring out what it does on the PS2 to disable that we're not handling here. :/

Revision 2091

Revamped some console log stuff.
* Added more colors!
* VM's EE/IOP logs (the ones that come from the emulated games themselves) are
colored accordingly: EE are faint cyan, IOP are faint yellow. They're
intentionally "hard to read" because 99% of the time they're meaningless trivia
(but still cool since it's what the actual devs would have used for developing
the games!).
Dev Notes:
* Removed Console.Status (specify blue/green colors manually if you want them).
* Renamed Console.Notice to Console.Warning.
* I changed the overloads so that both char* and wxChar* versions work like
printf now (no need to use wxsFormat when working with unicode strings). I also
removed wxString& versions of the overloads. This should (I hope) also be an
easier port to wx2.9 or 3.0, when that time comes.
* Default log color is now black instead of gray; typically you'll want to
manually specify Color_Gray when doing high volume logging (like the EErec's
block tracking in debug builds).
Jake.Stine
This color design was what Cottonvibes and I came up with after some disccusion earlier this week. The alternative was using some kind of prefixing, but that was problematic because it would have either required a special custom-draw console with a left side column for labelling each line (as sourced from PCSX2, EE, or IOP), or would have caused problems/bugs with per-character or partial-line writes that some things do.

Revision 2092

Changed most instances of wxString::FromAscii to fromUTF8, which is generally
more correct (may fix Issue 460 , please confirm).
Rationale: FromAscii should only be used on old-style DOS/ANSI character strings
that use the upper 128 characters for drawing pictures or writing umlauts, which
is pretty much nothing at all as far as PCSX2 is concerned. Chances are even
the japanese console logs coming from the PS2 itself use UTF8.
dyorgio
I use ISO-8859-1 for my sources, is more compatible, I belive...
Jake.Stine
Ok, the console actually uses Shift-JIT.
We'll be adding a unicode conversion for it soon so, hopefully, the games that use japanese console output will render properly (if you have the japanese fonts installed).
It's a small thing, but it's fun :p

Revision 2093

Added Console and MenuItem interfaces to the new Plugin API design (work in
progress).
Zeydl...
What part of this new API should I support on ZZogl?
arcum42
I can only go on what I see in the trunk and what we've discussed in the past, since my chroot's still broken. However, all this should be optional, though nice to add in. If I'm reading it properly, this gives plugins the ability to do two things:
1) The ability to use the Console commands, Console.Write/WriteLn/Notice/Warning, instead of printf's and things like DEBUG_LOG defs. This'll definitely be the preferred way to log to the Console in plugins, and is something we've been talking about doing for a while.
2) The ability to add menu items and submenu items to pcsx2. For example, being able to change the AA settings from the Video menu in pcsx2, instead of having to use keyboard shortcuts or the configuration dialog.
Given the "Work in Progress" note, I don't know how much of that is usable right now, though I'm sure Jake'll be able to give you the status...
Jake.Stine
Nothing in the new API is usable, quite yet. I have a hardcoded (statically linked) memorycard plugin I'm using to test some of the code, but other than that it's still just design stuffs. No live use.
When it's ready it's going to mean some major changes for some plugins to work with it. But in the case of GS plugins it's mostly a matter of deleting or bypassing code. The GIF Transfers (GIFtag parsers) won't be needed anymore, nor any window creation/management stuff. The OSD stuff will be optional... and it shouldn't be much to add anyway since it's meant to be a single texture layered on top of the framebuffer.

Revision 2094

Adds proper Shift-JIS decoding to the PS2 console output (conversion tables
generated by gigaherz). If you have asian fonts installed, then Japanese
characters will be displayed correctly in the console. :) [good test games are
FFXII and Tales of the Abyss -- many others too probably but those are ones I
have]
Known bug: sometimes the font won't get reset back to default immediately after
japanese text is printed. Not sure yet best way to handle that.
ramapcsx2
Neat :p
jfre1...
Noob suggestion but have you tried a if condition check. For example: if(font!="default")
{
font = "default";
}
or something along those lines.

Revision 2095

Fix GSnull under Win32; plus minor fixes to the console logger.

Revision 2096

Fix some linux compilation errors in GSnull and PCSX2.

Revision 2097

Savestate fix.
Jake.Stine
@Arcum42: This revision btw might fix the ZeroGS savestate crashing bug in Linux. Give it a try when you get a chance and see what happens.
arcum42
Haven't had a chance to look at it yet, but I'll put a comment here when I have...
arcum42
It did, in fact, get rids of the ZeroGS savestate issue.
Saving does seem to be rather unstable and crashed several times on me, with several different errors, but this may be because I had to use the menu commands, since the function keys don't work in Linux currently.
However I was able to save and load a savestate a few times.

Revision 2098

GSnull: remove obsolete makefiles, add eol-style:native property.
Jake.Stine
I'll probably end up making the cmake files myself, I think. And then (Hopefully) someone else can help maintain them. Zedron showed interest but he didn't really know how to "get started" with the initial makefiles.
david.jennes
Do you mean a cmake file for the whole pcsx2 project? Would be handy, I tried getting the latest svn a few days ago on my Mac, and tried both the codeblocks project and making my own xcodeproject, but didn't get far at all with the compiling :-P
(Reason for this is that, since the aligned part has been merged into trunk, I might be able to get it working. Boy did I underestimate that task :-P Kudos to zedr0n to even get 0.9.6 working)
Jake.Stine
Also, aligned stack is only 50% of the problem. the other problem that hasn't been resolved yet in trunk is XMM register clobbering. GCC's 4.3.x optimizer uses occasional XMM registers, which causes occasional annoying odd behavior in games. GCC 4.4's uses XMMs constantly, and it totally screws up the recompilers in PCSX2 -- games can't even boot typically.
Fixing that part's going to be hard. Zedron's fix was to throw in a *lot* of register freeze/thaw code all over PCSX2. I'm hoping for something a little cleaner.

Revision 2099

GSdx: Cleanups to the vsync framelimiter linkage. Ensures that the vsync
settings are preserved across plugin shutdown/init, and removes a lot of
function parameter mess trying to pass a single parameter across some 6-8
classes and 4 nested function calls.

Revision 2100

Much work on menus, gui features. Partially-working recent-isos menu list.
Bugfix for some of the new console stuff that could have caused some funny bunny
business, or crashes, in a few games. Why dat wascaly wabbit! >_<
krazytru...
In other news, Jake is losing it from programming too much =P
arcum42
Hmm...
Something broke opening pcsx2 somewhere in here. And I have a half-working[1] chroot, and a Release mode only copy of pcsx2 to figure it out in...
Basically, it spews out a number of gtk+ errors on the console, and then just hangs with no gui. Works fine if I revert to 2099, though.
[1] Which is a good deal better then it was; I can open codeblocks, and even run glxgears. I just can't compile in Debug mode[2], and can't actually run zzogl/zerogs.
Before, codeblocks wasn't working, and neither was glxgears. (The latter indicating that opengl was totally hosed.).
[2] My chroot is now a different distribution then my main copy of Linux, and I realized after the fact that it didn't have a package for the debug version of wxGtk that worked. Though it has a working copy of 2.9...
arcum42
The Gtk errors are the following, btw
(general gist is, something didn't initialize properly, and then a invalid pointer fails to be a Gtk object a bunch of times):
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:7295): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:7295): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function
(process:7295): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(process:7295): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed
(process:7295): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed

Revision 2101

GSdx:
- Fixed many flickering scene change transitions (FF12, Gust games, etc).
- Found more info on how games do some special effects. Preliminary code
included, but disabled.
ramapcsx2
http://img5.imagebanana.com/view/m7ewx8tr/xs3.jpg
This took ages to figure out :p
crushtes...
The linked image doesnt load here.
andutrache
This fixed the flickering on battle start with Wild Arms 5 too.
Nice.
serban.a...
keep up with the good stuff.respect!
roxh...
Good!Thanks!!
Autor...
BTW this WIP fog/blur/DoF effects are they working someway if i uncoment them?
Kaoss...
tyvm for fixing the GUST flickering!
Up to now everything runs fine
eliotfur
Fog, blur and DoF in DX hardware mode?..
Good luck to you, rama... Respect...
heatbla...
I`ll test Clock Tower 3`s FMVs flickering ASAP!
necr...
Fixes the flicker problem in Mana Khemia 1
Line...
OMG !!! Finally GS progress is moving ! =) Thanks Rama !!! Will test anything anytime :)
lemuel2010
Good job!!

Revision 2102

Implemented ELF loading! :D
Renamed a bunch of functions/methods in the Threading namespace that have been
bugging me for a while. (MutexLock is renamed to Mutex, Lock() is renamed to
Aquire(), etc)
nokiaqdman
Great!

Revision 2103

I speal gewd. (Aquire -> Acquire)
ntcong.it
Wow, that's a lot, your english teacher must be proud ;)

Revision 2104

wxWidgets/Win32: Disable tablet/inkpad support. Causes crashes on Vista/Win7
systems with tablets connected, and not needed for what we use RichEdit for
(which is the read-only console).
Jake.Stine
This is actually an issue in Common Control libraries that ship with Vista/Win7, or with how CommCtrl32 interacts with the Win7/vista message pump. The wxWidgets guys filed a bug report with microsoft, and it's acknowledged and still pending a fix. >_<

Revision 2105

Minor fixes to ELF loading and suspend/resume stuff.

Revision 2106

legacy_gui/Linux: Fix a compilation error.

Revision 2107

legacy_gui/Linux: another compilation error fixed.

Revision 2108

GSnull: Update to GPLv3.

Revision 2109

Added some hourglass cursors for various things; renamed more Semaphore and
Mutex APIs (I'm too indecisive >_<)

Revision 2110

Preliminary addition of Advanced Options (roundmode/clamping). They don't do
anything yet -- implementation of functionality is pending on review of the
layout. :)

Revision 2111

GSdx: More work on the effects. Found out I need to handle depth stencils ><
rodiablo...
Sorry to ask you this here, rama... But is there any chance this effects commits affect Xenosaga perfomance for good?
rodiablo...
I mean, when you finish it. :P
ramapcsx2
I doubt it, I'm not looking for performance right now.
The accurate scaler for example runs slower than it has to.
rodiablo...
Ok. Thanks for the answer. And +1 for the effort. Good luck ^^
Autor...
rama, thanks for your work, please tell me is this code compiles at current state, i tried to uncoment and compile and i've got
only one error
.\GSTextureCache.cpp(730) : error C2084: function "GSTextureCache::Source *GSTextureCache::CreateSource(const GIFRegTEX0 &,const GIFRegTEXA &,GSTextureCache::Target *)" already has realization text
1> c:\users\zerox\desktop\pcsx2old\plugins\gsdx\GSTextureCache.h(118): watch 'CreateSource'
ramapcsx2
There's 2 copies of createsource(). If you uncomment one, you need to get rid of the other.
Autor...
Where should i get rid of it?
zantezuken
it's func before the new one
Autor...
Tried i think i do smth wrong
zantezuken
Don't bother with it. Code in GSRendererDX.h left unfinished so, it is not possible compile it "as is" anyway.
heatbla...
I am re-cnfirming the issue with Dark Cloud 2 / Dark Chronilces when you try to invent an item and it succeeds the emu crashes.

Revision 2112

Bind CPU Advanced Options; roundmode, clamp mode, DaZ/FtZ should all
save/load/apply correctly now. :)
dh...
hi jake, this code will not work. i have compiled and now pcsx2 will crash if i start a game. the only error that i become is the windows message with the report that's the sound plugin has a error. here is the message from windows:
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: pcsx2.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 4aedc5af
Fehlermodulname: SPU2-X.dll
Fehlermodulversion: 1.3.0.2100
Fehlermodulzeitstempel: 4aedc503
Ausnahmecode: c00002b4
Ausnahmeoffset: 000027f8
Betriebsystemversion: 6.1.7600.2.0.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
the sound plugin is not the problem, i have tested all plugins and the crash comes overall but only the spu2-x plugin give me this error post, with all other plugins pcsx2 freezes only.
kaboo...
have you checked if it's this revision?
I just compiled it all and threw it into an folder etc and pcsx2 crashes for me too on cd boot gs plugin window opens and pcsx2 freezes
I don't get this error message though (I too have a german OS)
also I'm too tired right now to chek if it's really this rev XD
Wagnar...
True.
If we do a Save or apply in the option, the emu will always crash instantly.
(gs window open but stay gray)
To kinda fix it, deleting the ini folder will do it.
Wagnar...
More info.
The problem is not related if I change something to the inis.
If I start the emu and its the pcsx2.ini was not created (a new install), it will work.
But closing the emu and reloading it make crash.
Summary, emu crash when launching a game if pcsx2.ini exist in the INI folder.
Jake.Stine
Fixing.

Revision 2113

Rewrote internal handling of SSE roundmodes and DAZ/FTZ (fixes major crash bugs
of the prev revision).
* Added SSE_MXCSR union/struct with bitfields and methods for doing common
actions.
* Converted all existing MXCSR code to use the new union.
* Added a __pagesize macro for use in conjunction with __pagealigned and
dynarec functions.
dh...
hmm... it's a bigger problem. now starts the emu not. if i delete the ini files brings the emu the config dialog and after this crashed the emu. i can't see the main window, emu is crashed directly at start...
dh...
i think the cpu detection is wrong or so, i have checked the log file and the point x86-32 Init: is not more present. the last entry is Savestate version: 0x8b410003 and then pcsx2 crashes.
Wagnar...
For me, still can't run a game. And this time compared to older revision, its worse, it wont start a game even if the pcsx2.ini is not present on the loading of the emulator.
Hope it helps.

Revision 2114

Fix Linux - __pagesize as a #define was bad mojo.

Revision 2115

Fixes for more crash bugs introduced in the prev revision; potential fix for
Linux/GTK errors.
Details:
* Intel's FXSAVE requires an aligned buffer (wasn't explicitly documented in
the programmer's guide).
* I moved the wxMenu() objects in the wxApp constructor to OnInit(), which
should be post-GTK initialization.
arcum42
That got rid of the gtk issues. Now the issues I have to deal with are entirely local.
Oh, and the rearrangement of the menus and the way the advanced settings are integrated looks pretty good, btw...
dh...
the emu runs a little more, it's a step by step story ;) the gui starts now a the emu play no games... i have the same problem from the svn 2111 and the same error post from windows. i have tested with spu2-x and then with spu2null, by spu2-x crashes the emu faster and windows say error in spu2-x.dll.
here the windows error post:
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: pcsx2.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 4aeeede6
Fehlermodulname: SPU2-X.dll
Fehlermodulversion: 1.3.0.2100
Fehlermodulzeitstempel: 4aee9216
Ausnahmecode: c00002b4
Ausnahmeoffset: 000027f8
Betriebsystemversion: 6.1.7600.2.0.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
with spu2null runs the emu a little bit more and windows post a stackhash error. here the post:
Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: pcsx2.exe
Anwendungsversion: 0.0.0.0
Anwendungszeitstempel: 4aeeede6
Fehlermodulname: StackHash_0a9e
Fehlermodulversion: 0.0.0.0
Fehlermodulzeitstempel: 00000000
Ausnahmecode: c00002b4
Ausnahmeoffset: 5f241c97
Betriebsystemversion: 6.1.7600.2.0.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 0a9e
Zusatzinformation 2: 0a9e372d3b4ad19135b953a78882e789
Zusatzinformation 3: 0a9e
Zusatzinformation 4: 0a9e372d3b4ad19135b953a78882e789
and now the logfile from the emu, first with spu2-x and last with spu2null (i can't find a option here to add any file to this post, so i copy/paste it here)
PCSX2 0.9.7.r2115 - compiled on Nov 2 2009
Savestate version: 0x8b410003
x86-32 Init:
CPU vendor name = GenuineIntel
FamilyID = 6
x86Family = Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
CPU speed = 3.199 ghz
Cores = 2 physical [2 logical]
x86PType = Standard OEM
x86Flags = bfebfbff 0008e3fd
x86EFlags = 20100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3.. SSE4.1
Initializing PS2 virtual machine...
Allocating memory for recompilers...
Loading plugins...
Binding GS : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\GSdx-SSE4.dll
Binding PAD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\LilyPad.dll
Binding SPU2 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\SPU2-X.dll
Binding CDVD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\CDVDiso.dll
Binding USB : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\USBnull.dll
Binding FW : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\FWnull.dll
Binding DEV9 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\DEV9null.dll
Plugins loaded successfully.
*****************************************
PCSX2 0.9.7.r2115 - compiled on Nov 2 2009
Savestate version: 0x8b410003
x86-32 Init:
CPU vendor name = GenuineIntel
FamilyID = 6
x86Family = Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz
CPU speed = 3.199 ghz
Cores = 2 physical [2 logical]
x86PType = Standard OEM
x86Flags = bfebfbff 0008e3fd
x86EFlags = 20100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3.. SSE4.1
Initializing PS2 virtual machine...
Allocating memory for recompilers...
Loading plugins...
Binding GS : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\GSnull.dll
Binding PAD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\LilyPad.dll
Binding SPU2 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\SPU2null.dll
Binding CDVD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\CDVDiso.dll
Binding USB : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\USBnull.dll
Binding FW : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\FWnull.dll
Binding DEV9 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\DEV9null.dll
Plugins loaded successfully.
Loading plugins...
Binding GS : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\GSdx-SSE4.dll
Binding PAD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\LilyPad.dll
Binding SPU2 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\SPU2null.dll
Binding CDVD : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\CDVDiso.dll
Binding USB : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\USBnull.dll
Binding FW : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\FWnull.dll
Binding DEV9 : E:\Downloads\Emus\PS2\PCSX2 R1675 + Maetel 4.5\plugins\DEV9null.dll
Plugins loaded successfully.
Initializing plugins...
Init GS
Windows 6.1.7600
NVIDIA GeForce 8800 GT (8.16.11.9107)
Init PAD
Init SPU2
Init CDVD
Init USB
Init FW
Init DEV9
Plugins initialized successfully.
Issuing EE/iR5900-32 Recompiler Reset
Bios Version 1.90
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
Opening plugins...
Opening GS
Opening PAD
Opening SPU2
Opening CDVD
detected blocksize = 2048
isoOpen: D:\PS2\Dark Chronicle.iso ok
offset = 0
blockofs = 24
blocksize = 2048
blocks = 2291296
type = 2
* CDVD Disk Open: DVD, Single layer or unknown:
* * Track 1: Data (Mode 1) (2291296 sectors)
Opening USB
Opening FW
Opening DEV9
Plugins opened successfully.
Issuing EE/iR5900-32 Recompiler Reset
# Initialize memory (rev:3.63, ctm:393Mhz, cpuclk:295Mhz detected)
# Total accessable memory size: 32 MB (B:2:8:0) (363:2:7c30)
# TLB spad=0 kernel=1:12 default=13:30 extended=31:38
# Initialize Start.
PAL Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 50.0 fps
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# Initialize Done.
EE DECI2 Manager version 0.06 Feb 6 2003 08:38:48
CPUID=2e20, BoardID=0, ROMGEN=2003-0623, 32M
# Restart Without Memory Clear.
NTSC Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
PAL Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 50.0 fps
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize Scratch Pad ...
# Restart Without Memory Clear Done.
# Restart Without Memory Clear.
NTSC Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
PAL Display Mode Initialized.
Framelimiter rate updated (UpdateVSyncRate): 50.0 fps
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize Scratch Pad ...
# Restart Without Memory Clear Done.
microVU1: Cached MicroPrograms = [001] [001]
microVU1: Branch VI-Delay (1) [0270]
microVU1: Branch VI-Delay (1) [0478]
Closing DEV9
Closing FW
Closing USB
Closing CDVD
Closing SPU2
Closing PAD
Closing GS

Revision 2116

More fixes to MXCSR code. (Warning: prev revisions may have corrupted your ini
files badly -- if you have startup/boot crashing problems, wipe it)
dh...
yea, now works ;) i can play! the only thats crashed the emu directly is EE/FPU Clamping Mode: Full. i have tested all other modes in various combinations and all works....
very cool jake ;)

Revision 2117

* More MXCSR fixes (roundmode / DaZ / FtZ).
* Fixed a bug in the Full-mode FPU recompiler.
* Added some better error handling to the BIOS Rom loader.

Revision 2118

Minor fix for the new Shift-JIS console encoding. For some reason FFX sends it
an invalid/reserved character. Ignoring invalid/reserved characters for now,
pending possible discovery of a better handling of them.

Revision 2119

Cleanups and Linux compilation fixes. :)

Revision 2120

SPU2-X: Minor fix for very rare cases of hang-on-suspend when using the XA2
driver.
chuuey
thanks jake, there's an issue i want to tell you about in ffxii again, i don't know if you've tested it? There's sound feedback of some sort when you start the game, like all the sounds give out some weird sounds and then it stops, happens again after you change zones, by the way this started to occur a while back can't exactly say which rev.
jfre1...
Always helpful
heatbla...
Thanx for the work. BTW is the issue with the PATCH enabler fixed? Strange enough but my patches are not working on the new WxGuis...
Jake.Stine
I'll look into SPU2-X in depth once I start working on converting it into the new plugin scheme, and adding custom menu options to the PCSX2 gui.
Patch code has been modified a bit to make it Unicode compliant, and hasn't been tested or debugged. Status is unknown. It's generally not something high on my priorities list since I rarely use patches. And I'd also like to turn the whole thing into a plugin interface anyway. Hrm.

Revision 2121

Cause the gui to remember if 'Enable Patches' is checked. (Still not used,
though.)
arcum42
I don't have things set up where running the emulator works yet, but I may as well work on the gui a bit.
And if you uncomment that line in Counters.cpp, patches might work. Or not. Can't tell till my local copy is unbroken...
Jake.Stine
If patches make it through the parser without error, then yea it's quite likely they do work.
arcum42
I figure they probably work, but I didn't really want to turn it on without testing it in the emulator. And I didn't really have time to reboot into Windows yet.
I'll probably have my Linux system back to some degree of normal soon, so I can test without rebooting. If it wasn't for work, it'd probably already be there...
jfre1...
Ok I uncommented the line and recompiled this revision and patches work fine (tested the skip intro movie patch with Ghost Hunter).
dh...
yes i can confirm, patches works. only i don't understand: in the *.pnach file (i have tested suikoden tactics pal) is the entry patch=0,EE,00374CB0,word,24020001 for skip videos and this works fine under the legacy-gui. now i must change the line to patch=1,EE,00374CB0,word,24020001 or the patch does nothing...
whatever! patches works and i can play suikoden tactics (game hangs by playing the first intro without patch) and now we need the patch browser ;)
arcum42
Just thought I'd mention that I've got my chroot back to full functionality now... :)
Now the time I was spending working on that can go to coding. As a bonus, I've set things up so I can boot into my chroot as a separate Linux installation in Grub if I feel like it.
Not really related to this revision, but I just am glad to have it straightened out...

Revision 2122

Added drag&drop for the main window (supports isos and ELFs -- isos are
automatically added to the Recent Iso menu), and fixed some minor bugs in
managing/updating the recent iso menu.
dh...
nice idea a the function accepts all types of files and include the given wrong types to the iso rescent list... a check for valid types are nedded ;)

Revision 2123

Recompiler Bugfix: for crashes in Ace Combat 4, and likely other games that use
COP2 extensively.
Explanation: EBP was being used by mVU macro-mode (COP2), which violated the new
EErec aligned stack setup. ie, register/stack corruption resulted.
tatsuy...
Fixed the Ace Combat 4 crash and it also runs slightly faster nice job! Colors are inverted at intro but thats probably GsDX based (maybe?).
lemuel2010
Finally.

Revision 2124

ToAscii() -> ToUFT8() [missed a few last time]

Revision 2125

Enable patches, and fix Linux compilation.
arcum42
Since there were a few reports that it is working, I figured I'd go ahead and turn it on now, rather then waiting.
And it's amazing the difference \ vs. / can make.
heatbla...
Thanx a lot! I`ll test them asap! Very well done!
heatbla...
Now that`s another + from me!
arcum42
np.
I figured it'd work, since I didn't think much had changed in the patch code, and hooking it in wasn't exactly difficult. As with all things, you may see patch support break and unbreak a few times as we work on it, though...
heatbla...
Now Bakugan Battle Brawlers is playable via a video-skipping patch :) Cheers again!

Revision 2126

Fix for Issue 338  : Removed some HwRead spam that's generally not needed these
days, as it's wrong way more often than it is helpful.
Details: Most hardware registers are supposed to be read from the hwRegs memory
cache anyway, unknown or not..

Revision 2127

Fix BIOS Selector bug: BIOS list wasn't cleared when changing search folder.
heatbla...
Haven`t noticed that but good job!

Revision 2128

Misc bugfixes to plugin management and error handling.

Revision 2129

GSdx: Few more CRC's.
heatbla...
Good improvements, but Dark Chronicle/Dark Cloud 2 still crashes on item invention option :)
Autor...
heatblazer i don't think that your bug could be fixed with scuh commit
it's just adding CRCs nothing about Dark Chronicle/Dark Cloud 2
heatbla...
I know. I am just reporting.
ramapcsx2
Yes, we heard you the last 20 times you reported it. Stop that!
david.jennes
Do we have ourselves a new ferrarinews? :-P
necr...
Careful 'heatblazer', you may guarantee that no one will fix that bug...
heatbla...
OK, sorry, I will stop. :")
kimoki...
Hello rama, this is KiNGKiMO aka KOC2000.
I'm not sure if this is the right place to report this, excuse me please if not.
Long long time ago, gabest added the CRC of "Crash Bandicoot the Wrath of Cortex" to remove the fog from that game because it was very buggy, but now this might been fixed, can you please disable that fix so I can test it.. or tell me how to do so.. Thank you so much.
kimoki...
Well, I commented the line "{0x09F49E37, CrashBandicootWoC, Unknown, 0},"
Fog isn't visible yet, but the upper half of the screen now looks sharper, with the line uncommented the upper half seems a bit blurry plus all objects in that half gets duplicated.
lemuel2010
Improvements GS plugin very nice.

Revision 2130

GSdx: Remove a hack I put in when I introduced GSopen2 -- it's obsolete since
adding Device deletion to GSclose (and was causing some bugs on the F9 render
switcher).
nahuel36gg
i dont know, but when i press F9 the game (FFX) get more faster. Since this commit, when i press F9 that dont happens, and the program ends suddenly.
nahuel36gg
my mistake, this happens but with the ICC gsdx plugin. With the gsdx classic works fine.

Revision 2131

GSdx: Deleted a little too much in the last rev. >_<

Revision 2132

LilyPad: Fix for occasional loss of input when suspending/resuming emulation.
kimoki...
Thank you.. I was about to report that one.
mattme...
Oops. Looks like I really should have tested more with the wx gui before that threading commit.

Revision 2133

Fix a few stability issues with on-the-fly plugin re-configuration and the F9
RenderSwitch. (all plugin settings should be changeable without having to reset
emulation or anything now)
Zeydl...
By the way, is it possible to send GS_SaveStateChange when player press F1? Right now this function call only when user change number of saveslot.
lemuel2010
Great!!!.Issues eliminate.

Revision 2134

Console logging performance tweaks, disable the unused GIFtag register log (it's
been tested enough and documented), and add extra calls to GSchangeSaveState
(affects zerogs/zzogl only).

Revision 2135

Emitter Rewrite, Part 3 of 5: Finished all SIMD instructions, except those
embedded into base instruction groups (CMPSS/SD, DIVSS/SD, etc).
Jake.Stine
Shaved another 10-20 seconds off the link stage of PCSX2 compilation.
Before I started this emitter retooling, PCSX2's link stage used ~440megs and took 2:39. After this commit it's down to 310megs and 1:41.
arcum42
In simd.cpp, xSHUF is declared a constant without assigning it anything. Which is the sort of thing that makes gcc unhappy...
heatbla...
OK, I`ll report something that you may have not saw. If you set EE RECS to NEAREST, the game Rogue Galaxy changes. The players begin to flicker and move in random directions. Hope to see that reported from other ppl.
Jake.Stine
Ok, I'll report that we have an ISSUE dedicated to Rouge Galaxy, and that I'm copying your text and putting it there, so that it'll actually have some slim chance of being found by other devs, testers, and users after this revision is scrolled off the front page in a day or two.
(however I make no claim as to the actual value of the statement -- roundmodes other than Chop cause erratic behavior in lots of games, so I'm not sure what we're supposed to gleen from that)
heatbla...
@ Jake.Stine, thanks. I`ve been thinking of reorting that in the forums, but since it`s not a bug, and if you play at defaults the game is just fine, I changed my mind and decided to report it just for info or some clues. Hope to find it useful.

Revision 2136

Misc changes to Patches.cpp. Unconst xSHUF for the moment, so Linux compiles.
Jake.Stine
Oh, it probably needs one of those pointless empty constructors that GCC insists on for some inexplicable reason when a struct or class has no actual members.
arcum42
Er, Patch.cpp, that is.
arcum42
Probably. Didn't recall offhand, so I just commented out const.
I was mainly going through trying to get an idea of what pcsx2 calls in Patch.cpp, and what it calls from the rest of the program, and trying to isolate it a bit from the rest of the code.
Looks like ApplyPatch and inifile_read are the only things called from it, and it needs access to memWritexx, memReadxx, iopMemWritexx, IopMemReadxx, and to be able to set roundmode.
Jake.Stine
Yeah that about sums it up, although a more advanced patch interface with more patching/cheating ability might could use a little more access than just EE/IOP ram.
I'm hardly an expert on cheat application though, so I dunno what all a cheat system could benefit from. Might be something worth starting a new thread about in the public developer forum at pcsx2.net. Maybe some other users will have additional input.
arcum42
Probably a good idea. I could see them wanting access to all the various game fixes, speed hacks, and everything in the ee/iop & vu sections of the configuration dialog, really.
Whether we want them to have access to all of that, is another question...
arcum42
Oh, being able to read and write memcards from the plugin is another one I could see, because it would let them alter values in the saved games to give, say, unlimited gold. (Or write random data over the memory cards and destroy all your saved games...)
Jake.Stine
Memcards should be exclusive to external editor material. Editing a memory card while the emulator is running is a really complicated and volatile method of editing savegames, when it can be done more effectively from a saved/backed up memory card in a separate app.
Cheats and patches are meant to be on-the-fly editing of the game's running state. Typically a cheat writes a value to memory on each vsync, and then the game will read that value as it processes the next frame's logic and video. Often games modify or correct data afterward, which is why patch type 1 values are re-written on every vsync.
Jake.Stine
The other consideration with more advanced cheat insertion points is that they could adversely affect performance. Applying a handful of cheats on each vsync is pretty minor. Trying to change speedhacks or game fixes (which typically require recompiler resets) would cause massive slowdown. :/
arcum42
If we do that, it should probably be a separate memory card plugin, anyways, and suspend emulation when it's running. But, yeah, you're right, it wouldn't be within the scope of the patch plugin.
arcum42
For game fixes and speedhacks, we clearly wouldn't want to have it be every vsync. Once at the start of emulation would probably be enough. They could probably be changed in the inifile_read function (which would likely be changing names.)
Jake.Stine
Eh, don't really think we want the patch plugin to also be a full fledged game-specific configuration system either. With the wxWidgets ini file tools and how I set things up internally, it's pretty trivial to just load custom INIs directly into the EmuConfig. No need for any special external patch API for it.
Jake.Stine
So I was thinking about it, and what [i]could[/i] be introduced, and which [i]is[/i] true to the spirit of patches, are EE/IOP code execution traps. Two types offhand:
* Address Trap. Before the marked code address is executed, the patcher is invoked.
* Instruction Trap. Patcher is invoked for every execution of a specific instruction mask.
Both of them can be implemented into the recompiler in such a way that unpatched emulation would be exactly the same speed as now. Patches using address traps would also be pretty fast in general, unless the patcher traps an address that's run *alot*. Instruction traps would be much slower, and admittedly they're probably not useful for cheats -- but an instruction trap *could* be very useful for debugging. :)
Jake.Stine
And for [i]some[/i] reason, using BBcode doesn't work when posting to Googlecode. :p
arcum42
It's googlecode. What can you say?
And address traps and instruction traps would be very useful. And they are both things we'd want to add to the debugger as well, so it saves some coding later.
And all we really would need to do with the speedhacks/gamefixes is make sure the plugin has access to EmuConfig. It's something I recall I'd thought about before for the information about where the ini files are located.

Revision 2137

A few more changes to the patch code.
arcum42
Now the two functions exposed are InitPatch and ApplyPatch, and ApplyPatch(0) is called in InitPatch. Simplifies things a little.

Revision 2138

More patch stuff. inifile_read gets passed a wxString now.

Revision 2139

Convert the patches code over to use wxStrings.
arcum42
This involved redoing a bunch of functions in Patch.cpp . While my tests worked, it's quite possible some patches may have broken in their revision.
PatchFunc::patch itself can probably be coded better, but I'm not really that familiar with how the SafeList class works, so I just modeled it after how the old code was doing it...

Revision 2140

GSdx:
- Bring back IncAge() for textures to avoid excessive memory usage by some
games.
tatsuy...
Textures in the intro and ingame of Ace Combat 4 are still inverted using either DX 9 or 10 HW or SW mode, the water color and parts of the land is inverted and ahead is all black about midway and up on screen. Iam thinking its emulator based because I can uses the same r2140 GsDX with legacy GUI and those issues are not present. This has happened since r2123 when AC 4's crash was fixed.
Jake.Stine
This could be a microVU clamping issue.
Does r1736 and r1888 behave the same? Check both. r1736 used microVU for the COP0, r1888 uses superVU. So r1736 may have the same issue as 0.9.7, and if it does then we (kinda) know why.
tatsuy...
r1736 and r1888 both behave the same and do not have the inverted colors or midway black screen. Used GsDX r2140 SSE4.1 and default emulator settings for r1736, r1888 and r2140.

Revision 2141

Quick fix for TOTA crashing/freezing at startup; caused by a sign extension bug
in the new Shift-JIS -> Unicode text converter.
diego...
Great man,you are fixing issues like a mad XD,anyway,any news about my problem with dragon ball budokai tenkaichi 3 ?,i think that my crc code is the problem,you should add it thanks,CRC 740101a3

Revision 2142

Emitter rewrite, part 4 of 5: De-templificated all x86 base integer operations.
krazytru...
+1 for the code change, +10 for the new word. "De-templificated" XD
ivicamar...
Is there going to be part 5? It was long time ago, but i remember that these commits were good.

Revision 2143

Linux: Compilation fixes / project file updates.

Revision 2144

Wee bit 'o cleanup to patch file checking.
Jake.Stine
the console colors are kinda picked arbitrarily. Other than the use of the faint colors for EE/IOP sourced logs and strong colors for errors/warnings and such, I just kinda pick things on whatever feels right at the time. :p
In this case, since the "no patch found" message is very minor and should be ignored, I grayed it, and since it's often useful to see when a patch *is* being applied, I made it a more visible green.
arcum42
Makes sense to me. You're going to be seeing the "No patch found" message a lot more then the one about a patch, so the latter should stand out.
I hadn't realized that wxwidgets had a command to test if the file system is case sensitive or not, though. That's nice.
Hmmm... Just noticed that "f1.Close()" was removed. Shouldn't we close the file after we're done with it?
Jake.Stine
It's a C++ object. It executes the destructor when the current scope of the object is left, and the destructor automatically closes the file. :)
arcum42
Ah. That makes sense. Didn't realize that it took care of that for us.
And my cleanup of Patch.cpp to use wxString was mainly inspired by seeing that comment by your new trim function about how it couldn't be integrated in until the rest of Patch.cpp was using wxStrings, btw.
Of course one section really should have used SplitString. I just wasn't really clear on how to refer to the individual pieces of the string afterwords...
Jake.Stine
Eh, your method was probably better for this anyway, since it more effectively allows for l-values to have '=' in them. I'm just used to using SplitString because of my PHP coding days, where I split strings a half dozen times a day.
But yea SplitString in a simple sense is usually like this:
wxArrayString parts;
SplitString( parts, "=" );
// parts[0] is the r-value, parts[1] is the l-value
But if you have multiple '=', you'd get multiple parts, so it's really not the most ideal way to parse an ini file. A game title should be allowed to have '=' for example.
So your approach is better.
wxWidgets also has a wxStringTokenizer as a replacement for strtok, though I typically prefer just splitting into a flat array and accessing it that way. The resulting code is usually a bit more straightfoward.
Jake.Stine
Also, the automatic cleanup-on-exit design of objects is most important in exception handling. When throwing an exception, C++ cleans up all objects on the stack. So any open file handles get closed, allocated wxStrings get free'd, etc. And no need to explicitly handle errors and close out those resources by hand. Saves a lot of red tape coding, typically.
arcum42
Interesting. I'm used to splitting strings in Ruby, too. The main trouble I was having was not being that familiar with how your ScopedList class works. I *thought* I could use parts[0], [1], etc..., but was running into issues.
I see your point about multiple '=', though, so I'll keep it with the current approach, though I may clean it up a bit.
And you can probably tell I got rather irritated with the functions for converting wxStrings to numbers at one point. Though I suppose I should have used ToULong instead of ToLong, looking at it...
arcum42
Right, I was just thinking of fopen and fclose, and it didn't occur to me.
Of course, I should have thought of it because of one of the ways you can deal with files in Ruby. There are several ways to do it[1], of course, but the one that sticks in my mind is:
File.open("foo.txt", "r") do |f1|
while (line = f1.gets)
puts "#{line}"
end
end
The neat thing there is that you are passing a code block to the open method, and it opens the file, runs your code block, then closes it for you.
I've actually wished for something similar in C++ before. Particularly when dealing with the Freeze/Thaw XMM/MMX code...
[1] There are always several ways to do something in Ruby.
Jake.Stine
Yeah you can do scoped Freeze/Thaw code in C++ using objects. Although Ref's use of it in VIF is generally very scattered and evil, so it wouldn't really apply too well there.
And honestly we need to nuke the whole freeze/thaw design anyway so don't get too eager to rewrite it again. I don't think the modern GCC 4.4 optimizer is *ever* going to work right with the current system. Instead I'm going to have to enforce complete XMM register flushes at most C/C++ function calls from the recompiler.
Jake.Stine
Actually maybe I have a better idea, using some VTLB cleverness, to freeze/that registers only for certain HW register reads and writes, that access DMA memory (which, I'm pretty sure, is where the bulk of the problem lies).
The VIF's loading of XMMs in C code, some 20-40 lines prior to actually calling the VIF asm code, may also be a problem tho >_<
arcum42
Don't worry, I'm not really planning on doing a rewrite right now; the last one was sort of a spur of the moment thing.
And, yeah, I recall that code. Having "yay evil" in the comments by code sticks in the mind... :)

Revision 2145

Fix an unmapped character in the shift-JIS conversion table ( patch applied from
Issue 467 )

Revision 2146

Redid the structure packing macros a bit: added __packed, a bunch of comments,
and removed a few ugly #ifdefs.
arcum42
Looks like gcc doesn't like the aligned attribute being before struct. As of this revision, it's started giving warnings about how it's ignoring attributes.
If we switch it to "struct __aligned16 microRegInfo" and "struct __aligned16 microBlock" in microVU_IR.h, gcc is happy. Not sure about visual C++, though.
Jake.Stine
yup, that's fine.
Jake.Stine
Crap, I deleted some code I had only meant to move to a better location. Fixing. >_<

Revision 2147

Fix a few compiler warnings.

Revision 2148

Emitter code cleanups, and re-added GCC 4.4.x code I accidentally removed in a
prev rev.

Revision 2149

svnrev.h fixes for when TortoiseSVN isn't available (fixes compilation errors in
SPU2-X and cdvdGigaherz).

Revision 2150

GSdx: likely fix for the infamous DX10 memleak and resume/loadstate
instabilities. Likely because I don't have DX10 capabilities, so I'm coding
blindly as usual. ;)
Jake.Stine
I fail.
I definitely fixed at least 2 CComPtr leaks in this rev, but there must still be others. Man, honestly, I think I prefer the old days, when things are forcefully free'd and, if you have leaks, you get either neatly trackable CRTDBG blocks and/or neat crashes.
heatbla...
Interesting issue with Castlevania Curse of Darkness where there are some kind of glitches during the game... Notably on save points.
jfre1...
And thats as of this revision?
Jake.Stine
No, that's an ancient issue known to be fixed by using VU interpreters and stuff (which means it a VU clamping issue). But heatblazer does what he does. We mostly ignore it.

Revision 2151

Seems when I made the internal iso reader I changed some code that shouldn't
have been changed. This should make dual layer stuff work "as well" as in
cdvdiso.
kojikni...
Ahh thanks very much. Was wondering why I had to use the cdvd plugin when playing xenosaga.

Revision 2152

Replaced the old isofs code with a new simpler and cleaner isofs handler.

Revision 2153

This file wasn't necessary. Forgot to delete before committing.

Revision 2154

Get Linux working again.
gigaherz
Whoops. That's for relying on VAX's automatic #include thingy. :P
arcum42
Yeah, since Linux has a case sensitive filesystem, I end up having to fix includes a lot...
arcum42
And I just got to close a 7 minute old issue with this commit, too. ^_^

Revision 2155

Since pcsx2 itself can now identify the specific disk type based on the base
media type, cdvdGigaherz does not need to replicate the same work anymore.
This means cdvdGigaherz builds will no longer work on older versions of pcsx2
from before I integrated the detection code into the emu.

Revision 2156

* Added word wrapping to tooltips! (Windows only)
* Minor cleanups to iFPU roundmode recompilation.
* Changed AsciiFile from wxFile (slow!) to wxFFile (fast!)

Revision 2157

WIP work towards adding support for non-trivial image files (multitrack cue+bin,
ccd, nrg, ...).
This is only refactoring, there shouldn't be any behavior change.

Revision 2158

- Added microVU_Flags.inl to the project file (somewhere along the lines it went
missing)
- Fixed sVU COP2 to compile correctly (when disabling mVU Macro)
- Fixed minor mVU debug/logging bugs
- Made mVU0 exit execution every ~768 cycles which fixes Rachet and Clank
hanging (mVU0 already did this before when the m-bit was set, but now it does it
all the time even when the m-bit isn't set; other games might be effected by
this change...)
Autor...
Rachet and Clank 3 still hangs for me, did i do smth wrong?
azte...
congratulations cottonvibes, it's always good to see game fixes instead of seeing only fixes related to the emulator "itself" (this isnt a bashing against that ;) ).

Revision 2159

Change the console functions so that the terminal actually has colored text in
Linux. (And doesn't have blue underlined text for most of FFX...)
arcum42
I suspect Air will probably want to mess with this a bit, since the Console is mostly his code.
I added functions to the ConsoleWriter_Stdio function that change colors and change the console title in Linux, then added functions to the Console file writing code to pass the commands to the stdio code, since that's where it was passing along messages to the console already.
And I told it to clear all the current text settings before setting a color.
Net result: colors in the terminal, and when code that Final Fantasy X writes change the text color to blue and add underlines, it only lasts for a line, rather then the rest of the game.
I even had it change the title of your current console window. ^_^

Revision 2160

Minor fix for my last commit.
arcum42
It's best not to call nonexistent members of an array.
arcum42
I probably should reorder the array, anyways. The reason why it isn't in the same order as the enum is that I copied it from the legacy gui aqnd modified it.

Revision 2161

Avoid use of wxString in globals, unless really necessary (C++ global/static
object initializers on "complex" objects that do resource management can lead to
wonky inter-dependency nightmares, plus this more efficient anyways ;)
Jake.Stine
I've also gone on a bit of a crusade lately to undo a lot of the not-necessary brand of C++ initializers. There's no compelling reason to use C++ initializers for simple types (ints, etc), and compilers handle them more efficiently if they aren't in the initalizers. Complex types like objects and reference handles are another story though, and either should, or must, be handled via C++ initializers.
arcum42
Understandable. I'd forgotten about wxChar*, or I'd have used that instead, anyways. For that matter, if wxPrintf understood const char*, I would have left it as it was...
leomar....
Thanks by the great work!
I would like to do a request, it has some way to compile plugin with an option to edit the function gamefix_skipdraw=3 ?
maybe include inside the games fix?
OBS: Why the version legacy of the emulator runs so lighter, and correct than the normal version?
Jake.Stine
>> OBS: Why the version legacy of the emulator runs so lighter, and correct than the normal version?
BECAUSE THE 'normal' VERSION IS A WORK-IN-PROGRESS.
Sheesh. When it's stableish, and fasterish, we'll like, you know, post some downloads of it. There's a good reason we haven't been posting betas, and it's because it still sucks.
leomar....
Thanks by the answer.
sorry By the way that I talked, it is my poor English.

Revision 2162

Minor SVN Maintenence; added eol-style:native property to some files missing it.

Revision 2163

Patch parsing code cleanups, using some parser helper classes and properly
const-qualified wxString parameters; also improved error handling slightly.

Revision 2164

fixed a compile warning from mVU

Revision 2165

IsoFile/IsoFS code conformance stuffs:
* Converted new code to use PCSX2/wxWidgets types and utility/helpers.
* use u32 where appropriate (as defined by ISO 9660), and removed s64 stuff
since it's not supported by the file format anyway.
* general fixups to conform better to general C++ style error and object
handling.
zantezuken
Error 21 error LNK2001: unresolved external symbol "void __cdecl InitPatch(class wxString)" (?InitPatch@@YAXVwxString@@@Z) Elfheader.obj pcsx2
Error 22 fatal error LNK1120: 1 unresolved externals I:\Dev\Emu\PCSX2\bin\pcsx2.exe 1 pcsx2
=======
Not sure if it is current rev but anyway...
airmake...
Typo in line 10 in IsoFS.h
airmake...
Not sure if it's relevant here, but since you're working with the related files:
/home/maister/bin/pcsx2/pcsx2-read-only/pcsx2/CDVD/IsoFS/IsoFSCDVD.cpp|22|error: declaration of ‘virtual IsoFSCDVD::~IsoFSCDVD()’ throws different exceptions

Revision 2166

Better seeking for IsoFile; using s64 to allow for a full 4gb of addressable
file positions in either direction.

Revision 2167

Fix compilation errors.
arcum42
Skipping the bios seems to have broken at some point in the last few revisions. Don't have time to trace that back right now, though.
Jake.Stine
oops.
fnptr has a .data() method, that should be used on printfs.
Jake.Stine
Also, Skip bios works here. I wonder why it dies on linux.
Jake.Stine
Ok just tested, the crash must be game specific, I ran La Pucelle in Linux without errors; using Skip Bios.
what game?
arcum42
Doesn't seem to be happening now, so I'm not going to worry about it...
Jake.Stine
ahh probably some GCC dependency fail on recompilation/linking. It does that a lot for me if I like don't explicitly rebuild on every change. >_<
arcum42
Yeah, usually I do that fairly often, but I've only been awake for about an hour and a half. I work Sundays, though, and I'm probably not going to have much time after work today to code, so I figured that I'd beeter take care of it now.
Btw, any idea why the following code:
wxString temp = L"foo";
Console.WriteLn("temp = '%s'", temp.c_str());
prints:
temp = 'f'
?
Oh, and having to rebuild so often is new to the wx port. It'd happen occasionally before, but not nearly so often.
arcum42
beeter -> better
And I'm guessing that the rebuild issue is something related to the way codeblocks builds the project. That's what would make the most sense...
Jake.Stine
Console.WriteLn(L"temp = '%s'", temp.c_str());
^ Adding an L Will fix it.
Unfortunately we can't interchange UTF8 and UTF16 strings in Console writes. There's no way to improve the type safety to report the errors at compile time, and I haven't thought of a clever way to try and detect it at run-time either (not without re-coding an sprintf from scratch -- and the last attempt at that was buggy and not supporting many formatting options as it were.)
So yeah you just need to be careful -- when using wxString passed into WriteLn use L"", *or* you can also do this:
Console.WriteLn("temp = '%s'", temp.ToUTF8().data());
(depending, sometimes that's easier)
arcum42
All right. I was mainly wondering because I use WriteLn for debugging fairly often, and was running into that accidentally more and more.
If adding L or doing ToUTF8().data() will do it, though, I'll use that...
Jake.Stine
It's also possible to use the expanded '+ var +' approach, which you were using in Patch I noticed:
Console.WriteLn( L"omg I failed on '" + strval +"'" ); // tho while type safe, is often ugly as sin if you have 2 or more strings in a single printout.
C# makes this really nice by having a base Object class that allows it to do lots of runtime type checking and smart handling of objects. But then again the object encapsulation features it uses to allow that are also the slowest part of C#. Tradeoffs abound. ;)
arcum42
Yeah, I'd figured out that that worked, but, as you said, mutiple parameters make it ugly. Especially if some of them aren't strings (forcing you to throw a wxsFormat in the mix).
And, yeah, Ruby's pretty good at this sort of thing, too. (Though not the best at Unicode). Objects have a "to_s" method, and if you try to print an object, it prints whatever that method returns. And it's easily overridable.
Of course, again, Ruby's not known for its speed. (And sorry if I compare things to Ruby a lot. I just find the language very easy to use...)
Zeydl...
Nice, first version, that able to run menus for me. But real game -- still no. And release version is crush to,

Revision 2168

Correction to my last revision.
sunnydra...
For recent revisions wxWidgets featuring (including current) i not managed to run pcsx2 bios or iso with success.
what could be wrong?
system ubuntu x32 linux, AMD s939 X2 SSE2
./rebuild.sh
codeblocks rebuild all in release
run pcsx2
but loading iso image or setting to No Disk and Run CDVD cause pcsx2 to shutdown after
Opening plugins...
Opening GS
Opening PAD
Opening SPU2
Opening CDVD
Opening USB
Opening FW
Opening DEV9
Plugins opened successfully.
Issuing EE/iR5900-32 Recompiler Reset
Killed
my plugins are
ibCDVDnull.so.0.8.0 libDEV9null.so.0.4.0 libFWnull.so.0.5.0 libGSnull.so.0.1.0 libOnePAD.so.0.1.0 libPadnull.so.0.1.0 libSPU2null.so.0.7.1 libUSBnull.so.0.6.0 libZeroGSogld.so.0.96.2 libZeroSPU2.so.0.1.0 ps2hw.dat
sunnydra...
what could be wrong? anyone have same problem?
sunnydra...
nailed down..all works(but sloow) if i set EE Engine to interpreter mode
Jake.Stine
Release mode does not work when compiled from GCC 4.4.x.
It's a known issue. The fix is potentially complicated, due to how the recompilers in PCSX2 are written, and how GCC scatterbrains its way through optimizations.
sunnydra...
could you give a tip how to configure wxWidgets to work in debug mode?
./pcsx2-dev Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).
Aborted
pcsx2.cbp debug=no cause program to not compile
sudo ln -s /usr/lib/wx/config/base-unicode-debug-2.8 /etc/alternatives/wx-config not working too...
i guess i give a try to setup gcc 4.3 branch on my system...
sunnydra...
no luck with gcc 4.3 codeblocks profile neither in release or devel.. errors in Utilites
arcum42
I'd make sure you have the debug version of wxwidgets installed...(libwxgtk2.8-dbg? I don't use Ubuntu normally.)
sunnydra...
after ln -s replacement
wx-config --list
Default config is base-unicode-debug-2.8
Default config will be used for output
Alternate matches:
base-unicode-release-2.8
gtk2-unicode-debug-2.8
PS: rename Dualshock.jpg to Dualshock.png to correct rebuild.sh error.

Revision 2169

GSdx:
- Added some sad attempt to fix small upscale annoyances. It's very hackish but
better than nothing :p
- Small cleanups
Autor...
I see you activated WIP code, does it affect smth?
cubi...
Hi there,
I was just wondering about two things with recent builds:
(i) frame limiter - this one doesn't seem to work properly
(ii) GSdx fullscreen mode <- the plugin always activates windowed mode itself again and also doesn't honor the resolution (it displays as 640x480 window)
Are these known bugs due to the wxgui rewrite, or am I simply doing something wrong here? Tested win32 builds on a XP system.
juz...
(i) Known wxgui issue: Press tab to turn limiter on
(ii) this probably also due new wxgui. Happens also with win7 and DX10 HW plugin
rmx.aka....
old revisions of gsdx plugin has not this bug
<= 1846 works fine with new wxgui
problem in plugin, not wxgui
ramapcsx2
Autoran1:
It's more like HacksInProgress code :p But yeah, it may fix some issues. To test it simply use x2 scaling (the other modes are not affected).
liquid.acid: Yes, these are all things not yet done in wx.
akira: What bug do you mean?
dh...
hi rama,
i think the settings in the GSRendererHW.h for the internal res are wrong. with this settings u have a massive overhead of gpaphic memory and this results in big slowdowns (i have posted in the forum previous). i think this while i have the code understand as follows: gabest use a minimal resolution of 512x512. the value for upscale x 3 as a example is 512 x 3 -> 1536. in the code u use 1024 x 3 -> 3072. i have tested it ever and ever and the follow is my result: the most games uses a resolution of 512x512 and many games and the bios uses 640x512. i have the code changed for this and it's works with a good image quality and a good speed. u can test it and u can see ;) here is the change from my code:
if(!m_nativeres)
{
m_upscale_multiplier = theApp.GetConfig("upscale_multiplier", m_upscale_multiplier);
if (m_upscale_multiplier < 1)
m_upscale_multiplier = 1;
else
if (m_upscale_multiplier > 6)
m_upscale_multiplier = 6; //use the max upscale math
if (m_upscale_multiplier > 1)
{
m_width = 640 * m_upscale_multiplier;
m_height = 512 * m_upscale_multiplier;
}
else
{
m_width = theApp.GetConfig("resx", m_width);
m_height = theApp.GetConfig("resy", m_height);
}
}
m_gamefix_skipdraw = theApp.GetConfig("gamefix_skipdraw", m_gamefix_skipdraw);
u can see i have the upscale multipler incrased to max. 6, (640x6 -> 3840). all higher upscale results in a power off from my graphic card (i can't say why a the max internal res that works is 4096). my card is a 8800gt with 512mb ram, maybe works a higher upscale with more video ram...
hope u test it and can verify... and i hope u can understand me, my english is the horror ;)
cu deathcore
ramapcsx2
Yes, I know about this. And I'm sorry to say that it won't work.
Just try these values on tri-ace games, and you'll get totally broken graphics.
The idea is valid though (and it can be made even better), it's just that the GSdx texture cache has a bug somewhere, preventing this optimization.
(If your games work with these settings, you can of course use them. I won't put this on the svn though, for obvious reasons :p )
dh...
hmm.. i have found only 5 games from tri-ace via google, is this valid? the only game that i have is valkyrie profile 2 (pal) and in this game i have no trouble with my code change... the only wrong graphic is in the forest and this is present in all gsdx revisions. mhh, i must go to the video store and hope i find a other tri-ace game for testing... thx rama ;)
ramapcsx2
Hmm, you're right on one part. I'll see if I can avoid the problem I mentioned and still keep the lower rt size.

Revision 2170

wxWidgets/Win32: Force spin control contents to align to the right (they show
integers! By rule numbers should be right-justified).

Revision 2171

Partial implementation of Video configuration panel (totally just for show right
now, does nothing).
Dev note: kinda reached a point where I'd like to make some revamps of the
wxHelper classes based on better understanding of wx-in-practice. So I'm going
to work on a significant refactoring of most pcsx2 panel constructors starting
now. :)
jfre1...
Love the new look of the video settings screen :) +1 from me
arcum42
Sounds like a good idea. The AddCheckBox function could probably use to be able to pass ids, for example.
Of course, I'm looking at the wxCheckListBox class right now, because it might make straightening out the Logging dialog easier. I'm not sure if there's a way to do tooltips on individual checkboxes if I use that, though, or I'd try using it with the Game fixes as well.
For that matter, Logging might not be bad as a panel in the general settings, instead of a dialog. Of course, we'd have to make a graphic for it if we did that...
Jake.Stine
Belated response:
Yea we could add an id constructor to pxCheckBox if we ever need it, although I don't recommend using IDs exception for "standard behavior" type items (ie, Cancel or Apply buttons), or items that have a range of actions that act similarly (ie, many menus), *or* items that don't have "complete". object types (ie, all menus).
Barring those exceptions, Mostly I prefer using object-based coding instead, ie:
Using an ID I have to define the custom arbitrary ID, usually at a global scope to ensure it avoids conflicts with other control IDs. If we just record a pointer to the wx object, it's a single addition to the class itself, with no global hogwash to worry about.
and the ID of any control can be retrieved like so:
Connect( m_check_MyBox.GetId(), wxEVT_COMMAND_ETC, func );
... so as far as I can tell, this is easier than using IDs in most cases.
(and this is all probably good tips to be added to the wxWidgets Coding Strategies wiki, which I'm also hoping to find time toupdate one of these days ;)

Revision 2172

Whops :p

Revision 2173

Yay includes.
bigdeak
.... lol xD
i like sandwitch with cheese x3
arcum42
Yeah, the comments you run across in the code sometimes are fun.
Maybe I should have titled this revision "Yay, sandwiches!". ^_^
arcum42
(The point of this revision, of course, was to fix compiling in Linux again. I just get tired of "Fix Linux" for my revision names...)

Revision 2174

GSdx:
- Reduced the overhead of the new scaler. Instead of just using 1024*1024
blindly, it tries to adapt to games native resolutions.
- Yet another change to IncAge(), since it seems to be (mis)used to do texture
invalidation. (Fixes Disgaea 2 when booting through the BIOS)
- Added some comments
Note:
Before working on the texture cache GetDisplayRect(),GetFrameRect() and
GetDeviceSize() really need fixing. It's useless to try and find surfaces when
not knowing the real size of things.
lemuel2010
Always +1 in progress plugin Gsdx. When D3d fix jak & daxtar?
eliotfur
GSDX progress is highly appreciated since Gabest has gone... Hope to see correct HW rendering of Devil May Cry 3...
BTW, What about DX11 renderer?.. DirectCompute is available on DX10 devices too after a platform update from Microsoft...
diego...
good to see some gsdx fixes,hope they add some crc soon.
dh...
hmm... in the function Draw() u multiply the m_height double... first: int testh = GetDisplayRect().height() * multiplier;
and then m_height=testh*multiplier;
is this right? i think u will use this: m_height=testh;
ramapcsx2
dhaft: You're right. Leftover from a cleanup :p
Xeli...
"GSDX progress is highly appreciated since Gabest has gone... "
Hold on, clearly I've missed something. Since when is Gabest no longer considered part of the team?
dh...
i think gabest have no time a i hope he come back... gsdx code is extremely complex and fix it is a programmer's hell...
kamui_...
Hi, I'm orbb, I suggested the upscaler in that forum, do you remember ? :)
This commit have a problem, the bugs that I had returned in odin sphere (exactly like before the upscaler), I don't think that using the game native resolution is a good idea, in odin sphere for exemple, the native resolution is 512px width, and the textures are as big as 1024px width if I remember, or 2048px, I dont know. Anyway, the bug returned, so there is a problem with the upscaler again ...
dh...
i can't confirm orbb, i have odin sphere tested now and it work good. odin sphere uses resolution of 448x512 (pal version) as standard and with the upscaler works this great (full speed and good image quality)...
@rama: i can't understand the follow: u call in the code the test of m_width and m_high in GSTexture* GetOutput(int i) and in void Draw(), why? the GSTexture* GetOutput(int i) is called ever before called void Draw() and the m_width and m_height is set correct when Draw() is called... the next: the test for testh and testw is wrong in Draw(), testh and testw is never 1... u multiply testw and testh with the upscale multiplier and so is the min value of testw and testh the upscale multiplier and not 1 ;) i have logged and in GetOutput is testw or testh never 1, the test is also not needed here... only in Draw() come this and here is a test for m_with and m_height not needed if it's set in GetOutput before... a i can say the gsdx code is the hell, i work on it the last night and i have included a correct upscaler for the resolution of the game. this works great a in many games i have trouble at the moment (Animaniacs - The Great Edgar Hunt and devil may cray with the text in video sequences)... i will continuing search for a way to correct this. now i have found a way for video playback in ffx-2, this works now... i post it when i have entirely all..... (damn hell, where is gabest ;) )
ramapcsx2
Ghe.
You're again right. The == 1 check was from when I didn't yet multiply testw/testh beforehand.
Correct test now would be for "== 1*multiplier" :p
And yeah, this shouldn't be so hard. Yet the whole problem with the texture cache deficiencies makes it a pain to work on :/
Thanks again, and I hope you have some success yourself.
Will gladly update GSdx with a patch, should you get it working.

Revision 2175

GSdx:
- Detect more games that blur (Dragon Quest 8)
diego...
Captain tsubasa too,has that blur

Revision 2176

Fix a mistake. Thanks for spotting it, dhaft.

Revision 2177

Disable Interrupt is now recompiled, thanks to pseudonym :p
This is a significant speedup in Suikoden 3 menu's.
And any other obscure game that might do that a lot :p
xat...
iHaveNoIdea heheh..
leomar....
The graphics lost much clearness(sharpness), they are as in an old TV!

Revision 2178

Partial re-implementation of emulation Trace Logging. Still a work in progress.
>_<
Jake.Stine
I also removed the old unused PsxHw Read and Write variants in this commit.
Zeydl...
You broke compilation in gui/GlobalCommands.cpp 109: error: invalid conversion from ‘const char*’ to ‘char*’
arcum42
And removed a bunch of old junk, revamped how logging is done, and a bunch of other nifty stuff.
And beat me to removing those PsxHw variants. (I had them commented out in my local trunk...)
Zeydl...
And in /ps2/Iop/IopHw_Internal.h: 214 and 216 you use (sizeof T) * 8 instead (sizeof(T)*8), don't know, but my GCC 4.3 don't compile you version.

Revision 2179

Fixes release-mode build targets from my prev commit.
andutrache
+1 i was just about to yell "BUILD IS BROKEEEEEN !!!" in the previous commit.
XD

Revision 2180

No more sandwiches...
arcum42
I didn't just turn GSprintf into a const because I wasn't sure if it'd break the graphics plugins loading in Linux. I've seen similar changes break them before.
arcum42
And Jake removed the sandwiches in r2178.
Jake.Stine
Nah, my sandwich only moved: https://code.google.com/p/pcsx2/source/browse/trunk/pcsx2/gui/Panels/BaseConfigPanel.h?spec=svn2178&r=2178
airmake...
Haha :) I just had to make that fix myself when I tried compiling.
But don't you have to allocate memory for message first?
airmake...
Btw, when I run, PCSX2 crashes on GPU plugin loading it seems. Is that normal? :V
Bios Version 2.0
Load Bios Warning: rom1 module not found, skipping... (this is not an error)
Load Bios Warning: rom2 module not found, skipping... (this is not an error)
Load Bios Warning: erom module not found, skipping... (this is not an error)
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
Opening plugins...
Opening GS
An unhandled runtime error has occurred, somewhere in the depths of Pcsx2's cluttered brain-matter.
Jake.Stine
omg you're right. That's pretty horrible memory corruption oopsie there... >_<
And really it's also fixable with a const_cast. That'd be the better option.
airmake...
Owh, btw, arcum. Should I compile with GCC 4.3.3 or 4.4.2? (Also, how to I pick which GCC to use in code::blocks?) I remember there used to be a really weird bug when compiling with GCC 4.4.x when it was released.
Jake.Stine
@arcum42:I'm on my way out the door for dinner and a movie, but here's what you want to do:
GSprintf(10, (char*)(EmuConfig.Trace.Enabled ? "Logging Enabled." : "Logging Disabled."));
That'll suppress the warning.
Or the C++ way:
GSprintf(10, const_cast<char*>(EmuConfig.Trace.Enabled ? "Logging Enabled." : "Logging Disabled."));
Your pick :)
arcum42
I had it crash once on loading the GS plugin, but my computer was acting like it was running low on memory. I freed up some memory, and it stopped crashing there.
So I'd assumed it was just funkiness from my computer being nearly out of memory. Firefox tends to do that to me if I leave it running for a few days...
airmake...
Well, I have several GB not in use (well, it's cached though). I'll test more :)
Btw, you need to remove I think:
g++: ./.objs/release/gui/Panels/BaseConfigPanel.o: No such file or directory
:p The file (.cpp) isn't even there to begin with.
arcum42
I already did. Trouble is, I didn't close Codeblocks before committing, and it saves those changes on closing.
And I vary on which gcc I use. Since the rebuild of my chroot, I've been on gcc 4.3.3, but I had been using gcc 4.4.2.
Switching is a matter of doing:
gcc-config -l
To list profiles, and then doing:
gcc-config 1
(or whatever the number of the version of gcc you want is.)
On my computer anyways. I don't think codeblocks itself will let you change gcc versions.
airmake...
I see. Can't find anything called gcc-config in Arch, although I find a Gentoo package for it ;D hehe. I'll test 4.3.3 then. I've been having strange problems which I think are due to 4.4.x lately ...
arcum42
Yeah, wasn't sure if that was distribution specific or not. Unfortunately, I'm familiar enough with gentoo that I forget where the lines are drawn occasionally.
airmake...
Well, I found a better way. Settings -> Compiler & Debugger -> Toolchain paths :)

Revision 2181

Layout improvements for the Logging dialog; still not connected or saved tho

Revision 2182

Should probably drink something with caffeine in it, and worry about sandwiches
later.
arcum42
I'll have to try to make sure I'm more awake when committing in the future. I have this bad habit of checking for new commits at a point that's basically first thing in the morning for me...
Zeydl...
It still does not want to be linked.
Linking executable: ../..//bin/pcsx2-dbg
g++: ./.objs/debug/gui/Panels/BaseConfigPanel.o: missing file or folder
last veresion I was able to build was 2173
Zeydl...
A, here the deal, BaseConfigPanel.cpp was added, but no exists.
arcum42
Yeah, I deleted it from the project, but codeblocks doesn't save the project automatically when you build the program, like it does for source code, so it didn't get into the trunk.
I'll fix it next commit, but that'll be after I'm back home, so not for a while...
Jake.Stine
Oh, that's supposed to be BaseConfigPanel.h
Sorry about that.

Revision 2183

Implemented a feature which could potentially reduce the slight slowdowns
present when running in windowed mode inside Aero.
Since it's late, I will leave it to the world to figure out of it really makes a
difference.
ramapcsx2
Hmm, Aero still is a slowdown in gpu intense games for me.
What's funny however is that dragging around the main pcsx2 window causes speedups though :p
Letting it go, and speed goes down again (80fps with Aero enabled, 96 with it off or when in fullscreen).

Revision 2184

Small cleanup on the GUI. Only show the "Debug" entry on devel and debug builds,
as in legacy_gui.

Revision 2185

Patches don't need to go, they work apparently :p

Revision 2186

Legacy_gui:
- Various updates from wx, smart frame limit, SIF timing fix, DI does less
unneeded work.

Revision 2187

Finished the new logging options dialog (loads and saves settings (!))
Jake.Stine
Just for the record, I'll point out here that several of the trace logs aren't yet implemented properly, and that for the most part I think the SourceLog header files are obsolete: there ar eonly several variants of log function because of the old remote debugger that, apparently, never "really" worked anyway (certainly was win32 only if it did).
So I'm considering removing a lot of that macro mess and replacing it with a cleaner single logfile handler.
And one last thing: I removed the option to pipe trace logs to STDOUt, since most of them are so high volume they're completely useless in that regard (they just bring a whole PC to its knees listing tens of megs of data per second).
arcum42
That's definitely an area that could stand cleaning up.
As far as piping trace logs to stdout, that still strikes me as useful just so you can see what's being called live when things happen in the game. The heavy volume of logs does make it hard to do that, though.
It might be an idea to rank how often the log messages are useful, and then have levels of output to the logs, so that on light it logs the bare minimum of what's going on, and heavy has everything. Even if it isn't going to stdout, it might make sifting through the output easier.
Timestamps could be useful, too, for the actual log file.
I also have to wonder how many of the log messages are still useful, and how many are legacy...
Jake.Stine
>> As far as piping trace logs to stdout, that still strikes me as useful just so you can see what's being called live when things happen in the game. The heavy volume of logs does make it hard to do that, though.
With wxwidgets it *should* be a lot easier to set up basic GUI stuff for live action reporting. I'll be working on that eventually, when we get to the point I can work on the Debugger and other trace/troubleshooting aspects of PCSX2.
>> It might be an idea to rank how often the log messages are useful, and then have levels of output to the logs, so that on light it logs the bare minimum of what's going on, and heavy has everything. Even if it isn't going to stdout, it might make sifting through the output easier.
I was thinking we might just be better off having two separate types of logs -- Trace logs and Toggle-able Console Logs (like the CD Read log, in fact). I looked over the existing batch of trace logs and the *only* ones that could be seen as being useful when directed toward the console are the VIFunpack, GIFtag logs, and the USB/FW/DEV9 logs (if implemented). All the others pretty well stop the emu in its tracks when enabled to console.
But yea, I dunno. Mostly I just didn't have a good home for the Pipe to Console switch in the dialog, and didn't want to set up the switch and ini save/load and stuff unless I had a compelling reason for re-adding it. :p

Revision 2188

Implemented new pxCheckBox into the rest of the gui components.
Jake.Stine
Ok, idea here is that I'm going to try and lay out most of the dialogs so that they construct objects in one stage, and then lay them out in another stage -- rather than having layout and construction inline together.
The one exception will be StaticText, which is typically a simple object that we don't "save" the handle for, so it'll continue to be constructed inline at the same point it's added to the sizer layout.
I'm hoping when it's said and done, the code will "feel" more maintainable. :)
Jake.Stine
Note: I'm off to work, so I'll be scant for the next 4-5 days. Have fun. :)

Revision 2189

Update the codeblock project.
Xeli...
What exactly is the codeblock project anyway?
arcum42
In Linux, we're using an IDE called codeblocks to compile pcsx2.
So pcsx2-codeblocks.workspace is the Linux equivalent of pcsx2_suite_2008.sln, and pcsx2.cbp, which I just updated, is the equivalent of pcsx2_2008.vcproj.
In this case, one of the filenames in it was wrong, causing pcsx2 not to compile...

Revision 2190

GSdx:
Gave up on the smart m_width / m_height adjustments for now. This just won't
work the way I imagined it :/
Using a "common" size of 640*512 instead. This means some odd games might use a
wrong output surface again (they always did this on the normal upscaler).
ramapcsx2
I'm doing this mostly because I found another case of a problem.
ICO renders to a 512 * 448 target usually, but it switches to something GSdx detects as 720 * 480 for an fmv.
With the smart adjustment, at x2 scaling, this means an output surface of 1440 * 960, which kinda works.
After the fmv is over and the game return to its native res, GSdx still uses the big output surface, causing a nice, black screen with a bit of garbage :/
This is the main issue we're having currently. GSdx isn't smart enough to detect which is the right output surface.
diego...
Thats not so bad,i mean at least you are trying,anyway that detection stuff seems pretty advanced but it think you can make it work later
dh...
hmm i will test with ico a i can say that gsdx scale correct up and down by me with my changes at the moment... i post it to night when it's work correct, i test it for a while....
ramapcsx2
Sure, it can only get better now :p
dh...
i hope ;)
ICO is a damn game, i have no more problem with upscaler, the only is that ICO use a half screen high... problem is solved a i can't play this game: with pcsx2-new gui i can go into the first room and the camera pans up and i can't see my character. with pcsx2-legacy i have not this camera problem a the character runs often into a wrong direction... is this known or is this a problem with the pal version only?
ramapcsx2
Set EErec clamping to full. This is a problem we're working on yet, it'll be fixed soon :p

Revision 2191

Add 'Print CDVD Info' back in. In Linux, make writing to stdio optional. Make a
few log messages grey. A few misc things.
arcum42
If I removed all the #ifdef __LINUX__ statements, the Linux only stuff for writing to stdio would probably work, but I want to test it in Windows before doing that.
arcum42
Or maybe not. Tested it, and all those wxPrintf statements seem to end up in the Console window if you remove all the ifdefs. I'm sure there's a way to redirect their output to stdio, but given that wxPrintf's undocumented, and it's not exactly a priority, I'll wait a while on it.

Revision 2192

Expand the color list a bit, muck with the Linux color console code, and change
a few ifs to a case statement.
gigaherz
Modify /trunk/pcsx2/HwWrite.cpp diff
Contents and properties are unchanged.
^ WTF?
arcum42
It probably changed some line endings or spaces into a tab or something and didn't think it worth displaying. I changed something minor in HwWrite.cpp for testing purposes, and then changed it back. Codeblocks has a tendency to make my svn diffs look screwy anyways, so it's probably an extension of that.
Jake.Stine
Specifically, Codeblocks removes all the whitespace on empty lines:
void func()
{
CodeLine1();
CodeLine2();
}
The middle line, typically in MSVC will have a single TAB character during the course of standard editing. Codeblocks removes those when it saves a file. Personally I approve of that and wish MSVC did the same. The IDE can always enforce cursor position to default to the current "smart" tab depth regardless of if the tab character is actually in the file or not.
Several HTML/PHP editors have the same feature, to remove whitespace on empty lines.

Revision 2193

Some header cleanup.
Jake.Stine
@Arcum: Just so you know, I'm working on a pxRadioGroup panel now, which will basically replace the AddRadioButton stuff. Radio Buttons typically work based when grouped together via panels anyway (which currently we're not doing since it's red tape extra work). So I'm just going to design it with that in mind.
arcum42
Sounds pretty useful. You could probably just give it a list of strings, a default value, and some header text, and ask it what index is selected, depending on how it's implemented.
I've just been looking at whatever strikes my interest recently.
With the Console Logger code, it feels like there ought to be some way to just register all the IConsoleWriter's we want to use, and have it send messages to all of them automatically, rather then the workarounds we have now.
I wasn't feeling ambitious enough to write that, though. Now right now, anyways.
Other ideas that occurred to me were being able to filter what output prints by color (I could see turning off all grey output being useful, for example), and writing a IConsoleWriter class that outputs to a html file (with color, of course).
Not sure if I'll do either one, though. I often have ideas that I never get around to, or put on the backburner for a while...
Jake.Stine
The first I'd considered when I rewrite the Console system, but honestly C# has an open-ended logging system like that and I'm not very fond of it's complexity, so I purposefully avoided it. I was also concerned with the overhead, although that's not a concern after all (traversing a list is nothing compared to the overhead of converting UTF formats and passing messages across threads).
The trick with saving HTML is that it'd probably have to be disabled for trace logging, since loading extremely large HTML files in any browser tends to be... problematic.
Masking colors isn't really a problem, although I personally wouldn't have a use for it. I usually like to see as much of the "default" console logging info as possible at all times. I almost always run in debug mode so that I can see all the SYSCALL logs and manual block protections. ;)
arcum42
I might just write one IConsoleWriter that does nothing but pass the commands on to the appropriate IConsoleWriters. That'd be easy enough. Or I could just leave it the way it is for the moment. It works, it just seems odd to pass a command to the Window console, which passes it to the file console, which then passes it to stdio.
Hadn't really thought about having issues with the html files, because I've read full novels as html files before[1].
The masking colors mainly occurred to me because I play games that spam certain messages a lot, and the background noise can be distracting.
BTW, as far as converting shift-JIS to unicode, I noticed that if you look at the pathnames printed, they look something like this("¥VPACKJ¥V16000.AFS;1"), with yen symbols instead of '\' signs.
Reading up on Shift-JIS, I found that in the initial character set, one of the few differences between Shift-JIS and ASCII was that char 5C was a yen symbol and not '\'.
Makes me wonder if Sony's using a modified version of shift-JIS with the '\' symbol there, if they honestly use yen symbols for paths, or if they switch character sets depending on the region of the game, since this is a US game[2].
[1] Legally. Baen books has got to be my favorite publishing company for their free book library. And I've found free books in other places, too.
[2] Ar Tonelico 2, in this case, though most Gust games have pathnames listed, as it's reporting not hitting the cache for those files. (Since we don't have a cache.)
Jake.Stine
>> [2] Ar Tonelico 2, in this case, though most Gust games have pathnames listed, as it's reporting not hitting the cache for those files. (Since we don't have a cache.)
That's nothing to do with the CPU cache. That's an internal file cache that many games have, and the cache always misses a whole bunch on boot-up because,of course, nothing's been loaded yet. After the initial series of file loadings, usually subsequent stage loads have a lot fewer cache misses. ;)
I't quite possible Sony has a special Shift-JIS encoding. There are like four different "standards" and a half dozen more hack-ups of it. I'll check it out, see what I can figure.
Jake.Stine
>> I might just write one IConsoleWriter that does nothing but pass the commands on to the appropriate IConsoleWriters. That'd be easy enough.
Also, yeah -- that's what I'd do too.
arcum42
Makes sense. Intellectually, I know there are different types of caches, but seeing warnings about a cache, and knowing of a cache we didn't implement, I jumped to conclusions there.
And, yeah, the wikipedia page says "numerous minor variations" of shift-JIS exist, so that's what I was thinking. Substituting 5c for char 5c of the single byte encoding array obviously makes the paths look right, but who knows what other characters are different?
And I'll probably implement the message-passing IConsoleWriter at some point, if you don't do it first. I'll have to be in a coding mood first, though, and I'm more in a mood to read vampire detective novels. ^_^

Revision 2194

Remove the MPEG hack; Mana Khemia no longer needs it, as of the voodoo cycle
fixes.
ramapcsx2
The digital devil saga remark is interesting.
It had a few fmv not working before the cycle fixes, so both games share the same problem with the IPU it seems.
arcum42
That is interesting. I recall that the digital devil saga issue was the main reason why I didn't just put the mpeg hack in permanently on.
We're probably due to check the other hacks and see in they are necessary, come to think of it. Trouble is that I don't own most of them...
ramapcsx2
Well, most are floating point rounding issue workarounds. What's left is this:
- Fatal Frame with the dma exec hack << still needed, and likely a problem in other games, too.
- Erementar Gerad (or whatever :p ) << can't test this, I don't have this game.

Revision 2195

Added pxRadioPanel, a nifty all-thrills container for radio button groups.
Removed AddRadioButton. Moved SizerFlags and other wxHelpers to Utilities class
(optionally accessible by plugins).

Revision 2196

Fix up Linux, as well as make a few minor changes to onepad.

Revision 2197

Trim and tweak a bunch of includes, and a few headers.
arcum42
I'll check this in a few minutes against Windows.
arcum42
Compiles a Devel build successfully. Now I'm doublechecking release.
Basically, what I did in this commit was I tweaked Common.h and IopCommon.h, removing a few includes, added a new header, Hardware.h, and went through deleting a bunch of unnecessary includes all over the place.
arcum42
Release build's fine too, btw.
andutrache
Cant buil this rev it gives me Error 1 Error result 31 returned from 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe'. Project pcsx2
andutrache
build* damn no edit button
andutrache
ok an exe shows up even with this error but when i try running it its says MSVCP90.dll is missing what am i doing wrong all was working fine till now and i didn't change anything.
Jake.Stine
run clean_msvc.cmd and try again.
andutrache
that fixed it thank you :)

Revision 2198

Mode console logging updates and additions;
* Added support for indentation, as a replacement for using \t (options
include methods SetIndent and Indent, and a ConsoleIndentScope class for scoped
indentation of a block of WriteLns.)
* Use of Indent() as a modifier (the abstraction optionally allows use of
indentation methods besides \t, if ever needed).
* Minor header file cleanups: wxWidgets standard headers are now always first
in PrecompiledHeader.h files (is recommended due to cross platform setup code by
wx).
Jake.Stine
I'm "mostly" happy with this. There's probably room for improvement .. tho when isn't there? ;)
I could have also used a \t replacement parser instead of the Indent() approach. \t is more compact I suppose, though it wouldn't have allowed for scope-based tabbing.

Revision 2199

Lots of wee bugfixes to user interface stuffs

Revision 2200

Removed NULL-able DoWrite/DoWriteLn in IConsoleWriter (threaded logging crashed
when changing writers on the fly).

Revision 2201

wxWidgets/Win32: Added tooltip duration override of 10 seconds, so the tooltips
stay visible long enough to finish reading them.
For the curious: tooltip duration defaults to a function of your configured
mouse doubleclick rate, which happens to be something a lot of us users probably
set to something pretty fast or really fast, to avoid accidental double clicks
(mine's like 1 or 2 notches away from the fastest setting). So my tooltips only
stayed visible for like 2 seconds. >_<
Jake.Stine
Oops. I defaulted to 8 seconds, not 10. Sigh. Sleep time.

Revision 2202

SPU2-X: Implemented SPU2test - it now reports an error and returns failure on
CPUs not supporting SSE2.
DevNote: SPU2-X now links against w32pthreads and x86emitter.
dh...
can't compile spu2-x seperatly, the dependence for w32pthreads.v3, w32pthreads and zlib not set in the project ;)
docutu...
i am able to compile but it stop to recognize my audio driver even using the direct audio option, before it works well
docutu...
it is unable to retrive the name of the audio driver
http://i50.tinypic.com/e8vb0j.png
and here is my audio driver
http://i46.tinypic.com/23tquc4.png
docutu...
the log
DwmEnableMMCSS successful.
Initializing PS2 virtual machine...
Allocating memory for recompilers...
Loading plugins...
Binding GS : C:\Program Files\PcsX 2\plugins\gsdx-ssse3.dll
Windows 6.0.6000
NVIDIA GeForce 7600 GS (8.16.11.9062)
Binding PAD : C:\Program Files\PcsX 2\plugins\LilyPad.dll
Binding SPU2 : C:\Program Files\PcsX 2\plugins\SPU2-X.dll
(thread:PersistentThread) Plugin Test failure, return code: -1
C:\Program Files\PcsX 2\plugins\SPU2-X.dll
User-canceled plugin configuration; Plugins not loaded!
chuuey
got the same problem as docuturno, on windows xp using realtek hd sound ;)

Revision 2203

Hack Hw.h in half and do a bit more header cleanup. Remove a header that's
unused.
arcum42
There is probably a bit of room for cleanup on the divide between Hw.h and Dmac.h here. I'd felt for a while that Hw.h could use to be separated into two files, though. It was a pain navigating through all those enums when you want to tweak the structs that used to be in there...

Revision 2204

w32pthreads: Remove macro redefinition of __except (it was a nasty and entirely
unnecessary hack intending to protect idiot coders from their own failure to
comply to very strict SEH exception handling rules).

Revision 2205

Fixed the Recent Iso List, which got broken a few revs back... and many more wee
bug fixes, most are too unimportant to list here!!
Code Cleanups:
* cpuDetect: Split Win32/Linux code portions into separate modules. (probably
breaks linux)
Jake.Stine
Oops. my ?! mod in DEV9 slipped in. That was me making sure I was testing the wright version of dev9.dll ;)
arcum42
I was wondering... ^_^
pcsx2gu...
Breaks windows compiling (2206 doesn't compile either):
12>..\..\gui\AppRes.cpp(77) : error C2675: unary '__assume' : 'ScopedPtr<T>' does not define this operator or a conversion to a type acceptable to the predefined operator
12> with
12> [
12> T=wxMenu
12> ]
12>..\..\gui\AppRes.cpp(83) : error C2675: unary '__assume' : 'ScopedPtr<T>' does not define this operator or a conversion to a type acceptable to the predefined operator
12> with
12> [
12> T=RecentIsoManager
12> ]

Revision 2206

Quick fix on the last commit for Linux.
arcum42
And I'm off to bed...
Zeydl...
Also you should remove cpudepect_internal.cpp from cbp file. It's still unbuildable with it.

Revision 2207

* Implemented more support for on-the-fly CDVD source changes (not well tested,
probably need work).
* Fix Reelease mode compilation errors.
* More misc bugfixes to the UI.

Revision 2208

Bring back color to stdio on Linux.
arcum42
Everything went to black and white somewhere in the last dozen commits. This fixes it, and takes care of a project file update that was missed in my last commit.

Revision 2209

MSVC: Added missing dependency build order settings for SPU2-X

Revision 2210

A bunch of Codeblocks project changes.
arcum42
Changes I made:
Removed the NDEBUG define. I don't believe it is needed any more, and it seemed to be at the root of the devel build errors.
Replaced -O2 with the individual optimization flags.
Changed it to no longer check whether wxGtk is a debug build or not.
Messed with the compiler warnings.
And I recompiled pcsx2 way too many times. I'm able to compile the debug, dev, and release builds ang run a game with all three, and I tested with both a debug version of wxGtk and release version, though admittedly, my testing was less thorough on the latter.
Think we should be good with these settings, but it could use doublechecking...
arcum42
Should take care of Issue 474 and Issue 475 , btw.
airmake...
GCC 4.5 for the measure :D
Problem in OnePad/Linux/interface.c
An int is falsely casted to const gchar * in line 53.
Changed from
gtk_about_dialog_set_version (GTK_ABOUT_DIALOG (About), VERSION);
to
const char version = '1'; // const char version = 'VERSION'; gave me a warning of overflow. :V
gtk_about_dialog_set_version (GTK_ABOUT_DIALOG (About), (const gchar*)&version);
Probably dirty and wrong, but compiled at least :) Similar error in ZeroSPU/Linux/interface.c
I still get the same problems when trying to run a game though. I just get the "Cannot open GS plugin", and it bumps me back to the plugin selection screen. :\ I've tried several different GCC's 4.3, 4.4 and 4.5, and same stuff happens. Maybe something weird is going on with my bios image?
airmake...
Well, when I look at what I just wrote, it looks retarded. Maybe it's supposed to be #define VERSION "1" instead :v
airmake...
Well, what software are you running actually? It may not be a GCC issue after all.
Building and running in 32bit chroot, x86_64 Arch
gcc 4.3.3, 4.4.2, 4.5.0 (devel)
glibc 2.11
binutils 2.20
nvidia 190.42
nvidia-cg-toolkit 2.2
wxgtk 2.8.10.1 (not built with debug stuff)
xorg-server 1.7.1
jaens...
> const char version = 'VERSION'; gave me a warning of overflow. :V
Now that's strange. What's wrong with storing 7 characters in a character?
david.jennes
Probably 'cause it should be a pointer? :-P
airmake...
jaens, #define VERSION 1 in the source.
I'd expect const char version = '1'; to work :p hehe

Revision 2211

Fix the definition of VERSION in ZeroSpu2 and OnePad.

Revision 2212

* Added a 'master' toggle to the Speedhacks panel.
* ... more WIP stuff on the Video options panel.
* Spent 12 hrs working on crap text wrapping and window sizing issues.
* Moved several UI classes to utilities (lots of project changes, breaks linux)
* Fixed stilly bug in SPU2-X that prevented it from working (at all).
* Lots of code cleanups, and 1 or 2 bugfixes.
Jake.Stine
I feel bad for leaving the linux projects totally non-updated on such a large change, but I'm beat. Totally dead beat. And I really don't have much to show for all the work, which is depressing.
docutu...
dont give up ! :-) thx a lot for the time spent on the project
ramapcsx2
Fun thing, I debugged the spu2-x init problem as well, and was ready to commit the fix.
Nice work here, more master toggles ftw :p
kenzozus...
broke speedhack tab.
ramapcsx2
Yeah, so this should be a +40 commit :p
Anyway, looks like this now:
http://img5.imagebanana.com/view/lebimx2t/Unbenannt.jpg
ramapcsx2
Should be fixed in r2216.
azte...
"Comment by docuturno, Today (6 hours ago)
dont give up ! :-) thx a lot for the time spent on the project"
i say the same. :)

Revision 2213

GSdx/SPU2-X: Perform SSE checks before entering Configuration dialog (prevents
crashes on non-SSE2 machines)

Revision 2214

Cleanup from earlier commit -- forgot to remove some obsoleted sizer code.

Revision 2215

SPU2-X:
- Set the "latency" slider adjustment resolution to 1, so it's actually possible
to set the value the user wants.
ramapcsx2
Since the slider is some kind of exponentials based, this change makes the resolution at small values too "fine".
You'll need to press right like 4 times when going from "50" to "51", but at least you CAN go there now ;)

Revision 2216

Fix the speedhack panel.

Revision 2217

Linux compilation fixes and fix some signed/unsigned stuff in IsoReader.
Jake.Stine
... I did forget to remove some of the old files from pcsx2.cbp, which have been moved to Utilities.
Also, my Utilities lib is getting fat now.. and is a mix of Base tools and UI tools. I'll prolly need a bit of organizational love one of these days.

Revision 2218

Remove some old files from the codeblocks project.
Jake.Stine
I think that conditional in VU0 micro is potentially important. While GCC optimizations will typically factor it out, in any other compiler the -1 is translated into 0xffffffff and issued as an equality comparison that way.
I checked, and Ref's VIF code definitely purposefully issues -1 as a parameter, with the intent of executing VU0 micro program code, without changing the current TPC address.
arcum42
All right, so we should probably cast it to a int there?
Jake.Stine
So the logical fix is to compare against 0xffffffff, I guess. Though I've personally been known to use the -1 trick:
(u32)-1
... since I hate counting f's. ;)
But otoh, GCC will optimize that out of existence too I guess (because it relies of twos compliment math, and GCC considers that "undefined" since on computers from 1973 that use ones compliment such code would break).
Jake.Stine
Oh, and there's also UINT_MAX / ULONG_MAX
I dunno. Pick your poison, I guess. ;)
arcum42
Well, it doesn't complain about (u32)-1, so I'll go with that. I'm trying to figure out what in IsoFileFormats broke Iso file loading, though, so it'll probably be a few minutes before I commit anything...
Jake.Stine
Ln 376: if (ret < lsn) return -1;
That broke it.
I thought I might get myself into trouble.. I was trying to fix some signed/unsigned stuff in GCC from codeblocks, and I suck at cross-referencing code without all my MSVC / VAX tools. :p
arcum42
Yeah, that's the one. I'd just traced that back, and given that ret is usually 0 and lsn is usually values like 314015, I can see where it would be an issue... ^_^
Jake.Stine
Yeh, all the other readfile calls return the # of blocks read. So it threw me off, making a dangerous assumption of consistency.
That whole thing needs to be updated to use sensible inputs and return codes, or use exceptions instead of return codes, or something. It's a bit raw right now.
(Also, we can replace the Win32/Linux dual _readfile api with cross-platform wxWidgets stuff)
arcum42
At the least, we could switch them to booleans, with true for success, and false for failure. I've done that to a bunch of Vif code that returns -1 and -2 for error codes, since I figured out that nothing was actually checking more then if it was negative or not.
Haven't committed that yet, though.
And, yeah, gcc likes to complain a lot about signed and unsigned variable comparisons. It's possible to disable, but I occasionally find interesting things because of it...

Revision 2219

Fix iso loading.

Revision 2220

Lets use boolean return values in a few places in the iso code.
juz...
in IsoFileFormats.cpp in function bool isoDetect you could just
return detect(iso);
instead of
return (detect(iso) == 1);
because of the detect() function returns boolean value already. Just minor cleanup but it's quite useless to compare boolean value and then return same boolean value after one extra comparison
arcum42
Actually, come to think of it, I didn't mean to return a bool on detect because it returns 0,-1, and 1. I was going to leave cleaning that one up for later.
I'll change it back to an int for now...
juz...
oh. missed the part it returning 3 values. Just scrolled changes too quickly..

Revision 2221

* Speedhacks master toggle saves now.
DevStuff:
* Added a handful of operator+= overloads for working with wxSizers --
moderately reduces code clutter. :)
* Commented some of the wxHelpers classes (pxStaticText, wxPanelWithHelpers,
etc).
Jake.Stine
Crap, I wanted to commit the modified setup.h files of wxWidgets separately or, at least, make a comment about them. I forgot about it though when I got the operator+= idea, and it turned out to work *really* well.
I may extend it further tomorrow btw, and make pxStaticText implicit, so that you can just do this:
*this += _("Hi Mom! No Hands!");
... to add static text to the containing sizer of a panel.
arcum42
Gcc's complaining about it, unfortunately. I get "explicit template specialization cannot have a storage class" on lines 66 of pxCheckBox.h, and line 94 of pxStaticText.h.
I can get around it by removing static from those lines. Not sure it there's better way, though. It seems to be a gcc 4.3+ thing:
http://gcc.gnu.org/gcc-4.3/porting_to.html
arcum42
Oh, and I like the idea having the pxStaticText implicit, btw. It makes things easy to read...

Revision 2222

Various minor fixes. Corrected a few misspellings, fixed a console message or
two, and got Linux to compile again.
ramapcsx2
,and broke windows. :p
12>Linking...
12>AppMain.obj : error LNK2005: "void __cdecl operator+=<class pxStaticText>(class wxSizer &,struct pxWindowAndFlags<class pxStaticText> const &)" (??$?YVpxStaticText@@@@YAXAAVwxSizer@@ABU?$pxWindowAndFlags@VpxStaticText@@@@@Z) already defined in AppInit.obj
12>AppMain.obj : error LNK2005: "void __cdecl operator+=<class pxCheckBox>(class wxSizer &,struct pxWindowAndFlags<class pxCheckBox> const &)" (??$?YVpxCheckBox@@@@YAXAAVwxSizer@@ABU?$pxWindowAndFlags@VpxCheckBox@@@@@Z) already defined in AppInit.obj
12>IsoDropTarget.obj : error LNK2005: "void __cdecl operator+=<class pxStaticText>(class wxSizer &,struct pxWindowAndFlags<class pxStaticText> const &)" (??$?YVpxStaticText@@@@YAXAAVwxSizer@@ABU?$pxWindowAndFlags@VpxStaticText@@@@@Z) already defined in AppInit.obj
arcum42
Which would be the exact piece of code I had to change because it broke Linux. Great. Suppose I'll have to #ifdef it till Jake has a look at it.

Revision 2223

A few more minor changes.

Revision 2224

Slap a patch on things so Linux and Windows work till it can be looked at.
arcum42
That *ought* to fix Windows, unless I'm misjudging where the issue is.
Jake.Stine
Yeah it works.
The other thing that apparently works is using "inline" instead of "static". This is one of those magically retarded C++ "rules" that just makes no sense.
Jake.Stine
I'm fixing it up now, btw. :)
Jake.Stine
... also I wonder why the template versions in wxGuiTolls don't also have the error. Sigh. So stupid.
arcum42
What's worse is that I gathered the behavior is new, deliberate behavior in gcc as of 4.3. Introducing new ways that your code won't compile isn't really what I look for in new versions of a compiler...
Jake.Stine
Yeah, it's silly. Basically it should be a warning, not an error. Storage classes on explicit templates are ignored. Fine. Ignore them and don't break plz? ;)
But yea a lot of compilers don't ignore them -- like MSVC. The root of the problem is that C++ defines that specialized templates should inherit the generic template's prototype, and simply specialize it. But with modern compilers it is easier to just handle them as individual prototype defines.
... and the whole use of "static" on templates is iffy anyway. I add it out of habit but afaik it doesn't really do anything. Templates have odd module scoping rules. They inline by default and junk.

Revision 2225

Apply proper qualifier use for operator+= templates and their specializations.
arcum42
Unfortunately, now the linkers getting in on the action:
./.objs/devel/gui/AppMain.o: In function `void operator+=<pxStaticText>(wxSizer&, pxWindowAndFlags<pxStaticText> const&)':
AppMain.cpp:(.text+0x2c40): multiple definition of `void operator+=<pxStaticText>(wxSizer&, pxWindowAndFlags<pxStaticText> const&)'
./.objs/devel/gui/AppInit.o:AppInit.cpp:(.text+0x2e80): first defined here
./.objs/devel/gui/AppMain.o: In function `void operator+=<pxCheckBox>(wxSizer&, pxWindowAndFlags<pxCheckBox> const&)':
AppMain.cpp:(.text+0x2c70): multiple definition of `void operator+=<pxCheckBox>(wxSizer&, pxWindowAndFlags<pxCheckBox> const&)'
./.objs/devel/gui/AppInit.o:AppInit.cpp:(.text+0x2eb0): first defined here
./.objs/devel/gui/Dialogs/AboutBoxDialog.o: In function `void operator+=<pxStaticText>(wxSizer&, pxWindowAndFlags<pxStaticText> const&)':
AboutBoxDialog.cpp:(.text+0x230): multiple definition of `void operator+=<pxStaticText>(wxSizer&, pxWindowAndFlags<pxStaticText> const&)'
./.objs/devel/gui/AppInit.o:AppInit.cpp:(.text+0x2e80): first defined here
... ad infinum ...
Jake.Stine
oh, stupid gcc. It doesn't even do what it says it does.
Zeydl...
Sorry, you define:
template<>
void operator+=( wxSizer& target, const pxWindowAndFlags<pxCheckBox>& src )
and
template< typename WinType >
void operator+=( wxSizer& target, const pxWindowAndFlags<WinType>& src )
At the same time? Is it correct code?
sudonim1
It's correct, the pxCheckBox definition is a template specialisation and overrides the general definition for that type alone.

Revision 2226

thought 'inline' would be unnecessary with the removal of 'static' on the main
template prototypes. I was wrong. But hey, what do you expect from the C++
standards committee, who's "issues" forum is a single huge 1mb html file.
arcum42
Yep. People with too much time on their hands, sitting around arguing about things like the meaning of the word "depreciation". I'll admit, I really hate trying to wade through anything by them...
Wagnar...
Just wanted to say Thanks for all the effort Jake and the others have put in the WXgui. Its almost fully working :)
And to follow google code rules for commenting, +1 to this rev, it fix windows compile :P
Jake.Stine
and you know, some 75% of the evilness of templates and prototyping in general could be eliminated if C++ simply adopted a multipass parser option that compiles an entire program as a single code conglomeration.
There's honestly no reason not to, and it's actually be a lot faster and use less resources. I mean these days crap like Boost intentionally try to include *everything* into headers anyway, which causes the compiler to have to parse and compile a million lines of code into every file ANYWAY. So you end up with a project with 40 files, effectively compiling ~40 million lines of code + 3500 lines of the actual project. It'd be way better off just compiling it all as a single big stream of code.
RebelliousX
^ Hopefully most of these issues will be solved when C++0x gets finalized soon.
Jake.Stine
>> ^ Hopefully most of these issues will be solved when C++0x gets finalized soon.
... except it'll take GCC at least 6 months to get compilant, and Microsoft possibly 12-18. >_<
arcum42
One good thing about gcc is we know how close they are to being C++0x compliant, as it's on their website.
http://gcc.gnu.org/projects/cxx0x.html
In fact, anything listed there, we could turn on now[1], except that we'd have to wait for Microsoft anyways...
[1] Though for some of it, we'd have to switch to svn versions of gcc, since 4.5 isn't out yet.

Revision 2227

Added some more convenience operators for wx interface construction. These are
intended as a substitute for wxSizerFlags(), like so:
*target += control | wxSizerFlags().Expand().Centre()
// becomes:
*target += control | pxExpand | pxCentre;
Jake.Stine
I'm not totally done with these yet. Ultimately I think I'll try and replace the pxSizerFlags accessors with them also.
Also, I'm not sure if it should use the | operator, or use another operator. It's easy enough to change that anyway. Feedback welcome.
Finally: I tried to do the direct wxString-to-pxStaticText conversion, but can't make it work without removing the convenient sizer flags system (which is certainly worth more than a text shortcut). So I added a couple helpers instead to abbreviate it:
*this += StaticText(_("Mess!"));
A bit more compact that way at least.
powerzx78
I did not want to start a new issue, so I will ask here.
Is it normal that the state (on/off) of radio buttons in GS/Video tab is not changing and is not saved?
Or have i missed something?
ramapcsx2
Did you read the fat warning on first startup of your svn build?
The one that says pcsx2/wx is incomplete yet?
arcum42
Just to mention; we're back to linker issues, this time with |.
./.objs/devel/RecoverySystem.o: In function `operator|(wxSizerFlags const&, pxStretchType)':
RecoverySystem.cpp:(.text+0xfa0): multiple definition of `operator|(wxSizerFlags const&, pxStretchType)'
./.objs/devel/LnxKeyCodes.o:LnxKeyCodes.cpp:(.text+0x3a0): first defined here
./.objs/devel/RecoverySystem.o: In function `operator|(wxSizerFlags const&, pxAlignmentType)':
RecoverySystem.cpp:(.text+0xff0): multiple definition of `operator|(wxSizerFlags const&, pxAlignmentType)'
./.objs/devel/LnxKeyCodes.o:LnxKeyCodes.cpp:(.text+0x3f0): first defined here

Revision 2228

Fix broken dialog box labels from last night's commit.
Add a note to the Video Panel that it DOES NOT WORK YET. ;)

Revision 2229

* Fixed some bugs in the SYSTEM.CNF loader (most notably it will not crash on
files over 512 bytes -- some PS2 images pad their system.cnf to 32k)
* Botting NoDisc with "Skip BIOS" enabled should work now (untested).
* Renamed StaticText / StaticHeading helpers to simply Text and Heading.
* Made the iR5900 recompiler's stack alignment check a dynamic toggle instead
of a dev/debug build preprocessor.
* Fix annoying linux linker errors.
Autor...
Jak and Dexter Lost Frontier has 32kb SYSTEM.cnf< but still doen't booting

Revision 2230

(experimental) Partial implementation of a new model MTGS. Current features:
* Optimized switch() for dispatching ringbuffer commands (slight speedup
maybe, in very GPU intensive apps)
* Removed 8-frame queue (fixes lag when using vsync + fullscreen). New queue
is 2 frames max.
* Restart the ring buffer on every other vsync, regardless of ringbuffer fill
status (re-uses front portion of the ringbuffer more often, which should improve
L2 cache performance nicely).
Planned features:
* A few m_WritePos threshold checks: Need to implement smart logic for putting
the EE thread to sleep when the MTGS ring buffer is lagging (readpos is way
behind writepos), and should restart ringbuffer every frame if frames have large
amounts of data.
* Add periodic EE wakeup commands, or an EE wakeup threshold point to the
Ringbuffer; to signal a sleeping EE that the ringbuffer is nearing completion
and is ready for more data.
Jake.Stine
Ok for some reason the MTGS is now rendering interlace games as progressive scan. I'm assuming the CSR write is not working as it should since I checked the vsync code and it's definitely performing correctly.
but I have to sleep so a fil will wait until later.
ustve...
why negative Jake?
jfre1...
"Ok for some reason the MTGS is now rendering interlace games as progressive scan. I'm assuming the CSR write is not working as it should since I checked the vsync code and it's definitely performing correctly."
That would be why.
poisiono...
-> ustveter: I believe he just stated why above.
But you did not regarding your + though ;)
Anyways, kudos for the frame-queue adjustment, even if the interlace->progressive is not done yet, vsync works better with 2.
Have a nice sleep, and good work (as usual).
Xeli...
* Removed 8-frame queue (fixes lag when using vsync + fullscreen). New queue is 2 frames max.
This is a big one for me, thanks a lot Jake. When are you anticipating completion of the new MTGS model?
wespipe...
I'm sure it's a good start and something that needs to get done. For now though, ssx world tour, soul caliber 3,crisis zone,wipeout (that I've noticed) crash after trying to enter gameplay. Seeing halo graphics also in games like Nfl blitz 2003 and Crash Bandicoot Wrath of Cortex. I know it's WIP, but still doesnt hurt to report maybe. Again though, very good start, I'm just looking forward to things getting a bit back to normal soon.I'll stick with the revision from a few back for awhile I guess. :)
nexxus86
don't know if its this revision, but FFX-2 crash at the beginning, right before the first battle begins.
just before that, i noticed some weird screen flashes.

Revision 2231

Remove the old cpuid gcc hack. Work on IsoFileFormats a bit more.

Revision 2232

Stop the crash in cdvd detection when system.cnf is too big. Probably not the
best way to implement it but it should work.
tom.mat...
Rev. after 2227 break some games like SOTET. There is a graphical screen-flickering. Maybe because of the new (experimental) mtgs system introduced in 2030.
Its a PCSX2-Bug, not a plugin-bug.
ramapcsx2
MTGS error, it's know and it'll get fixed.
This is the wrong revision to report this though.
Autor...
Fixes Jak and Dexter The lost Frontier *now goes ingame and look's like playable
+10000 thanks
marius.i...
I can also confirm this fixes issues with the bigger system.cnf files, included jak and dexter. Awesome fix! :) Might want to look into it a little more, like gigaherz said, its a fix, but it could be fixed in a better way :)
Jake.Stine
Oh I forgot we have the system.cnf code duplicated in two places. we really need to fix that.
cottonvibes
i liked the old comment that said "if the file is longer... it should be shorter"
lol
anbublac...
dude like totally email me this r2232 thing as i too have jak and daxter the
lost frontier and am also having that system is to big problem. [email protected], i like totally can't seem to find a download
link for it. help is greatly appreciated.
gigaherz
This is an ancient revision now. All these changes are included in the 0.9.7 release.
anbublac...
i have 0.9.7 and it still has Stop crash in cdvd detection when system.cnf is too big. i don't know what to do tryed rebuilding the iso well
still am trying, jak and daxter the lost frontier certnly is proving
a challange to get working.

Revision 2233

Catch it if someone hands us a PS1 disc.
arcum42
It wouldn't load it, but this way the error message is appropriate.
jfre1...
Is ps1 game loading ever going to be added? or will that forever be a "go use a ps1 emulator" response.
Looking at it from a ps2 emulation perspective of what the actual ps2 does.
ntcong.it
It'll happen sometimes, but Ps1 emulation is not in the priority(_queue)
arcum42
It isn't really planned, on the one hand. On the other hand, we're trying to have it emulate a ps2 as well as possible, and a ps2 can run ps1 games.
However, it's preferable for the emulator to tell you right up front that the reason it's not loading is because you were trying to run a ps1 game, rather then giving you errors like "File Not Found", or "Elf file does not exist!".
If you want to see what happens with a ps1 game, though, in Elfheader.cpp, comment out lines 537 and 538, and change 540 to:
if( !filename.StartsWith( L"cdrom:" ) && !filename.StartsWith( L"cdrom0:" ) && !filename.StartsWith( L"cdrom1:" ) )
I tested that before putting in the exception, out of curiosity, as I had a few ps1 games lying around...
arcum42
Oh, and part of why I put this in was to document that that is what is passed by a ps1 game, so that if we *do* add ps1 support in, and have to do something special for loading their elf files, we know where to put the code...

Revision 2234

Some preliminary work for improving multithread recoverability and deadlock
handling. (not really doing much useful yet)

Revision 2235

Let's fix some major instabilities in the new MTGS design, shall we. :)
If this rev is nice and stable then I'll go ahead and break things again by
implementing the planned synchronization speedups. ;)
RebelliousX
I read somewhere that atomic operation provide great performance and
synchronization between threads, (It's not like I know everything about them!)
but definitely the use of mutexes/semaphores is easier and slower..
Don't know if pcsx2 will benefit from that (i.e., when supporting
quad cores), but yet implementing them could be bloody hell.. :/
Jake.Stine
>> I read somewhere that atomic operation provide great performance and
synchronization between threads, (It's not like I know everything about them!) but definitely the use of mutexes/semaphores is easier and slower..
I use atomic operations where appropriate.
Truth is, atomic operations are the 'easy' way to write thread sync. They aren't a pain at all. And they are actually typically slower than semaphores because they do not sleep threads when there is no work to be done. Also, Mutexes are, 95% of the time, simple atomic operations internally, with a thread sleep mechanism if the mutex is locked by another thread. Semaphores are typically a pair of atomic operations internally, plus a thread sleeping mechanism when no work is queued.
Atomic operations are what I usually call aggressive spinwaits, since that's what they do. They aggressively spin on a variable, until the status changes. In most cases they're a cheap and eays way to watch your CPU go to 100% usage, and your heat ratings go to 60-70c, while getting no real performance benefit. Only in rare threading cases are pure atomic operations more efficient than mutexes and semaphores, and usually they are still best used in conjunction with mutexes and semaphores, so that threads are only aggressively polling variables during the specific times when the variables are most likely to change.
And yes I know there are lots of sources on the web that think they're a great idea. There are also lots of sources on the web that think Windows98 had a 60ms kernel timeslice (utter BS), and other sources that think setting thread priority levels is good and using Sleep() is bad (also a load of cow dung).
Furthermore, the EEcore has until now used atomic ops to synchronize with the MTGS, which is now causing many problems in the new GUI because it aggressively blocks the GUI thread from being able to respond to user input, even when there is nothing to be done. I'm thus in the process of removing them and replacing them with intelligent use of semaphores, so that the EEcore will sleep when there is clearly a backlog of GS data needing to be processed.
>> (It's not like I know everything about them!)
I could make a funny comment here, but I guess there's no constructive point to that.
Jake.Stine
@rama: btw you were right. The progressive scan thing was just bad thread sync. The write positions were leapfrogging the read positions, and skipping large chunks of data.
RebelliousX
//I could make a funny comment here, but I guess there's no constructive point to that.////
pardon my ignorance, the matter of fact my humble knowledge of thread programming is because I never really did a useful threaded programs, besides small examples to test deadlocks..
And the reason why I mentioned atomic operations is to use the shared memory between threads for reading/writing, using lock/wait free algorithms. but you have a good point here, I can't deny that.
Jake.Stine
>> And the reason why I mentioned atomic operations is to use the shared memory between threads for reading/writing, using lock/wait free algorithms. but you have a good point here, I can't deny that.
Eh, well that's the whole conceptual design of the MTGS ringbuffer, as conceived by Zerofrog back in 2005. The write position to the buffer (EEcore thread side) moves independently of the read position (MTGS thread side). Under most "balanced load" scenarios there are virtually no locks or waits. Things only lock or wait when one side or the other gets way ahead (ie, way out of sync).
(... which admittedly happens about 60-75% of the time in most games -- but it's still a nice speedup ;)

Revision 2236

Attack of the non-POD type objects.
Jake.Stine
I do wish MSVC had a similar warning.
arcum42
I'll admit, I'm glad to see a warning about it, rather then just have the program crash when the code is executed. It's an easy mistake to make, otherwise, with all these wxStrings floating around.

Revision 2237

Hacked in a working synchronized MTGS option in the Video panel (it's the only
option that actually works at the moment). For debugging purposes.

Revision 2238

* Added toggles for game log output: EE StdOut, EE Deci2, and IOP StdOut.
Toggles are provided via a menu in the Console Log.
Dev notes:
* Renamed MtgsthreadObject to SysMtgsThread (matches naming pattern of other
thread classes).
* Added accessors for GetMtgs() and GetCoreThread() [rationale for them
documented in source comments]
* Removed wxHelpers namespace since we're using px name prefix instead for most
stuff.
Jake.Stine
I think, the only thing left that prevents the core emulation unit of PCSX2 from being separated from the User Interface is a couple references to the configuration folders in g_Conf.
heatbla...
I know you`ll yell, but I`ve tested Castlevania: Cures of Darkness, if using the Default VU it breaks the graphics, when using legacy VU it`s normal. Just to know that if nobody had reported it :"D

Revision 2239

Remove wxHelpers.h from the codeblocks project. Add a define determining if
pcsx2 tries to load PS1 games or not.
arcum42
The define is just for development purposes. Currently, if you uncomment it and try to load a ps1 game, it'll tell you the Elf header is corrupt.
(Which is actually an improvement. I changed it so it actually knows that 'cdrom:' is loadable, which wasn't in there previously.)

Revision 2240

And another SIF timing fix.
ramapcsx2
Just hope it doesn't break Mana Khemia (can someone test? :p ).
leomar....
Thanks ramapcsx2
can you make a new version of legacy gui? i have speed problems with another one to play Jak and Daxter - the lost frontier, but the old legacy gui do not suport SYSTEM.CNF 32 k, I would been very thankful
sorry by my bad english :P
arcum42
I'm able to get outside on Mana Khemia, so we're probably good.

Revision 2241

GSdx:
- Remove the silly upscale hacks from an earlier commit
- Replace them with a less silly version in CreateSource() :p
- Remove a few of the outer pixels from the visible area, as they often contain
glitches
shadowladyngemu
Pretty nice looking for those small glitches.
shadowladyngemu
Hmm, seems it costs a little in sharpness tho.
ramapcsx2
That's probably a game that layers several copies of the same output to brighten itself up. If the layers don't match up a 100%, it's going to get blurry (sometimes even a wanted effect).
Try setting a different scale multiplier, that could fix it :)
shadowladyngemu
Gonna try the different scale but it was in all games :P

Revision 2242

Added AtomicBitTestAndReset() to thread tools and added a Normalize helper to
'Path' namespace.

Revision 2243

MTGS Optimization! Implemented EEcore thread sleeping and signaling. [as always:
MTGS changes are experimental, and need testing to isolate potential thread sync
bugs, which are usually quite random in nature]
Important Notes: I designed the new MTGS to largely favor speed on GS intensive
scenes, at the possible cost of some speed loss on scenes that do very little GS
work (simple boring menus, mostly). The idea is that losing 5-10% on a menu
screen that already runs *really* fast is a valid trade off for possibly gaining
a few FPS for in-game scenes (especially slow ones that need it most). So don't
benchmark this thing on game menus and expect it to be faster.
The new MTGS also has several other benefits that do not currently reflect well
in benchmarking:
* It renders only two frames ahead instead of 8. This is great for fixing
laggy input problems, but bad for benchmarking. If the new MTGS manages the
same speed while having lost the queued frames count, it's a sizable
achievement.
* It works a lot nicer with the GSdx software rasterizer in general.
* It's new design will work nicer with future DX11 multithreaded features, when
supported.
arcum42
Observations on the Linux side:
"MTGS Synchronization Error -- Premature stoppage detected on ringbutter restart." spams a lot. Usually a dozen or so at a time.
Final Fantasy X (US) now freezes partway through the initial video when you start a new game. Trying to suspend pcsx2 tells you that the threads are deadlocked, and asks if you want to cancel. (Of course, we've had to make special allowances for FFX videos before...)
Oh, and "ringbutter"? ^_^
arcum42
The spamming tends to be near the start of games, and new scenes, btw.
Forcing synchronization does not affect the ffx freeze, btw. Having it display when the ringbuffer restarts does, presumably because it spams often enough to change the timing...
ramapcsx2
Same thing on the windows side.
Mtgs is very unstable again, so games like xs2 or sotc kill it on the spot.
This was to be expected though, I guess :p
Xeli...
Always glad to see commits like this.
Also, speaking of the vsync and input lag issue, has vsync been moved to a key-binding like the frame limitter. I can't get it working for the life of me.
danialho...
Seems the latest SVN builds won't even boot the bios, let alone games unless running the EE in interpreter.

Revision 2244

Change an assert not to be fatal, to prevent a few games from dying if skipping
the bios in dev mode.
arcum42
Xenosaga I, for example.

Revision 2245

MTGS sync bugfix, and remove some console spam caused by a last sectond addition
to my prev commit.

Revision 2246

MTGS sync fixes (thanks XS2, for being such an MTGS bitch)

Revision 2247

Couple more MTGS sync fixes, and some final optimizations.

Revision 2248

GSdx:
- Removed the outer pixel cropping, it causes blur in some games. (I knew I
should've done it elsewhere :p )
maurizio...
hi , please could you add X1.5 rescaling of native resolution ? i am having strange blurring on the front layer of front mission 5
alejandr...
Shame because that line on borders is annoying, but oh well prefer the not blurry part :P
ramapcsx2
maurizio.pianta:
I have a gs dump of that game, and it seems to use blur layers.
Having it look sharp is a matter of luck I'm afraid.
My gs dump is fine with x3 or x4 scaling though, so try that :)
maurizio...
i am fear that my GS7600 would not help me doing that :-)
PS: in software mode all is sharp and clean
bharav...
Maybe, it's better to make this as additional option? Just to let people find for themselves what games need it.
ramapcsx2
Nah, this one is (should be) enabled all the time really.
The idea is that 1 or 2 cropped pixels won't ever be noticed missing anyway.
(Remember that these games are made to be viewed on television sets, which often crop like 10 or more pixels :p )

Revision 2249

GSdx: Turn of the spam :p
shadowladyngemu
Yay, hate the spam :p
leomar....
Thanks ramapcsx2 !!!
But it would be possible you do a new version legacy, the old version is not compatible with system.cnf 32K, thanks again!
I wait anxiously

Revision 2250

More MTGS optimizations.
tatsuy...
Hmm AceCombat 4 still has inverted like colors at intro and in game in SW or HW mode and with both DX 9 and 10. SW mode seems like it sped up a little since the MTGS optimizations, nice job.

Revision 2251

User Interfacing:
* Added bold text to indicate default options on CPU settings panels.
* Hitting 'Restore Defaults' activates the Apply button.
* Fixed some missing confirmation dialog text.
* More conversions of interface code to use the new += and | operators.
ramapcsx2
Nice :)
Jake.Stine
I couldn't find anything besides the default buttons that didn't activate the Apply buttons.
Jake.Stine
Also, I tried to change the color of the text for the default radio button entries, but wxWidgets has a (known) bug that causes setting the text color on control labels to be ignored on Win32. So I had to opt for boldness. (italics looked totally lame).
The color might actually work in GTK under Linux, I didn't check yet.
132Mi...
hey, i see that your a good developer jake :D i was wondering if you can make a patch or a fix for bleach battlers 2 ? The video of characters ban-kai (main power) freezes the emulator (all revisions), so if there was a patch to skip them it would be amazing :D i didnt know where else to ask... so thank you :D
arcum42
They are, in fact, green in Linux...
Wagnar...
@132Mikle
The problem you have having is similar to the God Of War video Freezing problem.
I have Bleach game too and God of war game so that's why I can tell.
And please in the future don't use the comment on revision to tell an issue.
TO conform by the rules, Nice job jake on this commit. And thank for the info about the "auto apply" when we hit restore default.
Jake.Stine
>> They are, in fact, green in Linux...
Well isn't linux the clever one... :p
Feel free to tweak the color if you think it'd be better as something else. I couldn't exactly "see" what I was setting. >_<
ramapcsx2
Getting the defaults in green here as well :p
About the game bug report, this is indeed not the place for them.
Please file an issue for this (if there isn't one already).
But generally saying, this is the kind of bugs we'd *love* to fix, and
we'd long fixed it if it was simple..
Jake.Stine
>> Getting the defaults in green here as well :p
Good then you too can be in charge of colorizing things in the gui. :p
ramapcsx2
Awesome! :p
132Mi...
i'm sorry, didnt know where to post the bug report... thanks anyway :D

Revision 2252

Added a "Screenshot" button to the Settings window; it saves a screenshot of the
settings to png file. :) It's just preliminary for now. I'll replace it with
an artsy icon later, hopefully. :)
Cleaned up the operator overloads some more, and added operator, (yes, comma)
to solve some ambiguity problems when trying to apply multiple attributes to a
single window.
david.jennes
That's ... actually a really good idea, loads of people post ss of their configs anyway. Does it also take a 'ss' of the other settings (such as graphics and such)? Or is that up to each plugin to add such functionality?
Zeydl...
Uncompilable:
/home/ruslan/pcsx2-new/common/src/Utilities/wxHelpers.cpp:111: error: ‘s_littles’ was not declared in this scope
Jake.Stine
I got the idea from GPU-Z.

Revision 2253

* Improve GUI responsiveness while doing things like enumerating/loading
plugins.
* ConsoleLogger Optimization: Improved performance considerably for when the log
gets spammed by EEcore or MTGS threads.
DevNotes:
* Added a new pxYieldToMain() method (currently implemented in Win32 only). It
provides a smart way to allow passive-task worker threads to yield time to the
Main Thread when important messages are pending (keyboard or mouse clicks,
primarily). It also replaces the wxGetApp().Ping() stuff, which never worked
anyway due to wxCommandEvents having a higher priority than native system
messages.
arcum42
Notes:
The way you normally obtain the message status in Gtk is gtk_events_pending, which is also what wxEventLoop::Pending() uses. Not sure as far as thread safety goes.
( I have worked on a program that was using:
while (gtk_events_pending()) gtk_main_iteration();
but all the gtk calls were in one thread.)
Also, do we need GetOSVersionString()? Wouldn't wxGetOsDescription() suffice if we need an OS version?
maurizio...
it Stop to compile , builded a clean solution this is the result
http://www.fileshost.com/download.php?id=7DC56D811
maurizio...
------ Build started: Project: Utilities, Configuration: Release Win32 ------
Compiling...
WinMisc.cpp
..\..\src\Utilities\Windows\WinMisc.cpp(121) : error C2065: 'VER_SUITE_WH_SERVER' : undeclared identifier
Build log was saved at "file://c:\Development\Project Source\PCSX2\common\build\Utilities\Win32\Release\BuildLog.htm"
Utilities - 1 error(s), 0 warning(s)
maurizio...
is not defined in any include
121
+
else if ( osvi.wSuiteMask==VER_SUITE_WH_SERVER )
122
+
retval += L"Windows Home Server";
Wagnar...
I confirm:
9>..\..\src\Utilities\Windows\WinMisc.cpp(121) : error C2065: 'VER_SUITE_WH_SERVER' : undeclared identifier
pcsx2gu...
Seriously people if it doesn't compile, give it a -1 so the devs know! See Jake made 2 more commits and he still doesn't know.
Can't compile either, so -1
Wagnar...
Wasn't sure if it was "ok" to -1 because it doesn't compile.
I'll -1 now if a commit is not compiling sucessfully.
Thanks for letting us know.
Jake.Stine
>> Also, do we need GetOSVersionString()? Wouldn't wxGetOsDescription() suffice if we need an OS version?
For windows yes. I didn't realize there was a wx version util function, but I checked it out and it uses GetVersionEx, which is specifically *not* what I want. GetVersionEx returns the version specified by Windows "compatibility" modes, which simply fake version numbers as 5.2 or 5.3. To get the real version information you need to use GetNativeSystemInfo or VerifyVersionInfo.
Also, with the introduction of Vista and, especially, Windows 7, there are tons of various packages of windows and every one has different components (DLLs) and sometimes other differences. So it's nice to know both the version and the package.
So for now I'll leave it in for windows, but the linux side can just go ahead and use wx's.

Revision 2254

Turn an ugly snapshot button into a pretty one!

Revision 2255

Fix up Linux again.

Revision 2256

* Fix Issue 488 - FPU Full mode was being ignored.
* Slightly smaller and brighter camera icon.
heatbla...
This is some revision indeed! Steambot Chronicles - WORKS!The graphical vertical glitches still remain, but the speed is better and... it works! But there was a tweak - I had to disable the BIOS SKIP HACK...otherwise it crashed... But another big " + " from me!
azte...
always nice to see issues getting fixed, more games working well. :)
heatbla...
Btw... I have a question: have you tried the game Erementar Gerad? It gives me a black screen in GSDX Hardware, in GSDX it is normal but slow ~ 30 fpses. In the recent rev it shows the movie in the begining and when I press start the image flickers and remains but the start screen and the character sleect screen are not visible, but there is a sound of the cursor moving and further the fighting....? I`ll try to shot it the next time to show it.

Revision 2257

Remove Windows Vista/7 SDK requirement for compiling.
Jake.Stine
If there are still compilation errors please note them here, thanks.
maxzag...
It's nothing really, but the return description in LnxMisc.cpp has a typo: "shoul" --> "should"
Thanks!
jfre1...
I was getting 63 errors 2 revisions ago. In this one I get: 0. Good work :).
jfre1...
Emulator crashes if skip bios is selected with Arc the Lad
jfre1...
Didn`t happen on earlier revisions I tested, I`ll add

Revision 2258

Various tag stuff.
arcum42
Basically, I changed a bunch of things to boolean, revised the helper functions and added them to some structures that didn't have them.
Oh, and I changed:
vif1Regs->stat._u32 = (vif1Regs->stat._u32 & ~VIF1_STAT_FDR) | (value & VIF1_STAT_FDR);
to
vif1Regs->stat.FDR = (value & VIF1_STAT_FDR);
Same basic idea; just setting one byte instead of the whole thing.
And I fixed Linux; there was a missing include.
arcum42
Er, bit, not byte.
tatsuy...
Nothing is working, not even the bios displays. Every game sits at a grey screen before anything is shown.
arcum42
All right, reproduced. I'll either fix it or revert shortly. I hate it when things work properly on Linux, but don't on Windows. :(
arcum42
r2260 should take care of it.

Revision 2259

Expand the system.map symbol table string length from 32 to 64 chars (fixes
debug assertion in Silent Scope 3); and other minor code comments added.
wespipe...
I can't launch a thing with Linuz plugin now. :( No graphics, no messages....just hangs there.
Are there plans to have the built in ISO loader support compressed formats - like Linuz's plugin does? That's the only reason I still use it over the built in one.
wespipe...
Same issue for the built in ISO loader...I can't play anything now. Something has gone horribly wrong!! :)
arcum42
It'll be fixed shortly...
arcum42
It's taken care of in r2260.

Revision 2260

I'm not trying that again anytime soon...
tatsuy...
Fixed emulator hang with windows (r2258).
Jake.Stine
Yeah on MSVC when you mix types (bool and u32) it creates new bitpacking boundaries, since they're different fundamental types (bool is u8, u32 is not ;). So the u32 would align itself to the next 32 bit boundary and continue :1's from there.
That's unfortunately one of the "undefined" aspects of bitfields, so compilers are allowed to do whatever they choose. So the rule of thumb is to always use 'u32' when using bitfields that mimic hardware registers (where exact bit alignments are needed).
I think I use bools and u32 mixed sometimes in certain configuration structs, but those don't really care how they're laid out in memory so it's not a problem.
arcum42
Yeah, I saw the bools in one of those constructs; that's what gave me the idea. And it worked perfectly with gcc, of course, otherwise I wouldn't have committed it.
OTOH, I had a pretty good idea that it was an alignment issue once there was a report that it wasn't working, since I had thought about that at one point, and then forgot about it when it worked.
Oh well, at least both compilers don't mind my passing true and false to the fields, even if they're back to u32:1's. And I was able to keep the adjustments I made to the helper functions, and that change in VifDma, so some good came out of the commit.
Though, I'll admit I do feel like the helper functions should be abstracted somewhat, so they aren't repeated all over the place...
Jake.Stine
Helper functions can only be consolidated as macros, since using struct inheritance would cause the values to become non-POD (which means their internal layout is undefined at that point, and individual compilers are free to lay things out however they see fit).
arcum42
Yeah, I'll stick with just being repetitive for the moment. If the collection grows much more, I might go ahead and use macros, though. At least I don't really see them growing too much more, or if they do, it'll be functions individual to the struct.
I might move some of the code left in Tags.h there, for example.
Though one thing I was thinking about doing was giving them all a function that returns a nicely formatted string with their value in it, for use in logging...
Jake.Stine
>> Though one thing I was thinking about doing was giving them all a function that returns a nicely formatted string with their value in it, for use in logging...
Yeah that would be nice.

Revision 2261

Change the return values on some Vif functions.
arcum42
Basically, I untangled these functions enough to figure out that they didn't actually need to know if the return value was -1 or -2, for example, just if it was zero or negative.
In fact, a few of the ones I changed to bool could have been changed to void. I decided not to go that far, though, just in case.
bigdeak
Well then, refactoring is mostly good.
If you can be sure, that the functions caller really don't need to know a specific return value, then it helps to increase the emulator more and more :)
ramapcsx2
There's a small issue here:
if (_VIF0chain() == -2)
12>..\..\Vif0Dma.cpp(651) : warning C4806: '==' : unsafe operation: no value of type 'bool' promoted to type 'int' can equal the given constant
arcum42
Must have missed one. I'll take a look.
arcum42
All right, looks like I can safely change it to
if(!_VIF0chain())
The function it was returning only returned -2 or 0.
arcum42
There, took care of it in r2262. And, you know, I recall checking to make sure that statement wasn't going to be a problem when I started this, too. I must have just forgot to change it.
ramapcsx2
That was fast :)
arcum42
Well, my local copy of the trunk was in an easily committable state, I was at my computer, and I was already pretty familiar with that area of the code, so I was able to get it out quickly...

Revision 2262

Fix a if statement I missed in the last commit, and add in a couple functions
for printing structs.
Jake.Stine
Bleh, never mind. I'm so used to using printf syntax, I forget to even notice +'s in console writes. -_-

Revision 2263

Signed/Unsigned bug introduced from r2217 squashed (fixes Issue 483 : Extreme G3
crash); also added some more complete filesystem partition detection and logging
to IsoFS.
Jake.Stine
The lone change to VIF was something I noticed where the integer result of the r-value was a full range int, while the lvalue was a bitfield. The rvalue would have been masked and truncated to 0. The code in question is for logging in devbuilds only anyway (in what seems like a hacky fashion but oh well), so it wouldn't have broken anything.

Revision 2264

Layer break detection improved -- might fix GoW and Rogue Galaxy layer break
problems; and added a layer break cache so that layer breaks need only be
searched for once. Layer break info is saved to LayerBreakCache.ini.
The old layer break detection method assumed layer1 was never longer than
layer0, but layer1 is in fact the longer layer on aforementioned games.
pcsx2gu...
Finally fixed God of War layer change at Pandora's Bridge crash :) Great job!
kprajapa...
Can anyone tell me how to use these attached files...
I am getting same problem....

Revision 2265

* Cdvd Layer break cache uses hashed strings instead of the literal filename.
* Minor fix to cdvd layer break console log.
(and yes it's confirmed, this fixes GoW and Rogue Galaxy layer break freezes!)
darrenk...
I was really hoping this commit would fix this huge bug:
https://code.google.com/p/pcsx2/issues/detail?id=23&colspec=ID
...but I've tested and confirmed it hasn't.
pcsx2gu...
How could layer breaks have anything to do with that freeze? That freeze occurs like 15 minutes ingame so it has nothing to do with layer breaks.
darrenk...
Sorry, I was mistaken - I had assumed the layer break was associated with the bridge sequence at the end of the game. Currently the game cannot be finished without some fix to that issue, but apparently this has nothing to do with it.
powerzx78
This revison does not fix God of War (Pal) freeze at titan's bridge.
pcsx2gu...
As far as I remember, that is a cutscene with a video. Thus, nothing to do with layer breaks either, but the known bug with videos of God of War.
Also a revision NOT fixing something should NOT have negative feedback, since it fixes other things and doesn't break anything.
powerzx78
@pcsx2guide
Why my feedback was negative? Because this revision had confirmed, that it fixes problems with GoW, but it is not.
ps. I changed my vote to neutral.
darrenk...
Correction: apparently it *does* fix a GoW problem, just not the one I had originally thought.
powerzx78
@[email protected]
can you tell me which GoW problem it fixes?
pcsx2gu...
https://code.google.com/p/pcsx2/source/detail?r=2264
As I posted there, it fixes the layer change crash at pandora's bridge.

Revision 2266

Layer break search works on an inside->out path now (should be a good bit faster
for most images).
pcsx2gu...
Made layer break discovery time from 18 secs to instant here :)

Revision 2267

Fixed the return result of FStype_ToString, added some missing GPL statements in
a few files, merged a few redundant functions, and such...
arcum42
In case anyone's curious, FStype_ToString was always returning "Unrecognised Code (0x#)". Not that it mattered much, since the WriteLn statement was then truncating it to 'U' when printed. :)
And the redundant functions were MSFtoLSN and LSNtoMSF, btw.
arcum42
Hmmm, looking closely, the array was ordered in reverse in the original version of lsn_to_msf. Suppose I should reorder the array it's put in for the one call that uses it.
Though I have to wonder if it was putting it in the right order to begin with...
Must not make much of a difference, though. Haven't seen anything break.

Revision 2268

Merging LSNtoMSF and lsn_to_msf reversed the order of the results in one spot.
Change the order back.
Jake.Stine
Yeah this would have only broken CDrom games, and possibly only certain ones (and there aren't many to start with -- they all date back to 1999-2001).
arcum42
Yeah, only noticed it because I was reviewing the code I committed, and realized that the values were put in in the opposite order on the newer of the two functions.
I'm still wondering if it was already wrong in one or the other spot, though. Not sure if I actually have any games I could test with on this one, though.
arcum42
Based on this:
http://en.wikipedia.org/wiki/List_of_PlayStation_2_CD-ROM_games
Gradius 5. I do own a copy of it, because I remembered some of the Vif issues with it, and saw a copy in Game Crazy. (Yes, I think of pcsx2 issues when I'm game shopping ^_^).
I'll have to keep it in mind for testing cdrom issues.
pcsx2gu...
I got a couple of CD games arcum, if you need tests let me know in the forum
ramapcsx2
Gradius 5 was indeed broken in earlier revs, I just found out.
Now it seems to work again, but the intro fmv hangs randomly.
I seriously hope this is not sif timing related :p
ramapcsx2
And it is sif timing :/
arcum42
Figures. It gets tempting to make sif timing adjustable in the config dialogs.
And I think I'm fine since I've got Gradius 5. And if I can ever get it to rip, my scratched up copy of AR Max should be cd based, too...
One of these days, I'll have to hunt down Ico, though.
ramapcsx2
Oh, ico is and has always been fine. Never had any issues with it other than the usual stuff.
Also: I'll leave sif alone for now, the fmv hang is indeed random.

Revision 2269

Using the Console Log scrollbars to read back history will automatically
throttle emulation temporarily, until the scrollbar is released.

Revision 2270

GSdx:
- Let's try that pixel cropping again. Hope it doesn't blur ffx this time.
leomar....
Hi there ramapcsx2, how are you? Sorry if I am being boring, but it would be possible you do a new version legacy GUI?
please a need it to play games system.cnf 32k
pcsx2gu...
Hi are you an idiot? What the heck does this have to do with GSdx? Why are you posting a negative in a TOTALLY unrelated commit? Do you realize we use google code to track bugs and not for listening to people whining?
ramapcsx2
Did or did you not just -1 my commit because I didn't yet spent 4 hours diffing pcsx2/legacy with pcsx2/wx JUST so you can play your one game a bit faster?
That's so lame.. :p
trigunflame
*facepalm* x inf
Zeydl...
I not sure that you do a correct thing, some textures are 1 pixel width (height), so you simply invalidate them. From my point of view, correct constants could be 0.5 (half-pixel offset).
shadowladyngemu
Looking great so far, line gone and sharpness is the same as far as I could see in the games I tried.
diego...
This is just great,now upscaling does correctly render the shadows in naruto accel 2
Autor...
diegoNNC how do you able to render shadows in Accel 2, cause i have no shadows
jacol...
great work rama
leomar....
Sorry, but I did not mark as negative, this was already this way, was attention lack, a thousand apologies.
I would have to be a lunatic, to do a request and to put in negative!
Sorry for that mistake
diego...
@ [email protected]
all the characters have some shadows,when doing ougis you can specially noticed them,in the characters cloth for example,after this shadows where like randomly placed and they where like "squares",now there are in the place they must be and the shadows are more "precise"
Intere...
Unfortunately it still blurs FFX for me with this change.
shadowladyngemu
@ [email protected]
What do you mean?
It could be a different blur, have a screenshot where to see it easy?
Intere...
Its very very minuscule but it is still there and quite distracting when going from one revision to another.
I've marked the blurry parts on these screenshots:
r2190 with no blur:
http://i217.photobucket.com/albums/cc135/xavi3n/gsdx_noblur-r2190.jpg
and r2270 with some blur, notice the further away items have a seemingly out-of-focus look to them.
http://i217.photobucket.com/albums/cc135/xavi3n/gsdx_blur-r2270.jpg
its difficult to notice in the screenshots, but overall, in-motion, the image definitely loses some detail.
shadowladyngemu
yep seems like the same problem, does native show the same? should be more noticeable there. Did it happen only on this revision or in r2241 too?
Intere...
native is identical in both revisions (r2190 and r2270), i haven't tried r2241 though.

Revision 2271

Maybe better console log behavior when dragging scrollbars; move some code out
of ConsoleLogger.cpp into new files to reduce clutter and mammoth file size.
DanrleiS...
Frames skip is zero. well done. More work sob effects.
Jake.Stine
... is there a better translation for that? I'm having a hard time determining the meaning. >_<
jfre1...
Maybe his english is bad. He gave it a positive afterall.

Revision 2272

Let's not override WriteText in Linux for the moment.
arcum42
Mainly because gcc couldn't find DoWriteText...
Jake.Stine
Yeah, MSW's RichText control is such a pita. Only thing going for it is that it's really efficient at handling really large scrollback histories. But everything else is incredibly fickle and riddled with potential slowness. -_-
arcum42
Incidentally, I was just glancing around textctrl.h in the Windows and Gtk ports of wxWidgets, and as far as I can tell, DoWriteText is a Windows only function.
The Gtk version of wxTextCtrl::WriteText calls wxTextEntry::WriteText, which calls the gtk functions directly.
I'd figured it was something like that, but wanted to check...
arcum42
Oh, and Gtk has it's own issues. You don't want to know how much time I spent on another program trying to get windows to remember their positions.
Sounds easy. Not with Gtk, though.
Jake.Stine
Yeah! I noticed PCSX2 kinda fails still also. The window always ends up offset +8 pix or so on every restart (basically the size of the titlebar). I kinda got that fixed once, I think... but broke it again later with some changes I made later.
... or that behavior could be dependent on window manager even. Ugh >_<
arcum42
Combination of both, actually. First, I ran into this in the docs, which discouraged me:
"gtk_window_get_position() is not 100% reliable because the X Window System does not specify a way to obtain the geometry of the decorations placed on a window by the window manager. Thus GTK+ is using a 'best guess' that works with most window managers.
Moreover, nearly all window managers are historically broken with respect to their handling of window gravity. So moving a window to its current position as returned by gtk_window_get_position() tends to result in moving the window slightly. Window managers are slowly getting better over time. "
And the best guess at the window decoration wasn't that good for my particular window manager at the time. Spent a good while trying different methods of getting the position of the window before I found that, as I recall, too.
I probably wouldn't have stressed it as much, but the program in question had several windows, usually open at the same time. Usually you'd put them next to each other, and I'd keep opening and closing the program in testing, and then having to pull each window back up.
I need to go back and rewrite that code one of these days, actually. I fiddled with it too much, and I'm also a bit better of a programmer then I was last time I tackled it...
arcum42
Hmmm... First sentence of my comment doesn't make much sense. Overediting... :(
Try:
"It's a combination of both gtk and the windows manager. After playing with it for a while, I found the following information in the docs:"

Revision 2273

Simplified transfers. Removed some extraneous code, and moved some enums to
Dmac.h.
arcum42
And yes,
tag->chcr.TAG = ((*ptag) >> 16);
is the same as:
tag->chcr._u32 = (tag->chcr._u32 & 0xFFFF) | ((*ptag) & 0xFFFF0000);
DanrleiS...
Very well. Frames skip is 0. Bios work good.

Revision 2274

wxWidgets/Win32: Re-introduce wxWidgets resources for blank mouse cursor
(actually never existed in our packaged copy as originally borrowed from
Dolphin).

Revision 2275

Video/GS Window and Panel Options (partly!) implemented:
* Aspect ratio and mouse cursor hiding features should be mostly functional.
* Mouse cursor by default hides after 1.75 seconds of inactivity, when in the
area of the GS window. Can be forced to always hidden in the control panel.
Unlike the liilypad hack, this one won't hide the mouse in the main window or
title bars. (and it should work for Linux too!!)
* GS window position and size should be remembered between sessions.
Console Logger window z-order is now "bound" to the main window. When clicking
either window to bring it to focus, the other window follows (implemented for
Win32 only, since wxWidgets doesn't have a cross-platform implementation of the
necessary SetWindowPos call).
Jake.Stine
Yes I know the GS window has big grey borders when resizing it. That's currently intentional (for troubleshooting purposeS). I'll disable that later.
Also, I need more feedback on GS Window manipulations you guys like to see implemented, besides what's already there and what's outlined in the GS/Video panel.
Erik.O...
It doesn't compile because of the changes made in "pcsx2_2008.vcproj".
Error: 1>..\..\..\3rdparty\wxWidgets\include\wx\msw\wx.rc(23) : fatal error RC1015: cannot open include file 'wx/msw/rcdefs.h'
shadowladyngemu
Good work there, that remember GS position window is useful too :p
Seems that full-screen on GSDx's D3D9 and even with Alt+Enter on D3D10 stopped working for now. I wonder however, with the new gui it would be possible to make alt+enter work for D3D9 too? or is it limitation on the D3D9 part of GSdx itself?
ramapcsx2
No compile errors here, but I noticed lilypad's "windows messaging" input method fails for keyboard again.
Aspect ratio setting works, fullscreen is now blocked somehow (just getting the windows sound when trying alt+enter, just like in DXyesteryear mode :p )
Jake.Stine
Yeah that's all expected too, except Lilypad WM. Probably an issue in Lilypad because I use a sub-window now to manage aspect ratios.
Oxyge...
SetWindowText of GSdx has not worked.
Jake.Stine
>> SetWindowText of GSdx has not worked.
That's because I intentionally disabled it long ago. ;) We have a better info report in mind, just been a matter of finding time and energy to implement.
Erik.O...
>> No compile errors here
Yes, only devel and release mode don't work and are fixed in the next revision. All in all thanks for the good work.

Revision 2276

project file fix for devel and release mode targets

Revision 2277

Lilypad: Implemented full support for child-window GS viewports (fixes windows
messaging being broken from the prev rev).
DevNotes: The main change here was to turn WndProcEater into a class and create
multiple instances of it, so that it could manage the WndProcs for multiple
windows concurrently. The "frame" (top-level window) gets a WndProc that sets
title and handles screensaver/alt-enter hacks. The "viewport" (provided by
PCSX2) gets the usual keyboard input handler WndProc. Config buttons also have
their own WndProc that avoid fuzzy logic conflicts with the other two.
docutu...
recompiled sse3 release , keyboard stop to work , input are not passed to pcsx2
docutu...
PCSX2 0.9.7.r2273 - compiled on Nov 29 2009
Savestate version: 0x8b410003
x86-32 Init:
CPU vendor name = GenuineIntel
FamilyID = d
x86Family = Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
CPU speed = 3.044 ghz
Cores = 2 physical [2 logical]
x86PType = Standard OEM
x86Flags = bfebfbff 0000e39d
x86EFlags = 20100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards
SetLanguage: Cannot find pcsx2main.mo file for language 'Italian' [it_IT]
SetLanguage: Cannot find pcsx2main.mo file for language 'Italian' [it_IT]
DwmEnableMMCSS successful.
Initializing PS2 virtual machine...
Allocating memory for recompilers...
Loading plugins...
Binding GS : C:\Program Files\PcsX 2\plugins\GSdx-SSSE3.dll
Windows 6.0.6000
NVIDIA GeForce 7600 GS (8.17.11.9555)
Binding PAD : C:\Program Files\PcsX 2\plugins\LilyPad.dll
Binding SPU2 : C:\Program Files\PcsX 2\plugins\SPU2-X.dll
Binding CDVD : C:\Program Files\PcsX 2\plugins\CDVDnull.dll
Binding USB : C:\Program Files\PcsX 2\plugins\USBnull.dll
Binding FW : C:\Program Files\PcsX 2\plugins\FWnull.dll
Binding DEV9 : C:\Program Files\PcsX 2\plugins\DEV9null.dll
Plugins loaded successfully.
Initializing plugins...
Init GS
Windows 6.0.6000
NVIDIA GeForce 7600 GS (8.17.11.9555)
Init PAD
Init SPU2
Init CDVD
Init USB
Init FW
Init DEV9
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards\Mcd001.ps2
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards\Mcd002.ps2
Plugins initialized successfully.
Issuing EE/iR5900-32 Recompiler Reset
Bios Version 2.0
Load Bios Warning: rom1 module not found, skipping... (this is not an error)
Load Bios Warning: rom2 module not found, skipping... (this is not an error)
Load Bios Warning: erom module not found, skipping... (this is not an error)
Framelimiter rate updated (UpdateVSyncRate): 59.94 fps
Opening plugins...
Opening GS
Opening PAD
Opening SPU2
Opening CDVD
detected blocksize = 2048
isoOpen: X:\FM5 Originale\FM5 Originale.iso ok
offset = 0
blockofs = 24
blocksize = 2048
blocks = 1913328
type = 2
* CDVD Disk Open: DVD, Single layer or unknown:
* * Track 1: Data (Mode 1) (1913328 sectors)
(IsoFS) Block 0x10: Primary partition info.
Opening USB
Opening FW
Opening DEV9
Plugins opened successfully.
Issuing EE/iR5900-32 Recompiler Reset
(IsoFS) Block 0x10: Primary partition info.
(GetElfName) Detected PS2 Disc = cdrom0:\SLPM_662.05;1
(GetElfName) Software version = 1.01
(GetElfName) Disc region type = NTSC
Executing Bios Stub...
# Initialize memory (rev:3.70, ctm:393Mhz, cpuclk:295Mhz detected)
# Total accessable memory size: 32 MB (B:2:8:0) (370:2:7c30)
# TLB spad=0 kernel=1:12 default=13:30 extended=31:38
# Initialize Start.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# Initialize Done.
EE DECI2 Manager version 0.06 Feb 6 2003 08:38:48
CPUID=2e20, BoardID=0, ROMGEN=2004-0614, 32M
# Restart Without Memory Clear.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize Scratch Pad ...
# Restart Without Memory Clear Done.
Issuing EE/iR5900-32 Recompiler Reset
Execute Bios Stub Complete
loadElfFile: cdrom0:\SLPM_662.05;1
loadElfCRC: cdrom0:\SLPM_662.05;1
(IsoFS) Block 0x10: Primary partition info.
loadElfFile: 2729264 bytes
(IsoFS) Block 0x10: Primary partition info.
found 0 symbols
loadElfFile: cdrom0:\SLPM_662.05;1; CRC = 2615F542
Opening plugins...
Plugins opened successfully.
Jake.Stine
Well considering most forms of keyboard input stopped working in the *previous* revision, I'm not quite sure what to take from this.
Question: What type of lilypad keyboard input do you use? Messaging, Raw, or DirectInput?
docutu...
hi jake i am using windows Messaging and no hack enabled
docutu...
i understand what is happened , i have to set the focus on the gs window clicking on it with the mouse to have input keyboard intercepted

Revision 2278

Lilypad: bugfix for crashes when used with pcsx2 0.9.6
docutu...
recompiled today and keyboard input work again

Revision 2279

GSdx:
* Disable GSdx's internal AspectRatio setting when using GSOpen2 (pcsx2 0.9.7
controls aspect ratios internally now)
* DX10 should be able to startup in fullscreen mode now, without needing to hit
alt-enter (legacy 0.9.6 versions only)
* Added some comments for a failed attempt to disable DX10's default Alt-Enter
behavior. If someone knows how to do that properly, please feel free to submit
a patch because DX10/Com breaks my mind. (see GSDevice10.cpp)
* Remove DX11 for now since it's entirely unfinished anyway.
DanrleiS...
Gs video works good. Fullscreen not suported.
docutu...
GS.cpp
.\GS.cpp(252) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
Compiling...
ramapcsx2
Tested GSopen and GSopen2. GSopen can go into fullscreen at startup now. Alt+Enter works fine.
GSopen2 is unchanged. No fullscreen startup, no alt+enter support.

Revision 2280

Intercept calling the Patch configuration dialog until we actually have one.
arcum42
Prevents a crash on choosing that menu item.

Revision 2281

GSdx: Remove some DXGI stuff, which is being moved to PCSX2.

Revision 2282

Implements support for Alt-Enter fullscreen switching, DX9 only! DX10 is still
broken, will stay that way until some clever person figures out how to make it
work. I've make some comment guidelines in source (see MTGS.cpp).
... also, it's possible DX10 fullscreen will work if bound to, say, Shift-F9
(ie, something beside alt-enter, which DX10 decides to wrangle full unrelenting
control of, without our explicit consent, and needs some 20 lines of random COM
chaos to disable).
ramapcsx2
DX10 works fine as well, as we've just found out.
This is apparently by accident more or less, but we'll gladly take it :p
We have now non-obtrusive, non-crashing windowed/fullscreen support in dx9 and dx10 alike.
This sure took a while, grats.
(2 years iirc! :p )
shadowladyngemu
It's working really great, much better even than the legacy gui handled dx10's alt+enter.
Seems it writes 2x "It's not Alt!" lines in the log when you press any other key than alt in the gs window and 1x on esc :P

Revision 2283

GSdx:
- Re-enable the D3D10_CREATE_DEVICE_SINGLETHREADED flag, since it seems to be
stable again.
Autor...
About GSdx: i tested it a bit, and found that r1439 uses much HW resources *maybe leak maybe smth else, but in MGS3 cpu usage % in 1439 about 20-25% more than 1426, since this game already is heavy it causes fps drops
Jake.Stine
I fixed most of the slowdowns introduced by that rev some weeks ago. So while 1439 might be 20-25% higher than 1426, recent revisions should be like maybe 5-10% higher. (and we already know the new texture caches introduced around that same time are also slower, and probably account for any other speed loss, but they're too much integrated work for anyone besides Gabest to fix).
DanrleiS...
Gsdx : algumas correções fixadas. pulos de fps cada vez menores.
valentin...
hey there!Where can I downland this svn versions that you make or some others?
jfre1...
....
shuaitao...
I found that if I use gsdx dx9 hw mode, the game "Super Robot War Alpha 3' have a z-buffer problem that some layer is always behind another. I tried many way to solve this. finally I found that if I put this line to the 'vs_main' function in file 'tfx.fx', the problem disapeared:
input.p.z = fmod(input.p.z, 0x400000);
I tested 0x10000,0x100000 and 0x800000, it seems 0x400000 is the best value.
I just think if this is a hint to the developers to completely solve the z-buffer problem in gsdx dx9 hw mode.

Revision 2284

Fun little hack for Rama to play with, that should simulate the magic power of
the PEOPS SPU2's "unstuck iop" spell.

Revision 2285

Fix compile errors from last commit.

Revision 2286

Another fix to the hack. Yea. :p

Revision 2287

yay sif hack mess fix

Revision 2288

Stupid SIF hack tricks 101. Class at 11am.
kaboo...
I hope you don't mind me asking ... what is this SIF hack for?
Jake.Stine
It's an attempt to unstuck IOP when it gets hung because of bad SIF timing/handshaking. Relies on the fact that PS2 bios is really pretty robust and will safely recover from horribly incorrect DMA hardware management by PCSX2. It was easier than fixing all of SIF emulation. :p
tatsuy...
No game runs, not even bios, same problem as I posted in r2258.
Wagnar...
Im using build 2282 and it work. so must be you doing something wrong tatsuya.
And removing the -1 and setting to neutral would be wise imo.
wespipe...
I'm with tatsuya. I can't launch anything!! Sorry, gotta go negative here....
Wagnard what are you talking about?? Are you using 2288 or 2282...because you said the latter.
wespipe...
BTW, 2283 worked perfectly.
wespipe...
ACtually, it was 2282. I think 2283 is what broke everything. I deleted my ini folder and started fresh but still I only get a grey window after chosing something to launch. Nothing happens. I can't find a way to get anything to boot.
Jake.Stine
Well then none of that has anything to do with this revision specifically.
Also for what it's worth, I'm doing a lot of hacking around with the GS plugin API in my final push to get things working in prep for an 0.9.7 beta release. If you're mixing and matching GSdx and PCSX2 revisions at this time, expect things to not work as expected or intended.
tatsuy...
No plugins are mixed with 0.9.7, I only mix with legacy GUI.
wespipe...
No mixing here also. Full, clean install of 2283+ is unusable (for me at least).
Jake.Stine
Please try with DX9 and see if the problem goes away.
tatsuy...
No go with DX 9, HW and SW mode.
Jake.Stine
In that case the revision that broke it can't be 2283, since it *only* changed one thing that is specific to DX10. The problem must be with 2282 or earlier somehow.
tatsuy...
r2276 is the latest one I can find that works, tried the GSdx plugin from r2276 with r2288 and still no go.
ramapcsx2
If you compile yourself, check if IOP_ENABLE_SIF_HACK is set to 1.
If someone else compiles, ask him what its set to.
The symptoms you get would happen if it was set to 1.

Revision 2289

A new DMA tag structure.
arcum42
Just thought I'd archive that before I start doing weird things with it and mess up my local copy of the trunk.
na12345....
unfortunately it breaks the following games: tekken 5, tekken 4, vampire night, gran turismo 4, during the bootup.
arcum42
If you looked at the code on this revision, you would notice that the structure I added is entirely unused, as of yet. Therefore, any issues in the current revision come from a previous revision.
na12345....
sorry :)
arcum42
np.
If you notice something's broken on a revision, though, it's best if you test a couple revisions, and narrow down what revision broke it. That way it's a lot easier to figure out what broke...
I can guess from the comments in r2288 that something's broken right now, and since I do have Tekken 4, I may take a quick look and see if I can figure out what revision it broke in...
ramapcsx2
I really support your ongoing effort to make this stuff readable :p
arcum42
Thanks.
I figure that while we can remember or look up magic numbers, it's a lot easier to understand at first glance something like (ptag->ID) rather then ((ptag >> 28) & 7).
And it helps my understanding of the code, too, which is nice...
arcum42
And now I've got this structure actually being used in r2291. ^_^

Revision 2290

Some more warnings enabled by default in devel builds.
It'll be good to know which games trigger these.
DanrleiS...
O emulador não esta funcionando corretamente. Jogo não passa.
arcum42
Just for reference, Ar Tonelico 2 triggers two of these a few times in the intro:
DMA QWC (1000b020) upper 16bits set to 1
DMAExec32 Attempt to run DMA while one is already active mem = 1000b000
If I spot these in other games, I'll mention it...
arcum42
I'm suspecting we'll see that first one in several Gust games, though, since that's right *after* the DMAExec hack point. Not clearing qwcregisters might be what breaks gust games.
arcum42
Just to confirm, quickly looking at the openings, Atelier Iris 3, Mana Khemia, and Mana Khemia 2 have those two warnings; Atelier Iris 1 & 2 don't.
Basically, the ones that have all the "File cache was not hit." warnings also have those two warnings.
arcum42
Oh, and the opening movie for KH1 spams:
"DMAExec32 Attempt to run DMA while one is already active mem = 1000b400"
over and over.
arcum42
Never mind on Atelier Iris 1&2 not having the 2 warnings, btw. It's just later on in the game.
So, I'm reading this as that the Gust games are trying to run the DMA for IPU0 while it's active, and KH1 is trying to do the same with IPU1.
And the Gust games are trying to write to the 17th bit of QWC for some reason, despite it only having 16 bits...
ramapcsx2
Yes, that's our dmac issues right there.
I knew about the gust games doing it, guess what Fatal Frame does ;)
Basically whenever the double dma warning pops up, we have a problem as
we don't handle the situation well..
arcum42
One thing I thought was interesting, messing with DmaExec:
If you add return; right after psHu32(qwcRegister) = 0; in the if statement, Gust games still run properly, and only give the warning about the upper 16 bits. The attempt to run it while the dma is still active must be from the same call of DmaExec.
Of course, I don't know what happens with Fatal Frame if you do that, not having a copy...

Revision 2291

Start actually using tDMA_TAG. (IPU.h now uses it, and all the transfer code got
moved to it.)
arcum42
And yes, Tags.h is now entirely wrappers for stuff elsewhere...
Pillus1...
Returns
d:\svn\pcsx2\tags.h(37) : error C4716: 'Tag::Transfer' : must return a value
LINK : fatal error LNK1257: code generation failed
On compiling now :)
arcum42
Oops. Missed a return when wrapping a function. Fixed...

Revision 2292

Minor fix for r2291.

Revision 2293

Add a vsync callback to GSdx, managed by PCSX2.

Revision 2294

wtf? A working framelimiter? Turbo and slowmo hotkeys? Frameskipping?! Why
it's all here! Rejoice! And then find lots of bugs, too, I'm sure. Note:
Frameskipping has no gui stuff yet... I'll do that soon.
Pillus1...
Good job! :D
Using TAB to change the framelimit a couple of times will end it suddenly showing "Frame limit set to 5994.00fps instead of 59.94 :)
azte...
this is a so needed change/addition: thank you Jake.
1zz11111196
good pathway,,i'am loving IT
tatsuy...
No games are working, still a white screen when trying to run any game including bios.
davo...
same here nothings working nothing stars no bios nothing have to use revision 1888 to play
kaboo...
have you tried this
"Comment by ramapcsx2, Today (10 hours ago)
If you compile yourself, check if IOP_ENABLE_SIF_HACK is set to 1.
If someone else compiles, ask him what its set to.
The symptoms you get would happen if it was set to 1.
"
cause everything works for me
Jake.Stine
This is why we don't do fun hack experiments :p
tatsuy...
I don't self compile, I get them from http://www.mediafire.com/orleans
davo...
tried self compile once it was a horrible mess so now i go same place tatsu goes http://cid-ec92aae47a89073b.skydrive.live.com/browse.aspx/Emulation/Pcsx2?view=details
arcum42
That explains a lot. The person who put them up must have decided to try the hack.
That's one reason why we don't support builds downloaded from third party sources; there's no way to tell what modifications they've made before compiling, and sometimes it'll break things...
tatsuy...
Is there an official download source for the latest revisions or only when beta is released?
arcum42
Just the betas, and since the wx port came about, we've been holding off on betas till the gui is more mature. I think we're getting close, though. (The Windows port, anyways. Not sure if I'd want to do a Linux beta until the Fkeys work.)
Compiling yourself when testing the revisions is the best way to go, because then if something breaks on a revision, you can go back one or two revisions to see where it broke. And things do often break in svn.
The compilation for Windows guide in the Wiki tab has gotten pretty good for that.
However, if you are going to use third party downloads, you might want to locate more then one source of them, so that if things like this happen, you can try a different build of the same or close revision...

Revision 2295

w32pthreads: Removed some unneeded cdecl specifiers on non-exported functions.

Revision 2296

GSdx: SW rasterizer converted to use pthreads semaphores in the place of
spinwaits. Performance mileage will vary on this; probably favors dual core
machines over quads or i7's. Some tinkering might ink some more fps out of it
and get it to be a speedup in all cases though.

Revision 2297

Minor fixes for new framelimiter; add proper w32pthreads/gsdx dependencies to
the MSVC solution.

Revision 2298

GSdx: Small fix.
kaboo...
"// ThreadsConst - const number of threads. User-configured threads (in
GSdx panel) must match
// this value if UseConstThreadCount is enabled. [yeah, it's hacky for now]
static const int ThreadsConst = 2;
"
does this mean if I use the sw render I have to use 2 threads?
or is this info redundant?

Revision 2299

Compilation fixes for Linux.
arcum42
I'll have another revision out shortly; there was an issue that wasn't obvious till a rebuild with this revision.
arcum42
Specifically, x86Emitter gets built before Utilities, but uses headers from Utilities, so one of the changes I made didn't take effect till after I compiled Utilities, but broke x86Emitter on the *next* compile. Irritating.

Revision 2300

Let's try that again.

Revision 2301

GSdx: Fix some vsync enable bugs. Add "GSsetExclusive" API, which is meant to
be a hint for setting exclusive fullscreen mode in DX10 (no plans to support it
in DX9 due to complications that would require significant changes to DX9
resource management).
I don't have DX10 so this is (as usual!) untested. I'll be adding support for
it to PCSX2 soon.

Revision 2302

GSdx: Implement DX9 "on the fly" vsync enabler/disabler, and fix some dx9 vsync
bugs in legacy gui (hopefully)
matsur...
Great. Now the one useful change I did send isn't only useful in dx10 anymore :).

Revision 2303

Configuration panel code cleanups; supports slightly better handling of on-the-
fly settings changes.

Revision 2304

And, as usual, Gcc makes me want to throw things...
Jake.Stine
... 'tis good for the shoulders and triceps.
arcum42
True. ^_^

Revision 2305

More Tag stuff, mainly in Gif and HwWrite.
arcum42
Not to mention that QueuedDMA now takes a leaf from tIPU_DMA.
na12345....
reporting a problem for gran turismo 4 and tekken 5, the emulator just seems to halt once the games boot up btw its the r2305 im using with everything up to date. so maybe if you could explain the reason to this. BTW keep up the good work :)
heatbla...
OK, is it me just lame, or all the games I try to boot stops the emu? Tried with and without BIOS skip - no impact... Am I messing sth? Eveyrthing is default no speed hacks... 2271 worked normal this one does not work at all.
arcum42
Works fine on both Windows and Linux for me.
I'm personally guessing that either IOP_ENABLE_SIF_HACK got set to 1 somehow when you compiled pcsx2, or that you're grabbing builds from a third party site that set that hack to 1 before compiling.
See all the comments on r2288. We've been getting a number of false reports because of that, because if you enable that hack in the source it will break *all* your games.

Revision 2306

Potential fix for Issue 495 : missing keyboard handler in Linux.

Revision 2307

GSdx:
- Let's use dx10 software rendering for the F9 renderer switch, if it's
available.
docutu...
could we have fps count back ?
nokiaqdman
@ductorno
Yeah that would be great since Fraps isn't best.
ramapcsx2
I can't say if that's possible. The GS window is not handled by GSdx anymore.
Btw, Fraps is a lot more accurate than the fps counter in GSdx..

Revision 2308

Disable Vsync when using the F9 renderer switch.
Explanation why in the source :p

Revision 2309

A continuation of what I was doing in r2305.

Revision 2310

Get rid of Tags.h.

Revision 2311

microVU: Reorganized some clamping stuff...
zantezuken
Dunno what it does but any changes for mVU clamping worth +1
tatsuy...
Anyone with US version of Ace Combat 4 able to test if the inverted colors are gone? One of the devs said it could of been a microVU clamping issue and I can't find a source thats hosting this revision that isn't using the IOP hack thats breaking everything.

Revision 2312

microVU: added a flag to tell when its in COP2 mode.
macroVU: some clamping that may fix the ICO camera bug (not tested)
xat...
is microvu single or multithreaded?
fitness-...
Ico camera bug is fixed. I've checked it with PCSX2 0.9.7 svn 2317

Revision 2313

microVU: Implemented 'extra' clamp mode (it was doing the same as 'normal'
before)
Note:
What extra clamp mode does is whenever an SSE ADD/SUB/MUL/DIV instruction is
used in mVU, it will have its operands clamped.
Currently seems to cause sps in some games instead of fixing it...
There might be some reason for it that I'm not aware of yet, or it could be
'random' based on what a game is doing.
A quick explanation of what mVU's clamp modes do:
None - Does no clamping (fast)
Normal - Clamp certain instructions which have proven to fix games
Extra - Clamps every SSE instruction (slow)
Extra + Preserve Sign - Same as extra but preserves sign of the NaN (super slow)
Autor...
Fixes GT4 characters little sps with MicroVU, unfortunately doesn'f fix SC3 sps
coolraju...
cotton now does microvu offer everything that super vu has except for some devilish hacks?
darrenk...
Nice work, and welcome back, Cotton!
http://www.youtube.com/watch?v=QVS3WNt7yRU
zantezuken
No difference in Castlevania LoI/CoD: still the same VU issues ;<
ramapcsx2
Which same VU issues, and are they present on sVU as well?
cottonvibes
@scriptis: lol @ video
zantezuken
@rama
See Issue 170 for more details. Under sVU it is much worse, under mVu it's partially fixed. on interp. issue doesn't happens.

Revision 2314

New dialog for internal hacks.
arcum42
Dev note: Have any internal hacks not meant to be used normally call up this dialog...
ramapcsx2
"It will devour your young! - PCSX2 Shub-Niggurath edition"
This is so awesome :D
arcum42
Thanks. I really hope one of these third party people that compile the latest revisions renables IOP_ENABLE_SIF_HACK and doesn't test it before putting it up. Anyone who starts complaining about pcsx2 crashing on all games (unless you enable bios skipping, anyways), and talking about *devouring their young* deserves what they get. ^_^
But yeah, I was getting kind of pissed at people marking random revisions -1 because IOP_ENABLE_SIF_HACK was enabled when I commited this. And I love Lovecraft anyways. (Though why Shub-Niggurath would devour your young when she has a thousand of her own is beyond me...)
heatbla...
@ acrum42 sorry for marking the 2305 with a "-"... I am not a emu-master like most of you.. can`t tell what is it all about... a simpe user who sees if something works or does not, that`s it :) Thanx for the hard work, btw.
ramapcsx2
michael: Aw common, that was uncalled for.
Jake.Stine
Man this is what we get for a silly hack Rama and I toyed with for like 30 mins. :p
arcum42
Oh, the hack was interesting. It's not your fault that someone decided to enable it on all the builds they distributed without testing to see what it did.
And this way, if you come up with more hacks that are for developer use only, you can stick the defines in Config.h and add them into the if statement for this dialog...
arcum42
@heatblazer: That's all right; I'd already had other people mark my revisions -1 for the same thing, which is why I was already on edge about it. (though they took the -1 off after they figured it out).
But if something breaks like this please look back a few revisions, test and see if it might have started at an earlier version, and if you see -1 on other revisions past the last one you checked, look at the comments to see if any of the issues listed might be the same as the one you're having...

Revision 2315

microVU:
- Added microVU_Clamp.inl to the project file which holds all of mVU's clamping
routines.
- Added tmmk's optimized clamping method for sse4 (preserve sign clamp mode
only) <-- untested
- Not using regalloc for preserved-sign non-sse4 code anymore since it seems to
be bugged (thanks to nneeve for pointing it out)
- Extra mode was using preserve-sign code before; but changed it now to never
preserve nan sign...
- Fixed a bug in extra clamp modes where it was clamping all 4 vectors on SS SSE
instructions, destroying upper 3 vectors...
After these changes the compatibility of extra / preserve sign clamp modes have
gone up.
zantezuken
Now things in Extra+Preserve Sign completely broken. Black screen in Castlevanias.
Full mode (just Extra) not affected.
ramapcsx2
And I ask again, is sVU fine?
zantezuken
Why do you ask about deprecated sVU rec in the revision related to mVU changes?
Oh, and yes, the answer is - dunno, coz I tested related changes only.
ramapcsx2
I ask this so we know if it an mVU only issue or not.
davo...
i checked and its broken on both mvu and svu

Revision 2316

macroVU: Run vu0 on certain cases of recCTC2() like sVU's COP2 code does... this
fixes Rachet and Clank's title screen's sps...
Autor...
Yup, fixed
eliotfur
Yes, it really does...
Now there's only strange problem with textures and models loading/corruption left... And all geometry gets missing after pause/resume...
azte...
nice it got fixed, but i have 1 stupid (probably) question, does the devs tried to focus their efforts to fix only 1 game, i mean, make a branch of pcsx2 and try to fix totally only 1 game to see if this could fix more games than break them? Just a thought. ;)
Thanks for the one(s) who will reply.
eliotfur
I think, pcsx2 team is aiming at PRECISE emulation of PS2 hardware... If you have a model that behave exactly as the real thing... ???? Profit...

Revision 2317

microVU: fixed 2 bugs in my preserve sign clamp code thanks to nneeve
kaboo...
wow cotton on a row welcome back^^
zantezuken
yeh, now extra+ps mode is fixed

Revision 2318

Cleanup for VsyncInThread, lots of source code comments. (it's fun reading!
...maybe)

Revision 2319

w32pthreads/spu2-x/gsdx: add proper "debug" build of w32pthreads, instead of
both debug and release overwriting the same dll.

Revision 2320

GSdx:
- Unbreak Ratchet and Clank by re-enabling the broken pitch conversion.
Autor...
What does this fix in Ratchet and Clank, i have broken textures in game on distance
ramapcsx2
Yeah, that. And I know it's not working right, I've wasted days on that code already. Can't fix it ><
ramapcsx2
http://img5.imagebanana.com/view/6vhmz3fl/Unbenannt.jpg
Autor...
Btw, the same shit with textures as in Ratchet and Clank presented in Jak3, work correct when it close and broken on the distance, just let you know
eliotfur
Hmmm... Haven't noticed difference... Corrupted textures now appear later... 20-30% maybe...
Novak...
plzzz some1 fix ratchet and clank textures
simbo...
do what novak is telling
:)
ramapcsx2
Yeah, sure.
You so nicely plzzz'd me for it, it'll be the first thing I'll do.
Sigh, if I could fix these errors, I'd do it.
I wonder what you guys are thinking how easy/hard this is.

Revision 2321

Re-did the VUmicro's "Cpu Provider" structs into classes, and split sVU and mVU
into independent classes.
* Better error handling for when sVU fails allocating memory at a specific
location (should fail less).
* Partial support for detecting and handling non-SSE2 machines with some grace.
* Improved sVU's allocation chances with a second try at another randomish
address (and removed alloc fail spam from the console -- only logs on complete
fail now).
Pillus1...
Recompile error
d:\svn\pcsx2\x86\microVU_Macro.inl(340) : error C2228: left of '.ExecuteBlock' must have class/struct/union
type is 'BaseVUmicroCPU *'
did you intend to use '->' instead?

Revision 2322

Fix compilation errors (forgot to update cotton's recent changes before
committing)
Pillus1...
VU Changes makes all games crash pcsx2 on RUN with "Pcsx2 Has stopped working"
Pillus1...
Posting picture of the error messages the VU changes resulted in to have it documented somewhere
http://img109.imageshack.us/img109/8465/assertionfailed.jpg
http://img163.imageshack.us/img163/5358/assertion2.jpg

Revision 2323

Oops, forgot a __fastcall. >_<
docutu...
it crash
PCSX2 0.9.7.r2324 - compiled on Dec 7 2009
Savestate version: 0x8b410003
x86-32 Init:
CPU vendor name = GenuineIntel
FamilyID = d
x86Family = Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
CPU speed = 2.611 ghz
Cores = 2 physical [2 logical]
x86PType = Standard OEM
x86Flags = bfebfbff 0000e39d
x86EFlags = 20100000
x86 Features Detected:
MMX.. SSE.. SSE2.. SSE3.. SSSE3
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards
SetLanguage: Cannot find pcsx2main.mo file for language 'Italian' [it_IT]
SetLanguage: Cannot find pcsx2main.mo file for language 'Italian' [it_IT]
DwmEnableMMCSS successful.
Initializing PS2 virtual machine...
Allocating memory for recompilers...
Loading plugins...
Binding GS : C:\Program Files\PcsX 2\plugins\GSdx-SSSE3.dll
Windows 6.0.6000
NVIDIA GeForce 7600 GS (8.17.11.9555)
Binding PAD : C:\Program Files\PcsX 2\plugins\LilyPad.dll
Binding SPU2 : C:\Program Files\PcsX 2\plugins\SPU2-X.dll
Binding CDVD : C:\Program Files\PcsX 2\plugins\CDVDnull.dll
Binding USB : C:\Program Files\PcsX 2\plugins\USBnull.dll
Binding FW : C:\Program Files\PcsX 2\plugins\FWnull.dll
Binding DEV9 : C:\Program Files\PcsX 2\plugins\DEV9null.dll
Plugins loaded successfully.
Initializing plugins...
Init GS
Windows 6.0.6000
NVIDIA GeForce 7600 GS (8.17.11.9555)
Init PAD
Init SPU2
Init CDVD
Init USB
Init FW
Init DEV9
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards\Mcd001.ps2
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 769]
File/Object: C:\Program Files\PcsX 2\memcards\Mcd002.ps2
Plugins initialized successfully.
Issuing EE/iR5900-32 Recompiler Reset
Bios Version 2.0
Load Bios Warning: rom1 module not found, skipping... (this is not an error)
Load Bios Warning: rom2 module not found, skipping... (this is not an error)
Load Bios Warning: erom module not found, skipping... (this is not an error)
(UpdateVSyncRate) Mode Changed to NTSC.
... with user configured refresh rate: 27.50 Hz
(UpdateVSyncRate) FPS Limit Changed : 55.00 fps
Opening plugins...
Opening GS
Opening PAD
Opening SPU2
Opening CDVD
detected blocksize = 2048
isoOpen: X:\FM5 Originale\FM5 Originale.iso ok
offset = 0
blockofs = 24
blocksize = 2048
blocks = 1913328
type = 2
* CDVD Disk Open: DVD, Single layer or unknown:
* * Track 1: Data (Mode 1) (1913328 sectors)
(IsoFS) Block 0x10: Primary partition info.
Opening USB
Opening FW
Opening DEV9
Plugins opened successfully.
Issuing EE/iR5900-32 Recompiler Reset
(IsoFS) Block 0x10: Primary partition info.
(GetElfName) Detected PS2 Disc = cdrom0:\SLPM_662.05;1
(GetElfName) Software version = 1.01
(GetElfName) Disc region type = NTSC
Executing Bios Stub...
# Initialize memory (rev:3.70, ctm:19Mhz, cpuclk:15Mhz detected)
vtlbDefaultPhyWrite32: 0xBC1F000
ramapcsx2
# Initialize memory (rev:3.70, ctm:19Mhz, cpuclk:15Mhz detected)
Wow, how did you do that? xD
Anyway, no crashes, sir.
docutu...
mmm dunno , the cpu speed is detected right 2,61 ghz (some time it says 3,0 ghz) , i just compile the last svn with the release sse3 version , i will try later with the latest svn
Jake.Stine
# Initialize memory (rev:3.70, ctm:19Mhz, cpuclk:15Mhz detected)
... that means the virtual PS2 (as emulated by PCSX2) think's it's running on a 15mhz cpu instead of a 295mhz cpu. That is fairly unusual. The usual response looks like this:
# Initialize memory (rev:3.63, ctm:393Mhz, cpuclk:295Mhz detected)
(rev depends on your bios version and what-not, so it's natural to vary). Anyway, that's some serious broken-ness there...probably just need to do a full rebuild of pcsx2 to resolve it.
docutu...
i will do with your last svn , the one related to cmp emitter

Revision 2324

Changed the fpu MUL hack for tales of destiny. (Doesn't break under most
settings now).
ramapcsx2
Very nice, this is some interesting information there.
azte...
excellent update nhervé. :)
Nne...
Thanks, but I'm not nhervé.
ramapcsx2
xD
azte...
i see, i thought you were him. :)
zantezuken
@[email protected]
PCSX2 has it's won forums now, ya'now. Try to visit them, instead of ngemu.

Revision 2325

More throwing things.

Revision 2326

Add debug versions of Null plugins (helps fix some stack tracing problems having
a full set of debug-built DLLs, even if they aren't the source of the crashes).
DevNote: Moved jNO_DEFAULT from the Pcsx2Defs.h, since it's too dependent on the
Common libraries. It's now in Assertions.h. Plugins can use __assume(0);
directly instead or roll their own.

Revision 2327

* Redid console logging to use stdout instead of the buffered queue (probably
less buggy).
* Removed some hacks from cpuDetectInit's use of cpuId.
* Improved assertion checking for thread affinity.

Revision 2328

cpuDetect: fix for some odd crash in MSVC/PGO builds (this one took hours to
track down, though still not really sure what caused it).
docutu...
may be it fix ever mine crash , i will tell you soon
ramapcsx2
Nice you got it in the end.
PGO builds work fine now :)
docutu...
mmm guys i am afraid but..
http://i47.tinypic.com/54ezoz.jpg
kaboo...
... is that a PGO build?
if not stop negating unrelated commits
docutu...
yes is it
if you wanna try it is here with all the plug in compiled release sse3
http://www.mediafire.com/download.php?yqtnnzkgzj2
kaboo...
works fine here though I tested only wild arms 3
docutu...
i am not able to boot even the bios.. i have to investigate..
kaboo...
though I did not use your plugins since I can only use SSE2 but mine are up-to date but not with pgo
docutu...
mmm i have to test it with plug in compiled by others
docutu...
ok tested , it crash even with the lates official pluging , but the latest official pcsx2 did not crash with svn compiled plugin , i still think that the fault is on pcsx2 change done on this svn
Jake.Stine
Your bios message for initialization is still entirely bogus. I have no idea how that's happening, but I'm pretty sure it's not anything the PCSX2 team can fix. Something in your pcsx2 install or compilation builds is really screwy.

Revision 2329

Preliminary register structures for the GS CSR and IMR regs.
arcum42
Not hooked up yet. Since I have the potential to turn
GSCSRr = 0x551B4000;
into
GSCSRregs.reset();
I thought it'd be a good area to look at next.
arcum42
(And yes, the 4 lines in the reset function do the equivalent of the above.)
Autor...
About GS, could someone reactivate fps *and other things* counter for GSdx?
arcum42
It wouldn't so much be reactivate as recode, because GSdx is now using a window created by pcsx2 and not it's own window. And I'd really have to go with ramas answer from the comments of r2307, about not being sure how possible it is.
Rama, Jake, and Gabest would be the developers to talk to, though. Most of the coding I do is in Linux, so I don't really touch any of the Windows only plugins. SPU2-X is an exception, because I plan to port it one of these days...
Jake.Stine
The trick with CSR is that it's a dual register. The write value needs to update/modify the internal status of the interrupts and signals, which is why there's a GSCSR and a CSRw. I'd almost prefer if CSRw were just a custom bitfield struct of the bottom 5 bits tho (the various GS interrupts)... explained below.
Also, flipIntBits is incorrect. :) Or rather, setIntBits is incorrect. What the code in the current GS is doing is this (bit breakdown):
if( written.SIGNAL ) current_SIGNAL = false;
if( written.FINISH ) current_FINISH = false;
// etc, for all 5 lower bits.
That's all. So it retains the current CSR if those bits are written a 0, and sets those bits to 0 if they're written a 1. The SetIntBits sets them to 1 instead of clearing them to 0.
(and if they're written a 1, there's possibly other actions that need done too, as I documented in gifpath.cpp, so it's really best if it literally uses that style of if() {} code, instead of bitmasks)
So in summary: The implementation in the current GS CSR is over-complicated, and is also only half implemented (I documented SIGNAL and FINISH pretty decently in gifpath.cpp). And since we would't be using clever mask tricks anymore, the CSRw could be transformed into a more sensible set of booleans and stuff with all the state info needed for full and proper SIGNAL/FINISH emulation.
arcum42
I'd prefer the if statements, actually. I just wasn't sure if there were other reasons to use the bit fields.
And I wasn't totally sure about setIntFields and flipIntFields. (Though I would have been calling flipIntFields; setIntFields was internal). That's one reason why I decided to just commit the structure and not implement it yet was because I was hoping for feedback before continuing.
I'll go ahead and implement a new function to take the place of those two, and a new struct for CSRw that is just the interrupts then...

Revision 2330

GSdx:
- Crashfix for Dual Hearts, fixes part 1 of Issue 314 .

Revision 2331

Don't do invalid GIFchain calls, fixes Dual Hearts part 2 of Issue 314 .
This is part of PATH 3 masking mess, so it could fix other PATH 3 using games.
Added some debug lines as well, should there be problems.
lemuel2010
Well,this is a good update!!!
ramapcsx2
Btw, Dual Hearts broke in r1409. I checked the game "Izumo Complete", and it still works.
azte...
good work ramen, it's good to see the devs focusing on fix one game at a time, it may fix others as well. :)
animus...
Yeah, good job... "ramen". xD

Revision 2332

GSdx:
- Fix the Dark Cloud 2 crash when inventing stuff.
ramapcsx2
// Use version 1 of the optimized local > local transfer, as per revision 887.
// Later (more optimized?) versions cause a crash in Dark Cloud 2.
Since I can't figure out how to fix the crash, I just reverted to a less speedy Move().
This function is rarely used, and usually not a performance problem.
The big exception is Breath of Fire 5, which now lost 5% fps.
Imo a good tradeof :p
heatbla...
Just one word - KISSES!!!!!!!
heatbla...
Hmmmm.... maybe this was not one word but many.... whatever - you are No 1 guys - all of you!
eliotfur
Age of rewriting (mVU, wx, aligned stack and so on) ended... Now is the age of FIXES...
Autor...
rama, long time wanted to ask, how to activate your WIP/fog/dof code, you say it works not much better, but iwant to test it anyway
heatbla...
Well... the annoying heatblazer won`t bug you with that issue and with Steambot Chronicles :D Guess you are happy :D But still have to let you know that Micro VU breaks GSDX graphics in Castlevania Curse of Darknes... however Legacy is OK... so I can`t report that as a problem but just for you to know.
azte...
game fixes rule, thank you raman.
ramapcsx2
My nick is rama, thank you :p
Autoran1:
it's not worth it, but find the place and change the #if1 there to #if0.
Autor...
Thanks
pcsx2gu...
Comment by heatblazer, Today (11 hours ago)
Well... the annoying heatblazer won`t bug you with that issue and with Steambot Chronicles :D Guess you are happy :D But still have to let you know that Micro VU breaks GSDX graphics in Castlevania Curse of Darknes... however Legacy is OK... so I can`t report that as a problem but just for you to know.
You see it's not random these games got fixed. Dark Cloud 2 got fixed because a member found the exact revision it got broken and I confirmed it ( http://forums.pcsx2.net/thread-8814-page-2.html ) and Dual Hearts got fixed because me and shadow000 also tracked the exact revision it broke and did extensive tests ( https://code.google.com/p/pcsx2/issues/detail?id=314 )
I'm just saying that to make you understand that instead of wasting your time whining/posting the same stuff like x game no work fix!!11 you could help like others do and get the issues resolved.
zantezuken
@heatblazer
//But still have to let you know that Micro VU breaks GSDX graphics in
//Castlevania Curse of Darknes...
How in the hell mVU-issues related to GSdx and rama's work?
...
@rama
//The big exception is Breath of Fire 5, which now lost 5% fps.
//Imo a good tradeof :p
Can't disagree here. BoF already pretty fast, in some place FPS drops significantly, yeah, but those 5FPS will not help in this case.

Revision 2333

Stop VIF0, VIF1 and EE SIF1 from interrupting based on how much data was
transfered.
In theory this would be the correct thing to do, but with our current DMAC and
event test system it just causes problems.
Note: This commit *could* break/improve/fix games, please test :p
arcum42
Mana Khemia, at least, is all right with it, since it doesn't crash at the normal spot affected by voodoo cycles.
tatsuy...
Sky Odyssey now runs through the intro, lots of flicker and black lines but 90%-100% speed. Though it sits at a light blue screen after intro, but hell this game was dead since revision 97x and its coming to life again nice job.
At menus sometimes it hangs at bluescreen and sometimes I can hear the game running as I press buttons then screen turns black, console messages during this are (spammed):
*PCSX2*: DMA error: 5f395378
Hackfix - NULL GIFchain
dragonlo...
This rev breaks Okami. It hangs on a white screen. Tested with Rev 2332 and it works fine.

Revision 2334

fix for the annoying msvc warnings

Revision 2335

Did some work on HwWrite. Updated my structures in GS.h. Fixed some podsafe
object warnings I'd missed previously.

Revision 2336

Change a few .ADDR's to _u32's, so the SPR field is included.

Revision 2337

Revised dmaGetAddr. Fixed a thread error message.
ramapcsx2
No speed difference in the (short) test I did.
It was a FMV though, so lots of dma activity.
tatsuy...
Very small speed boost with Sky Odyssey, console spam saying:
*PCSX2*: DMA error: 0359d021
Hackfix - NULL GIFchain
Has reduced to saying it once.
JohnnyKi...
Its a little speedup for pcsx2:)
dragonlo...
Okami now hangs under a white screen.
azte...
"Comment by wespipes69, Today (7 hours ago)
Why negative then?"
using google code for the 1st time? ;)
kaboo...
I too don't understand why he voted negative but your comment I understand less... I could understand it if googlecode would randomly transmit false voting data... but that's not really the case...
Jake.Stine
Okami is probably fixed by changing this:
return ((addr >=0x70000000) && (addr <= 0x70003fff));
back to this:
return ((addr & 0x70000000) == 0x70000000);
... the reason is this:
return (tDMA_TAG*)&psS[addr & 0x3ff0];
I'll bet a penny the VIFdma and SPR implementations don't wrap the address themselves, instead expecting GetDmaAddr to wrap it for them.
arcum42
Provided it's this revision, that'd be the most likely candidate.
Anyone have an Okami dump I can test with?
xto...
how would you get this revision to test
arcum42
Generally by checking out the revision and compiling it. Svn builds often have things break and unbreak, which is why we don't provide official nightly builds, just occasional betas and releases.
Now, as far as unofficial copies, if you googled "pcsx2 r2337", I'm sure you'd find several copies other people have compiled. We don't support those in any way, as it'd be easy for people to make source code changes before putting them out, resulting in us getting erroneous bug reports (as has happened in the recent past).
Also, if you compile it yourself, it's easier to determine *exactly* which revision caused a problem. The people that compile unofficial builds often do it once a day, or once a week, and it's easy to accidentally blame issues on one revision, when they actually started, say, 4 revisions ago...
KrossX3
I just tried Ookami with r2336 and it doesn't boot either. So, this revision didn't break it.
Also, it seems to work fine with r2330, at least up to starting a new game. Is a good start point to test revisions. I'll try to get which one broke it later... now work's calling. >_<
arcum42
Ah, that's good to know, because Jake's suggested change was the biggest change in the function, and if that didn't take care of it, I wasn't that sure what did it...
dragonlo...
Confirmed that rev 2333 breaks Okami. Please ignore my above comment.
KrossX3
Alright, here it is:
Ookami boots on r2332, does not boot on r2333+
As usual, builds compiled from a clean unchanged SVN folder.
arcum42
BTW, Jake: Do you still want that old Virtual memory dmaGetAddr code in there for reference, or should I go ahead and delete it?

Revision 2338

Most likely unbreak Okami. I don't have this game, but I'm 99% sure it's this.
Autor...
I have Okami, and i remeber it always been playable, so i don't understand this...
ramapcsx2
Please try it with this revision then.
poisiono...
(edit, i went a little wrong with the consoles there, oops :p)
I admire the devs energy and hard bloody work.
We have:
A ps2 console.
Then we have a quite different architecture, the pc.
Then we have different specifications, and 32-bit and 64-bit.
Then we have different OS'ses for it (linux, mac, winxp, win7)
Then we have different input devices on both platforms.
Then we have Different grfx-systems, Open GL, Direct-x
Then we have different versions of Direct-X, (dx 9, dx 10)
Then we have Different grfx-cards manufacturers (Nvidia and Ati And Intel)
And then the cards handle the grfx-systems differently even.
I would die just from the first couple of non-standards.. *passes out*
(sorry for the off-topicness this time, keep up the good work!.
unfortunately i do not have okami available at the moment)
/PReP
KrossX3
You did it! Ookami is working now. ^_^
KrossX3
I wanted to ask this on the IRC, but got instantly banned for some reason.
Since some of us have the game and can test a bunch. What kind of values would be good to be tested on that commented line?
ramapcsx2
Make it:
CPU_INT(6, min( (int)(cycles*BIAS) , X ));
Then increase X until the game works. I'd need to know which value that is.
Note that this is no exact science. It's an arbitary value at which the whole system starts "magically" working.
Hence the voodoocycles comments :p
azte...
love game specific fixes, keep 'em comin ram. :)
KrossX3
The magic number for Ookami seems to be 6.
KrossX3
Wait... now's not working with 6. =_=
*sighs* It makes no sense... I'll test some more tomorrow.
Any way to get console output of what "(int)(cycles*BIAS)" gives? That might help a bit... I think. >_<
arcum42
Console.WriteLn("(int)(cycles*BIAS) = %d", (int)(cycles*BIAS));
KrossX3
Oh, it's like printf... no wonder then. Thanks! XD
arcum42
np.
And, yeah, it's mostly like printf. There are several variations of it, though. Console could be DevCon or DbgCon if you wanted to limit it to dev builds or debug builds, and WriteLn could be Error, or Warning for different colors. Or Write, if you didn't want a line break at the end.
Or you could just put a color name as the first parameter, say Color_Cyan. If I'm just testing something, though, I usually just use Console.WriteLn. Most of the others are for if you're planning on leaving the message in pcsx2, really.
Strings can be a bit trickier to print, though, because of some of the limitations of C++...
dragonlo...
Okami works fine now. Thanks for the fix.
KrossX3
Alright, here's some logs for that "(int)(cycles*BIAS)" (which I called MagicNumber.. >_< ) => http://www.mediafire.com/?lz5tinvtynw
Normal, it's just as it is now. And forced, gave same results if either forcing a constant "CPU_INT(6, 4)" or a max value with "CPU_INT(6, min( (int)(cycles*BIAS) , X ))". It hangs exactly when under "normal" would've gotten that big number.
Most probably this ain't right at all, but doing something like this, Ookami works.
if ( MagicNumber > 512 )
CPU_INT(6, MagicNumber);
else
CPU_INT(6, 4);
@arcum42:
I had the color, but I was trying to concatenate the string like this: "String" + Int ... it gave quite interesting results on the console. XD
ramapcsx2
Alright, I'll leave this alone then.
I was hoping for a small number, but this looks like a bad case.
Let games do double interrupts then, didn't cause any issues i know of anyway.
Autor...
Tested Okami, didn't see any changes, this game always worked for me
ramapcsx2
You obviously missed the few revision where it was broken..
Autor...
Look's like i did, well it works so +1
sbria...
Works great on my intel i5 and nvidia gtx 295, 60 fps
Jake.Stine
Comment by [email protected], Yesterday (20 hours ago)
>> love game specific fixes, keep 'em comin ram. :)
Indeed, pcsx2 needs more ram!
heatbla...
LOL :D Looks like coders, have sense of humour? So geniuses are humans afterall :D I bet you all even got facebook accounts :D
kage.urufu
Awesome
eliotfur
Was this about Start button in menu not working?..
I've compared r2318 and r2338... Both run well...
But I had "Start button not working" issue on r2280...
All recent revisions skip first intro (when the brush starts to draw things)...
refraction
The reason it hangs if the value is too small is because it issues the DMA, waits a bit, then makes sure its still busy, its very frustrating! had a play with this myself, put the timing in when i realised it worked, best i could without it killing too much stuff anyway.
Good luck getting it right ;)
Jake.Stine
Yeah the SIF has a serious fundamental issue too: it assumes the EE/IOP interrupts will occur in some specific order, but the two CPUs schedule things independently, and don't always trade off to the other CPU in "perfect" timing fashion. So weird things happen where the EE side of SIF will signal before the IOP side, even though by all logical accounts the EE CPU_INT timer "appears" to be scheduled after the IOP one.
(or vice versa)
... hence all the voodoo behavior >_<
refraction
Not quite in this case, its literally hard coded in to the program, it doesnt rely on any interrupts, it literally wants to see it busy within 8 cycles or something. the code goes like so
Sif_DMA Start
nop
nop
nop
nop
nop
nop
nop
Check Sif_Busy
if busy jump to right place
else bugger up ;p

Revision 2339

User Interface code cleanups and bugfixes. some highlights:
* Configuration panels are all modal-less now, so that you can open the config
panel and leave it open while running games.
* Handful of thread sync improvements.
* Fixed on-the-fly interpreter/recompiler configuration.
* Fixed plugin hotswapping (mostly works, but still a little funny at times)
* All new assertion dialogs and popup message handlers.
* RecentIsoList defaults to 12 instead of 6
Dev Notes:
* I had to create a new set of assertion functions called pxAssume*.
Originally I hoped to avoid that complexity, and just use a single one-assert-
fits-all case, but turned out blanketly using __assume() for all assertion cases
wasn't reliable.
* wxGuiTools: Replaced the operator, with operator& -- the latter has proper
order of precedence, the former required () to scope correctly. >_<

Revision 2340

Fix bug in BIOS skip hack (which I always forget to test since I never use it
personally ;)
KrossX3
Oh, I use that quite often.
And is still working, so +1 bug fixing.

Revision 2341

The usual Linux stuff.
arcum42
And a minor change to SPR.cpp that I forgot to make at some point.
Jake.Stine
Pretty amazing that all that stuff I changed and that's all that GCC cried about :p
arcum42
Yeah, and one of them I'm pretty sure was just a header adjustment somewhere. I just didn't bother to figure out what existing include was bringing in csetjmp for jmp_buf...
Jake.Stine
I forgot to put in my prev commit devnotes: my big commit also completely removed PCSX2 from depending on debug builds of wxWidgets. All assertion stuff is handled natively, and the AssertionDialog is actually enabled in *all* Release/Devel/Debug builds (though the pxAssert macros still generate null code in Release).

Revision 2342

w32pthreads: typo fix in pthread.h for CLEANUP_C mode (unused in PCSX2 since we
rely on SEH builds exclusively)

Revision 2343

Skip Bios hack works in EE interpreters now.
heatbla...
Should 100% fix Steambot Chronicles with/without bios boot. That is a good one! Here is a +

Revision 2344

Disable VU recompiler options for machines without SSE2.
heatbla...
That looks great for an official BETA release in the site, eh?
Jake.Stine
Don't get too excited yet. Can't go beta without a working memory card manager/selector.
heatbla...
Hmm.. I remeber that there was something like that... that`s why I renamed my MC1 and MC2 to MCD001 and MCD002... now I recall that...
zantezuken
You forgot gs-window title info about CPU/GPU load, savestate count, etc...
dragonlo...
This is probably a stupid question, but why make PCSX2 compatible with non SSE2 CPU's?
pcsx2gu...
PCSX2 already did support non SSE2 CPUs, this commit just automatically disables VUrecs for you if your CPU doesn't support it.
kaboo...
is there still a point for non SSE2 cpus to run PCSX2?
pcsx2gu...
Not really, but saves us the whining of people with some ancient Pentium 3 machines asking "WHY NOT WORK MY PC HAS MOOORE MEGAHURZ THAN PS2!!111"
kaboo...
... only to get posts like "WHY SLOW?????! PC MOAR FAST THAN PS2!!!!"
I see little point in coding this service but I hope the people with said hardware are at least are grateful^^
pcsx2gu...
Well if you check the diff it's like 2 simple lines of code, don't think that took more than 2 seconds for Jake to write :P

Revision 2345

experimental new vif unpack rewrite... (currently disabled and slow)
Autor...
What this Vif unpack for what games it could help, and how to enable it?
ramapcsx2
No comment.
Seriously, we can't explain every change we do to you.
If you want to know what changed, read the diff.
It's not hard to figure out how to enable/disable stuff.
Autor...
Sorry, i figured out how to enable it, no need to rush
heatbla...
The revision rox ass! I`ve tested many games, and hell, they work. Btw, as expected Steambot Chronicles boots with/without the BIOS skip, but more interesting is that the speed of the game has improved (can`t tell by how much fpses) but the vertical lines remain... However, great revision! Keep it up (kiss)
keb...
i'm sorry for what i'm about to say, you can even delete it if you want but...
heatblazer can't you just STFU about steambot chronicles?!!
i read the comments because i like seeing the emu growth and the comments makes me understand a lit bit more about the revisions, and it's also useful when a particular revision affects a large group of games check if my games are in that group... but you really can't stop talking about that game regardless of the relation to it...
heatbla...
@ kebrus - flaming is not the main reason we are here. I may have pissed the coders with SBC for some time but I have stopped. I just reported what are the positives of the game now.
I`ve tested Eternal Poison! It is visible. I`ll go to the forums to post the screenshots, however the battles are still black but... hell - it`s great!
keb...
see what i mean? you can't stop talking about it, even when you are justifying your reasons you HAVE to tell the battles are still black... holy jebus are you ferrarin with a different nickname or something?
keb...
PS: i know that you are talking about EP now (it was just an example of your behavior)

Revision 2346

Did some optimization and bugfixing on the new VIF unpacker. :) (it's still a
bit slower than the current/old one though)
Jake.Stine
Looks like TriAce games do the same thing that GoW does -- tons of 1-length packets that get really really slow because of all the overhead involved in resolving which VIF unpacker to use. So it's definitely worth optimizing. I made notes in the code how to do it. :)
Jake.Stine
Also, I checked and not only is the vifUnpack 1-count in length, the entire vIF function is only 2-3 commands -- so there's almost no use in bothering with a higher level recompiler of VIF. The effort involved in resolving the recompiled function for what amounts to two or three lonely dispatches would be nearly equal to the current brute-force approach.

Revision 2347

* Disable newVifUnpack, which I left enabled in the prev commit (it's not ready
yet!)
* Added feature to align call targets for EErec functions and blocks on P4's
and AMDs, and pack them on Core2/i7's.
* Fixed some svn:native props.
tatsuy...
Core i7 w/HT on here, seems to be a slight speedup.

Revision 2348

GSdx:
- Decrease upscale glitches in dx10 (dx9 later) by hacking the UV coordinate
system in borderline cases.
heatbla...
Will test it ASAP... great rev.
wespipe...
I see no difference in my games (tekken 5, RE Dead Aim,etc). Using 1080X1080 does get rid of the black lines - but cuts off a portion on the bottom of the screen though. :(
ramapcsx2
Forgot to mention, it's only working with the scaler options.
wespipe...
I'm using the scaler options and still zero improvement in all my games (tried 2x, 3x) - black lines still there. Darn it!
ramapcsx2
These games might be using the "stq" coordinate system then.
Anyway, this (and other) hacks are meant mainly as a fix against misplaced textures.
Text and brightness layers mostly.
ramapcsx2
http://img5.imagebanana.com/view/gzs2l37/1.jpg
http://img5.imagebanana.com/view/27by3r5c/2.jpg
peter.0x...
Awesome, this fixed a lot of glitches in the various Gust games. Great work.

Revision 2349

newVif: optimizations, cleanups, and bug fixes...
DanrleiS...
oK! Very Well! Gsdx works good now!
DanrleiS...
Work good now ! Incluides quality!
pcsx2gu...
Lol what? Do you realize that this has nothing to do with GSdx and that you need to modify the source to even use it? :P
Other than that, good job people, a new VIF sounds promising :)
Jake.Stine
Yeah so far it doesn't look like it's going to be any faster. But it's certainly much easier to work with. We'll be able to obsolete a few more asm files and a whole lot of ugly VIF code, once a couple known bugs are fixed.
arcum42
And that alone will be worth it.
I'm assuming getting Gradius V and Ape Escape 3 working in newVif would be in the known bug list? (I checked both simply because I recall what a hassle keeping them working when modifying the Vif unpack code was...)
ramapcsx2
Gradius 5 is broken ><
Thanks for letting us know :p
arcum42
np.
At this point, I test both on any Vif unpack revision, because I've broken both of them more then once. (Of course, with Ape Escape 3, I have to whip out a dump of the opening I have sitting around. And that is broken in newVif too, incidentally.)

Revision 2350

Resolves Issue 502  : FFXII vid hangs in release mode builds due to PCH being
enabled on IPU.cpp.
This is actually the second time around on this. Same problem happened in the
Playground days, with the same fix. ;)
federelli
I don't get it, is it a MSVC bug? Happens with GCC and ICC too?
azte...
yay for Jaky's game fix, way to go man. :)
Jake.Stine
>> I don't get it, is it a MSVC bug? Happens with GCC and ICC too?
GCC doesn't have real PCH (just some fake hackup that hardly works). ICC doesn't work, period.
The IPU code breaks a lot of rules. I'm amazed it works with any compiler optimizations enabled, honestly. So it's less likely a bug in MSVC and more likely just IPU causing optimizations to become unstable due to entirely unsafe use of asm code.
icedus...
the final fantasy XII fmv's on pal version are completly broken:
http://img691.imageshack.us/img691/9595/finalfantasyxiifmv.jpg
Should i make an issue because of this?
Jake.Stine
I'm pretty sure using Software mode in GSdx fixes those FMV (press F9). If so, it's a known limitation of GSdx HWaccel modes.
icedus...
hum thanks i just asked because in r1888 the fmv's are perfect and in recent revision's are broken
ivicamar...
I have the same problem black lines all over FMVs on PAL. Somewhere about svn r2000 they occured but then get fixed up and then get broken again, but at that time didn't pay much attention. I am trying to figure out which version it was. So far i am going backward and get to r2090.
federelli
Nice, ty for the explanation :)

Revision 2351

newVif: some minor changes and cleanups...

Revision 2352

* Significant optimizations to the VIFunpack interpreter (employs templated
maskmode and cyclesize constants).
* Minor optimizations to newVifUnpackSSE, and more optimization notes.
Jake.Stine
For what it's worth, the interpreted VIF unpacker (SSE disabled) is some 50% faster than it used to be, I think (depends heavily on the game still).
... speaking of which, does the the VIF unpacker require SSE2 or just SSE? That question applies to both VIFs, zero's and cotton's. I never paid attention to that. :p
ramapcsx2
New VIF is now 1-2 fps faster.
Up to 93fps in SO3 (97fps with old Vif), and 40fps in SotC (44fps with old Vif).
Getting there ;)
arcum42
Issues that I'm having so far:
1) gcc doesn't like it if you declare a function (_nVifUnpack) as static, and then define it as an extern in a header. Easy enough to take care of.
2) This one took me a little while to trace back. In VIFunpack.cpp, gcc gave a whole bunch of errors saying "error: insufficient contextual information to determine type" in lines using UnpackFuncPair.
What it's complaining about is that the last parameter in these two typedefs is u32, though it took a little while to trace that back, given the cryptic error message.
typedef void (__fastcall *UNPACKFUNCTYPE)(u32 *dest, u32 *data);
typedef void (__fastcall *UNPACKFUNCTYPE_ODD)(u32 *dest, u32 *data, int size);
Still thinking about how best to deal with that...
Jake.Stine
Arcum42: geh... wtf kind of error is that? Great.
Does making it void* data work? I dunno.
Try adding some &'s in front of the function names in the macro? Sometimes that helps unbreak stupid compiler-ness.
If all else fails I guess we can revert back to having 24-some functions which just serve to typecast the parameter for use by the templates. Annoying. >_<
Jake.Stine
I can't look at it myself because my co-linux is broken (tried to upgrade, and it's not working so well. >_< )
arcum42
That was about my reaction.
I'm still messing with void*'s right now. I just decided to start working on it in a different directory with a clean copy of the source, because I'd fiddled with the previous copy too much...
What type of issues are you having with co-linux?
arcum42
Finally got the friggin' thing to compile. I'll give you a patch to look over after I play with it a little more.
arcum42
Spoke too soon; forgot I didn't have the new dma enabled. I'm closer, though.
arcum42
Well, this compiles, and I did run Tekken 4 for a few minutes with it.
Thought I'd see if you had any ideas for improvement.
http://pastebin.com/m2c52b235
Jake.Stine
>> What type of issues are you having with co-linux?
the new nautilus/xming combo crashes constantly, mainly. I tweaked settings right out of the box tho, I'll have to try a vanilla build and see how it runs.
_unpk_u(32) / _odd_u(32)
Is that stuff needed in that patch? It looks like it's all just casting to void* anyway, which should be allowed (or does GCC throw some fit?).
arcum42
I had a copy of nautilus like that once. As I recall, that's what spurred me to try a different desktop manager then gnome.
As far as the _unpk_u(32) stuff, I tried to remove it once things were compiling, and those contextual errors came back. Otherwise I would have gotten rid of them, because I wasn't really happy with it.
arcum42
Though I think the ones that actually say _unpk_u(32) and _odd_u(32) can be turned back into _upk and _odd...
arcum42
But the _unpk_u(bits) && __odd_u(bits) ones are needed. (Didn't quite mean to hit 'Submit' right there...)
Jake.Stine
ok... man that's totally not making any sense. Did you try something like:
(UNPACKFUNCTYPE)_unpk_u(bits) // instead of (void*)_unpk_u(bits)
... running on the theory that GCC will let us cast the function to anything (including void*) once we've cast it to itself. Ie, what really matters, maybe, is the "cast to myself!" part, and not the void* part?
Jake.Stine
Anyway if that works it'd solve all the typecast mess in actual-use code anyway, which is fine. Don't much care if the table construction macros are ugly, but the typecasts in the code that references the tables is.. bleh. :(
arcum42
All right, that works, at least. So we can get rid of the void* casting, thankfully, even if we're stuck with the typedefs...
arcum42
That trimmed it down enough that I went ahead and commited what remains. It's pretty much isolated to the tables now.
Oh, and Gradius V, while still being messed up in newVif, looks less messed up in this revision, btw...

Revision 2353

Bugfixed bad behavior when using BiosSkip and doing interface-ish things while
the stub was running.

Revision 2354

Various bizarreness to get Linux working again.
Jake.Stine
I'm pretty sure there's no standard C++ rule that says a templated function must be explicitly cast to itself before it can be re-cast to another function, even if it wouldn't surprise me to learn that there is (simply because the C++ standard is that random at times).
Jake.Stine
Also, maybe this is actually a bug dealing with __fastcall and templates under GCC. If I recall I had problems with __fastcall in some other places as well, prompting me to use a selective macro that evaluates to cdecl on GCC.

Revision 2355

Bring the main gui on top when suspending emulation.

Revision 2356

Minor optimizations to newVifUnpack.
Jake.Stine
Cotton: Ok, confirmed this commit did almost nothing for speedup, and the profiler insists incVUmem is a bottleneck: which means that the main overhead remaining in the newVIF is a combination of the call/ret to the function pointer, and possibly dependency stalls in the XMM result writebacks in the SSE functions. Both things typically cause AMD code Analyst to think the code *after* the problem code is slow, because the actual penalties in the CPU occur after the instruction pointer has been updated to point to the next instruction(s).
So yeah, the best thing left to do is inline the SSE unpacks into the loop itself, using fully recompiled unpackers and such.
arcum42
Just a quick observation on Gradius V. It works with either newVif totally disabled, or with it enabled and newVif1 disabled, (and is messed up with newVif1 enabled.)
However, if you have newVif1 disabled and newVif enabled, "huh!!!!!!!" spams all over the console when the opening animation plays. Thought that might be useful as a case of when that piece of code in VIFunpack() is used...

Revision 2357

Remove some assertion and log spams in devel builds.

Revision 2358

Wrote a vif 'unpack' packet recompiler.
Compatibility is probably the same as the newVif interpreter code, but its
faster.
Speedwise its similar to the old-vif unpack code (the one currently enabled by
default in pcsx2).
Its about 0~2% slower on my machine from my limited testing, but I assume people
with SSE4.1 cpus might have a lot better results since I added a lot of sse4.1
optimizations...
The SSE4.1 optimizations were also ported to the newVif interpreter code.
Also the "filling mode" should be fast compared to the old-vif unpack code since
its sse optimized, but most games don't use this mode so it hasn't been tested
much...
DanrleiS...
Ok. Many work now. There were many get better, and now the emulator uses the maximum attributes of the capacity of the cpu.
arcum42
While Gradius V is still broken in newVif, it's a lot less broken in this revision. On the opening movie, 3/4's of the screen is missing, but a bunch of screens that were just gray previously in newVif look fine.
trigunflame
thanks for the 4.1 opts.
azte...
cottonvibeh rules. Thanks for the optimizations.
wespipe...
Looking good!
SSX World Tour has completely messed up graphics, not sure if you're worried about that yet. It's fullspeed though, even doing "Monster Tricks" doesn't cause a slowdown anymore.
Autor...
Cotton you're the best NewVif fixes some of SPS in Star Wars Episode 3 which always was here
Autor...
Here's the example
old Vif
http://img42.imageshack.us/img42/5216/old1e.jpg
http://img526.imageshack.us/img526/8642/old2y.jpg
new Vif
http://img526.imageshack.us/img526/7569/new1zp.jpg
http://img526.imageshack.us/img526/7251/new2m.jpg
i'm very glad that this old bug is progressing *game still have some bugs with new Vif, but i think this cause Vif is WIP*
cottonvibes
autoran1: cool :D
it also fixes Wild Arms Alter Code F.
But it currently breaks a lot of games too, so hopefully we can fix that soon :)
rickywoz...
So I'm trying to fix Wild Arms: F, but I have no idea how to do any of this. Anyone?

Revision 2359

Update project file.

Revision 2360

static and extern do not mix.

Revision 2361

(Most Plugins) Updated plugins to obey PCSX2's ini folder requests. This will
fix problems with plugins failing to save settings on Vista/Win7 due to lack of
Admin rights, and also ensures all the plugin inis show up where you would
expect them to.
Fixed a couple UI bugs: FirstTime Wizard display bug and the "Configure..."
button in the plugin control panel grays out when it should.
Zeydl...
Sorry, could you be more specific -- what did you do with API? What GSsetSettingsDir should do?
Jake.Stine
>> Sorry, could you be more specific -- what did you do with API? What GSsetSettingsDir should do?
It's a bit hacky so to retain backwards compat. So I did it this way:
* Plugin should default to "inis/plugin.ini" (same as always)
* If PCSX2 calls setSettingsDir, it should override that default path (the inis/ part).
In the plugins I modded, I included a conditional for if the dir passed to setSettingsDir is NULL -- tho PCSX2 itself will never pass NULL. I just like to account for most possibilities up front... just in case, etc. :)
Jake.Stine
I will patch up zerogs in a bit. I planned to do it separately specifically so that you'd have an easier tome doing a patch compare for zzogl.
DanrleiS...
Parabéns. Os jogos estão mais rápidos. O sse 41 Esta otimo com o new vif.
kaboo...
broke lilypad! can't save settings anymore win7 release debug and devel untested.
Zeydl...
Incompilable again.
/pcsx2/gui/Panels/PluginSelectorPanel.cpp:247: error: ‘class wxArrayString’ has no member named ‘at’
arcum42
See the comments in r2362.

Revision 2362

Lilypad and PCSX2 ini/config bugfixes.
kaboo...
Lily pad can't save or load bindings (Win7)
kaboo...
broke already in 2361 for me
arcum42
Gcc doesn't like this revision either.
/usr/loc/usr/local/src/pcsx2-4/pcsx2/gui/Panels/PluginSelectorPanel.cpp:247: error: 'class wxArrayString' has no member named 'at'
arcum42
I think it's supposed to be:
panel.m_ComponentBoxes->GetConfigButton(pi->id).Enable(
(panel.m_FileList==NULL || panel.m_FileList->Count() == 0) ? false :
g_Conf->FullpathMatchTest( pi->id,(*panel.m_FileList)[((int)box.GetClientData(box.GetSelection()))] )
);
Jake.Stine
wxWidgets on the linux distros isn't built using std::string? That's... a potential problem. wxWidgets inhouse string class is not thread safe, it needs to use std::string to be thread safe... >_<
Jake.Stine
Oh, cancel that. I forgot that wx has a separate option for std::string away from all other container types. wxString uses std::stirng and all other containers may still use wx internal containers. Not ideal, but reasonable.

Revision 2363

w32pthreads: bugfix for minor race condition on exiting threads. Tech details:
the testcancel flag was being incremented after the thread had already canceled,
leaving the flag "dangling".
PCSX2: attempt at fixing what appears to be a belated thread affinity issue
during the cpuspeed detect.

Revision 2364

More minor improvements to cpuSpeed calculations, since my experimental fix
apparently works. :)

Revision 2365

newVif: non functional minor changes...

Revision 2366

GSdx:
- Added a macro that disables any upscale hacks.
- More work on the dx10 renderer upscale hacks.
PCSX2:
- Changed a warning so it reads more like a notice :p
diego...
Any news about decreasing the upscale glitches in dx9?
nexxus86
it doesn't fix the FFX upscale glitches at least:
http://www.abload.de/img/pcsx22009-12-2114-03-3zq8j.jpg
any chance to fix it?
andutrache
uberly satisfied with this Ar Tonelico 1 and 2 look better than ever.

Revision 2367

newVif: created a custom memcmp for the vif dynarec block finder... its faster
than memcmp, but not sure if it will be a noticeable speedup.
Should work in gcc Linux builds, but if not uncomment the memcmp() part in
newVif_HashBucket.h's "find()"...

Revision 2368

newVif: minor change, brought the nVifstruct down from 32bytes to 16bytes...
cottonvibes
'nVifBlock
not nVifStruct :D
tatsuy...
Clicking configure button for any plugin causes PCSX2 to crash.
Autor...
New Vif also fixes texturing problem in Crash of the Titans и Crash Mind Over Mutant *these games were totaly untextured *naked* before*
aleing...
your newvif, make me happy, look awesomme :D
cottonvibes
Autoran1: hah interesting. i just tried myself and the textures are indeed fixed in crash of the titans.
thanks for the info :D

Revision 2369

Fix Linux compilation (and I suspect a crash). Fix up some of the null plugins
so that they actually load in Linux.
arcum42
Well, maybe not a crash, thinking about it.

Revision 2370

Added preliminary screensaver disable feature. Cleaned up Vista/Win7 DWM code a
bit. Consolidated various win32 specific code into MSWstuff.cpp
Jake.Stine
I'm not entirely happy with the MSWstuff.cpp file. the DwmSetup.cpp and MSWstuff should probably be consolidated into one file, but I couldn't decide if I wanted it all in /windows, or in /gui. So rather than make a decision, I just made a new file :p
arcum42
In MSW_SetWindowAfter, don't you mean '#ifdef __WXMSW__'?
Oh, and MSW_SetWindowAfter( mainframe->GetHWND(), GetHWND() ); won't work in Linux, due to GetHWND() not existing.
azte...
yay for disabling screensaver. :)
Jake.Stine
MSW_SetWindowAfter( mainframe->GetHWND(), GetHWND() );
oops, it shoudl be GetHandle()
Both are the same thing internally. GetHandle is portable.
arcum42
All right, taken care of. You might want to doublecheck r2372, though, and make sure that MSW_SetWindowAfter works right on the Windows side...

Revision 2371

ZeroGS: Add support for GSsetSettingsDir.
Zeydl...
ZeroGS.def seems to be incorrect: to @38.
Zeydl...
Also you forget to remove block
#ifdef __LINUX__
char strcurdir[256];
getcwd(strcurdir, 256);
s_strIniPath = strcurdir;
s_strIniPath += "/inis/zerogs.ini";
#endif
from GSmain.cpp (287-292), otherwise it does not use correct ini file dir in Linux.

Revision 2372

Fix Linux up again.
Zatara...
I've been away from the project for a while, so I'm not sure if it's just me, but is the Linux branch broken? Because I can't build it anymore. Plugins build fine, though.
arcum42
If you've been gone for a while, currently the Linux version can't be compiled from the console. You actually have to install Code::Blocks, and open up the workspace file in the main trunk, and compile it from there.
The build files broke during the migration to wxWidgets, and weren't easily fixable. There are plans to put a new build system in, probably using cmake, but it's going to be a pain, and it hasn't been the highest priority.
The Linux port has broken 4 times or so in the last week, but that happens occasionally...
Zatara...
Ah, oh well. Based on the fact that I have no idea how to do any of that and that I basically learned how to use subversion from the original Linux compile guide, I'll just check back every once in a while to see what's up here.
arcum42
Installing Code::Blocks & wxWidgets is the tricky part.
Once that's done, you just open Code::Blocks, open the file "pcsx2-codeblocks.workspace", find pcsx2 in the list on the left side of the screen, right-click on it, and choose "Build". Or "Rebuild" if you're having issues.
And you can do the same for the plugins, or build them the old way.
Zatara...
Alright, thanks, that worked perfectly. The legacy build crashes when the plugins directory is set, but the debug build works as long as you don't try to change any of the settings around too much.

Revision 2373

w32pthreads: only half-fixed the cancellation counter before. This should full-
like fix it.

Revision 2374

Interface stuffs:
* Enable word wrapping on the console window (maybe could make it an option...
hmm).
* Slight bugfixes to main window/console focus linking (windows only)
* Fix linux compilation error in ZeroGS.

Revision 2375

newVif: Implemented support for partial-vector unpack transfers.
Games that were having problems with newVif should hopefully be fixed by this...
Fixes Gradius 5, and I think Tekken 5?
ramapcsx2
Gradius 5: fixed
Tekken 5: missing textures fixed, but really funny looking SPS remain
Harry Potter: still the same
Autor...
Tekken5 really has some funny SPS
tested more
With newVif fixed some little missing geometry bugs in Simpsons The Game
oldVif
http://img696.imageshack.us/img696/1458/old1.jpg
http://img687.imageshack.us/img687/9900/old2a.jpg
newVif *lots of SPS all over the game but i catch a little bit clean place*
http://img696.imageshack.us/img696/9506/newzq.jpg
arcum42
It fixed Ape Escape 3 as well.
azte...
yay for game fixes cottonm. :)
shadowladyngemu
Fixed X-men legends and Marvel Ultimate Alliance 2 as well.
tenderde...
wow nice work man, do you think you could see if you could fix the pink textures in Berserks interface?

Revision 2376

Re-implemented Ping() into wxApp, this time using Idle events (for once I found
a use for them!). This because the YieldToMain logic wasn't ever going to work
right since wxWidgets lacks a way to poll the event loop for pending events.
End result: More responsive GUI dialogs and junk. ;)

Revision 2377

Moved PADupdate() from MTGS thread to the GUI thread, and moved PADkeyEvent from
EEcore thread to GUI thread.
Rationale: I realized finally the point and purpose of PADupdate was to give the
PAD plugin a callback that's on the same thread as the GS window, and which is
(mostly) updated in regular sync to the refresh rate (50/60hz). So that's what
it does now, finally.
arcum42
The Linux port seems to have gotten fairly unstable on this version. Within a few minutes, an error:
Fatal IO error 11 (Resource temporarily unavailable) on X server
generally pops up, followed by the threads deadlocking, either immediately, or when closing the pad plugin.
Don't really have time to troubleshoot at the moment, though.
arcum42
This is both with OnePAD and with PADNull, btw...
Jake.Stine
Oh, I totally forgot about the legacy GSopen mess. I'll need to put a conditional in and call PADupdate from the MTGS when the old-school GSopen is in use.

Revision 2378

PadSSSPSX: Added to PCSX2 Suite, and updated to work with PCSX2 v0.9.7.
Changes: Implemented PADupdate and PADsetSettingsDir, added thread sync mutexes.
Note! This is based on v1.6 of SSSPSX, since we don't currently have v1.7 in
the repository. I did just realize that 1.7 comes with sources online, so I'll
upgrade the repository to 1.7 shortly.
Jake.Stine
Yay, [email protected] is the resident +1 fairy. :p
Jake.Stine
SSXPSX is actually broken in this rev due to some changes I made while running the wrong (old) version of the DLL, so I thought my changes were working fine (oops). I'll be committing fixes shortly, including the 1.7 upgrade.
zantezuken
Ah, I see my feature request ( Issue 142 ) partially done, eh? ;P
Great.
azte...
"Comment by Jake.Stine, Yesterday (22 hours ago)
Yay, [email protected] is the resident +1 fairy. :p"
well, if i understand what the update is about and i like it, always +1 i will put. ;)

Revision 2379

SSSPSX: Updated to v1.7, fixed savestate/freeze callback bug that caused the
public version to crash in 0.9.6 betas.

Revision 2380

* Call PADupdate from MTGS thread when using legacy GSopen -- Should fix Linux
Pad instabilities.
* Fixed a savestate loading bug, when loading states made with different
sets/versions of plugins.
DevNote:
* Moved some old PS2E types to PS2Edefs, since the new v2 plugin API won't use
them (freezeData, keyEvent).
arcum42
That took care of it...

Revision 2381

Add PADnull to the MSVC solution, and set eol-style:native props on PADnull and
OnePad.

Revision 2382

newVif: fixed some minor stuff...
DanrleiS...
Newvif não teve mudanças complementares.
leomar....
Can anybody do a new version legacy?
ramapcsx2
Well, I won't, and I doubt anyone else can be bothered to.
We'd much rather spend this time on perfecting wx.

Revision 2383

SSSPSXPAD: Fix for a random crashing bug when doing suspend/resume type stuff
(caused by multiple threads trying to initialize directinput at the same time)

Revision 2384

newVif: minor optimizations.
* Improved hashing slightly by ignoring the garbage values in the 'mask'
parameter when doMask is false.
* Wrote an inlineable version of the hash compare function, using x86
intrinsics.
Zatara...
Sorry about the misplaced comments, but I've been away from the project for a while. Neither the Linux nor the Windows versions of pcsx2 seem to compile correctly based on what's given in the compile guides. arcum helped me compile the Linux version the other day, so I was hoping that you could tell me what's new with the Windows version, Jake. Is there some new requirement for the building of pcsx2 now that wxWidgets has been implemented?
Jake.Stine
I don't think there should be. The new Compile Guide wiki (all 30 pages of it) should cover everything needed to get PCSX2 to compile. Mostly the dependencies are a handful of annoying opengl deps needed by GSdx for nothing in particular. (the actual code is incomplete and disabled)
Zatara...
That's weird, then. I'm getting compatibility errors from both VS 2008 and 2010. I'll do a little more poking around and see if I can find anything wrong here.
Jake.Stine
Paste errors and I'll translate them into what's wrong and how to fix.
Zatara...
Never mind, I got it to work by using VC++ instead of the other two. I've been wiping my computer a lot over the past few days trying to get a dual boot set up just the way I want it, so I can't really remember what the errors were before. I just remember that VS 2008 wasn't compatible with the 2008 sln file, and VS 2010 wanted to convert a bunch of files before building, which it did before giving me some other error. Oh well, not an issue anymore, anyway.

Revision 2385

SPU2-X:
- Slight adjustment on the timestretcher, stops it from going to "emergency"
mode too often (even on bigger buffers).

Revision 2386

w32pthreads: bad project linker setting caused occasional link errors and
possibly unstable behavior.

Revision 2387

newVif: I'm a terrible person. What started out at an optimization turned into
this.
* Optimized codegen of the VPU recompiler using displaced memory offsets (1-2%
speedup)
* Undid a lot of the inl stuff for more traditional cpp code layout (explained
below)
* Removed some redundant code and turned some macros into functions.
* Renamed a few things to VPU (Vector Processing Unit, which is the specific
name of the logic core that performs VIF Command Processing and Unpacking on the
PS2)
Jake.Stine
inl Rationale: There's only one notable template involved (vpu interpreter) so I didn't see a compelling reason to stick with the .inl files, and they were causing me all kinds of grief in trying to figure out complex compilation/dependency orders as I set up the new class-based dynarec.
VPU Rationale: The VifDma->VPU renaming is incomplete but I'd like to can continue the trend over time as we fix stuff. It's just a lot less vague and confusing when talking about "VIF" if we can either mean the actual processing of command packets, or the regulation and management of DMA transfers (which are two fairly separate concepts, even if they are somewhat married in the code itself).
Jake.Stine
Actually now that I'm looking at it, I got it backwards. The top level "VIF" part should be named VPU, and the unpacker should be VIF. >_<
Bleh. This is why code reorganization is a feat oft unattempted by anyone.
azte...
"newVif: I'm a terrible person."
yes, you are. But we forgive you. ;)
ramapcsx2
Wait, isn't VPU another term for the VU's? :D
cottonvibes
technically VPU is the vif+vu unit, but lots of times used as alias for VU's.
imo we shouldn't use VPU as the prefix for the unpacker since its confusing xD
aruan...
wow having to re-write the macros to functions that was a good one... anyone doing some mess before that you had to repair his mistakes????
anyways good job Jake.Stine
Atho...
A Typo slipped in this revision. Breaks compiling with CodeBlocks.
(diff/patch)
Index: pcsx2/Linux/pcsx2.cbp
===================================================================
--- pcsx2/Linux/pcsx2.cbp (revision 2388)
+++ pcsx2/Linux/pcsx2.cbp (working copy)
@@ -518,7 +518,7 @@
<Unit filename="../x86/VpuUnpackSSE.cpp" />
<Unit filename="../x86/VpuUnpackSSE.h" />
<Unit filename="../x86/VpuUnpackSSE_Dynarec.cpp" />
- <Unit filename="../x86/newVof_Unpack.cpp" />
+ <Unit filename="../x86/newVif_Unpack.cpp" />
<Unit filename="../x86/microVU.cpp" />
<Unit filename="../x86/microVU.h" />
<Unit filename="../x86/microVU_Alloc.inl" />
Athos
ramapcsx2
aruantec:
It wasn't a mistake, just a choice of style.
Jake thought making those functions would be better, so he did. Simple as that :)
aruan...
@ ramapcsx2:
aaaa got it... it happen to me sometimes too and i end up re-writing a lot of code :) anyways good job guys and keep up the goog work.
Jake.Stine
That's what I like to do really. I fix, clean up, and optimize existing code. I'm pretty lousy writing my own code, usually.

Revision 2388

Forgot to disable newVif again (overall compatibility is still too low for
enabling).

Revision 2389

Fix Linux compiling (with newVif disabled).
arcum42
With newVif enabled, it gives the error " error: invalid cast of an rvalue expression of type 'long long int __vector__' to type 'float __vector__&'
in newVif_HashBucket.h. If I change:
int result = _mm_movemask_ps(
(__m128&)_mm_cmpeq_epi32(_mm_load_si128((__m128i*)&bucket.Chain[i]), _mm_load_si128((__m128i*)dataPtr) ) ) & 0x7;
to:
int result = _mm_movemask_ps(
(__m128) _mm_cmpeq_epi32( _mm_load_si128((__m128i*)&bucket.Chain[i]), _mm_load_si128((__m128i*)dataPtr) ) ) & 0x7;
It compiles, but when it goes to recompile blocks, I get "Out of memory re-allocating hash bucket (bucket size=1)" errors.
tatsuy...
Sky Odyssey flickers a garbled texture then I get a runtime error and crash, this is with newvif. Oldvif so far not affected and still running same since I posted in earlier revision.

Revision 2390

Take care of Issue 512 .

Revision 2391

Undo VPU renaming, Vif was better for this originally. >_<
Jake.Stine
Arrgh, I forgot to disable newVif again. Jesus I hate ifdefs. I'm about 20 seconds away from making it a GUI option. :p
Jake.Stine
Cotton: Also, this is my last vif code change for a while, unless I make newVif a gui option (which wouldn't modify anything important). So feel free to do whatever you want while you're away, without fear of conflicts when you get back (in the event you don't have inet access for some reason).
Jake.Stine
Ok, I lied, I found a couple bugs to fix. Commtting.

Revision 2392

newVif bug fixes (mostly related to the interpreted version), and switched it
back off again. >_<
Jake.Stine
Ok this should pretty much do it for me for a while, regarding VIF.
There's one more optimization I'd like to try, but it's not important, will probably suck, and so I'll do it later (like a week or two later).
arcum42
Just as a note, newVif is a bit brokenish on Linux right now. It seems to want _mm_cmpeq_epi32 cast to (__m128) in newVif_HashBucket.h, instead of (_m128&), and doing so nets me "Out of memory re-allocating hash bucket (bucket size=1)" errors all over the place.
Presumably broken in r2384, though I noticed it in r2387...
arcum42
Oh, the cast was because currently if you try to compile with newVif set to 1, you get the following error:
newVif_HashBucket.h:57: error: invalid cast of an rvalue expression of type 'long long int __vector__' to type 'float __vector__&'
matsur...
on/off/on/off/on/off... driving me nuts.
my.b...
just curious, what exactly Vif stand for ?
Jake.Stine
@arcum: the out of memory error is unrelated, I'll fix.
The other error is annoying. msvc forbids that (__m128) direct cast, which is why I had to use a reference handle instead. Guess it's macro time.
toammar2...
Check From R2375 To R2392....
Positive Games on newVif:-
WILD ARMS F
http://i260.photobucket.com/albums/ii31/AMMARPB/WILDARMSF.jpg
Negative Games on newVif:-
BEACH KING STUNT RACER
http://i260.photobucket.com/albums/ii31/AMMARPB/BEACHKINGSTUNTRACER.jpg
BREATH OF FIRE DRAGON QUARTER
http://i260.photobucket.com/albums/ii31/AMMARPB/BREATHOFFIREDRAGONQUARTER.jpg
DEATH BY DEGREES
http://i260.photobucket.com/albums/ii31/AMMARPB/DEATHBYDEGREES.jpg
NARUTO TIMET HERO 2
http://s260.photobucket.com/albums/ii31/AMMARPB/NARUTOTIMETHERO2.jpg
NARUTO ULTIMATE NINJA
http://i260.photobucket.com/albums/ii31/AMMARPB/NARUTOULTIMATENINJA.jpg
R RACING EVOLUTION
http://i260.photobucket.com/albums/ii31/AMMARPB/RRACINGEVOLUTION.jpg
SYPHON FILTER
http://i260.photobucket.com/albums/ii31/AMMARPB/SYPHONFILTER.jpg
Tekken 5
http://i260.photobucket.com/albums/ii31/AMMARPB/Tekken5.jpg
VIRTUA FIGHTER 4
http://i260.photobucket.com/albums/ii31/AMMARPB/VIRTUAFIGHTER4.jpg
VIRTUA FIGHTER 4 Evolution
http://i260.photobucket.com/albums/ii31/AMMARPB/VIRTUAFIGHTER4Evolution.jpg
kaboo...
@toammar
you do realise that the new Vif is not complete yet and is by default deactivated?
it's like a teapot in the making ... you simply shouldn't try to drink from it yet -.-
arcum42
Thought it might have been, but I wasn't sure, since it wouldn't compile for me without the change...
Does seem like gcc is giving us a lot of grief about casting recently.

Revision 2393

Fixing some more bone-headed project file compilation errors (my fault, don't
know what I was thinking when I did this w32pthreads lib change int he first
place)

Revision 2394

ZeroGS: Move most of the X11 window code to one file, to make it easier to
switch from using an X11 window to a Gtk window.
arcum42
Switching to GSOpen2 is going to require putting our OpenGL context in a Gtk window, so this puts most of the code that would have to be changed in one place...

Revision 2395

Linux: Fix bugs in _aligned_realloc and newVif's inlined SSE HashBucket finder.
arcum42
That took care of both issues...
arcum42
BTW, is there any good way to tell the pad plugin whether GSOpen2 was used or not? I'd like to set up the pad plugins in such a way that it's possible to start switching GS plugins to GSOpen2 without switching all of them at once (since I don't have control over the most important one Linux uses.)
And the main barrier to switching is that the pad plugins currently expect a X11 display, and crash if they get something like a Gtk window instead...
Jake.Stine
In Windows there's a function to check if a window handle is a valid Windows handle or not, ie something like
if( !IsWindowHandle( hWnd ) )
// must not be MSW..
I dunno if GTK or x11 has something similar. If so, that'd be your best option. if not, then you'll need to hack up some special PADopenGTK() call just for linux and have PCSX2 invoke that when GSopen2 is in use. (yuck, but oh well).
arcum42
Now that I think about it, I seem to recall trying the first approach originally with GTK_IS_WIDGET. Seem to recall it not working, but I'll try messing with it that way.
And if I do hack up a special call, I'll try to see if I can make it somewhat more useful then just this one case.
I was just hoping I was overlooking something simple. The other thing I've been thinking about is wxWidget plugins. Since we are sharing the plugin directory with the legacy gui, it locks us somewhat into having legacy guis on the plugins.
For the moment, I was thinking about adding a define to the headers to indicate to the plugins that this is the wx version, and providing some sort of a call to pass the main app instance to the plugins, so that they can grab it and use it for their configuration dialog.
Though, come to think of it, we could just have pcsx2 pass a dialog along to use for configuration, the same way that GSOpen2 passes a window. That might be easier and work better. I'll have to think a bit about that...
Jake.Stine
>> For the moment, I was thinking about adding a define to the headers to indicate to the plugins that this is the wx version, and providing some sort of a call to pass the main app instance to the plugins, so that they can grab it and use it for their configuration dialog.
Won't work in MSW. :( All of wxWidgets is "complex" types, and so unless the plugin and the main program are compiled with exactly the same everything:
* compiler version
* debug settings
* optimization settings
* other header/stl compiler options
* etc...
... the layout and content of the classes and their STL containers they use will change, and result in weird and unpredictable behavior any time the DLL and the main EXE try to exchange wxWindow handles or pretty much anything else wx offers.
Under linux, .so files are hybrid static/dynamic mixes, so wxWidgets design ends up working a little more reliably. Though significant changes to compiler/libc version could still rear up ugly behavior if written code ever deviates from using wx-provided accessors (which it does, since we make frequent use of extending base classes into more complex types).
Passing native window handles and using clever wxWidgets tricks like SetHandle to force it to manage the window will work better, but could still be wrought with annoyances. In windows you'd have 2 instances of wxWidgets trying to manage the same window's events (unless PCSX2 is sure to detach everything before passing it to the plugin). On Linux I think they may share the same instance of wxWidgets library so it might work better. On the other hand they may not, if plugin uses an older version of wx or something. So it's again a dangerous assumption to make. :(
Honestly, wx is built from the ground up to be a statically compiled convenience layer over top the existing window manager, as is C++ since the language itself refuses to define any sort of concrete layout for complex class types or STL container implementations. We really can't use any of the magic provided b either in cross exe->plugin communications.
Bottom line: we just can't share wxWidgets types. Too risky.
Jake.Stine
The GSopen2 approach works because PCSX2 manages almost *everything* about the GS window. The only thing the GS plugin does is paint to it, and the only thing the PAD plugin does is intercept the window's messages via native window manager hooks (both of which have already resulted in minor complications even as simple as they are).
Passing a configuration dialog means giving the plugin almost full control of the window -- to handle input, child windows, etc. But wxWidgets of the plugin will only be aware of the child controls it creates. Likewise, the wxWidgets of the plugin could shut down the window, or other children in the window unexpectedly as part of its built in convenience helpers -- and cause the wxWidgets of the EXE to crash when it tries to do its own cleanup.
Though speaking of GSopen2, I fear I still have a threading issue that needs to be resolved. On Windows, Direct3D/DXGI's "Present" is thread safe, so you can blit to a window that's on a thread separate from your own (in our case, MTGS->GUI). I fear Linux/OpenGL will be a bit less forgiving. But since it's *really* hard to fix in a clever and efficient manner, I'm just going to play dumb and hope it works... and worry of fixing it later, only if it doesn't. :p
Jake.Stine
Well, on second thought, the passing of the configuration window *might* work, if we make sure and pass an empty child panel of the configuration frame. Although the plugin would need a whole set of APis for communicating with the main window for:
* OK/Cancel/Apply buttons
* Main Window size changes
* Possibly Main window appearance options
... eh, starting to suck now. Never mind :p
arcum42
All right, so it's feasible, but not particularly desirable.
Oh well, I was just hoping we could do something about the mess we have for plugin guis. Maybe we should just do one simple configuration panel, designed only for plugins that didn't otherwise have one.
Pass it the name of the plugin, it displays a panel with a 'Logging' checkbox, and passes the value of that back to the plugin. Then we remove the gui of every null plugin we have in favor of it.
Jake.Stine
Hmm, yeah, that pretty well makes sense to me.
If we want to extend it slightly, without getting too complicated, the built in config panel can read from a list of simple checkboxes. Don't think I'd want to add anything more complicated than checkboxes (any plugin needing radio buttons, orgroup boxes, list boxes, etc, should have its own gui probably).
But that way a plugin could at least, say, have 2 checkboxes if it needs it.
arcum42
That'd be good. That would handle all the null plugins, and ZeroSPU2, as well as any new plugins that we are developing until they get complex enough that they need a real dialog box.
So we pass it the name of the plugin, names of all the checkboxes, and their default values, and get back the new values of the fields.
I've thought before about actually building the null plugins into pcsx2, too, so that you don't have to have any plugins for pcsx2 to work. Thing is, I like having the null plugins there to base new plugins on...
Jake.Stine
Yeah we discussed integrating the nulls into pcsx2 on irc a couple times, but decided against it. Not really enough compelling reason to do it.
arcum42
Yeah, and often the null plugins have enough code in them to give you a good start on making your own plugin. That's something I'd like to improve, actually.
I actually did grab dev9null recently, and start messing with it, basically reimplementing MegaDev9, mainly because I wanted to fiddle with an internal hard drive on pcsx2.
I suppose I could have just ported MegaDev9, but this is more fun...

Revision 2396

Thread Local Storage Fixes:
* Implemented TlsVariable, a nifty alternative to __threadlocal, suitable for
archaic operating systems that don't have native TLS support (namely Mac OS/X).
* Added a forced reference to TLS in AppInit so that TLS is sure to be
available to DLLs (otherwise windows doesn't init TLS by default).
* Disabled TLS support in the x86emitter by default, since it's looking
increasingly like we won't find a use for multithreading PS2 sub-components (can
be re-enabled later if spontaneous brilliance at a later date proves me wrong).
wisestud...
Hello.It looks the lastest version of ssspsxpad is broken.It will crash,when you setting pad bottom...
heatbla...
I know it`s not the place, not the thread, but... Merry XMAS and thank you all for your efforts! May the XMAS force be with you!
system.compiler
Merry X-mas.
Enjoy the times
nov...
This revision and later seems to crash on my system.
AppName: pcsx2.exe AppVer: 0.0.0.0 ModName: msvcr90.dll
ModVer: 9.0.21022.8 Offset: 00036678
Jake.Stine
@novax:
>> This revision and later seems to crash on my system.
Sounds like it could be a plugin incompatibility with older plugins. Post a screenshot of your plugin config window. Also if building pcsx2 yourself, do something for me:
Jake.Stine
@novax:
oops, second part of the message got lost in my post-editing :p
(a) make sure and full rebuild everything. I changed a lot of headers, and MSVC's depedency checking might have missed something.
(b) Compile and run a Debug build instead of Release. See if it changes the behavior.

Revision 2397

Bugfix for assertion breaks not working in Devbuilds.
newVif:
* Bugfix to HashBucket::find() cuts microprogram caches misses in half.
* Dynarec version now uses alternating XMM registers for unmasked unpacks (very
minor speedup, ~1%).

Revision 2398

We'll need to include signal.h if we're raising signals.

Revision 2399

ZeroGS: It'd help if I modified the project file to reflect the new file... :(
arcum42
I had modified it, actually, but codeblocks doesn't automatically save project file changes when you compile. Not the first time I've run into that...

Revision 2400

newVif: last bugfix was crappy. This one actually fixes the bug without
introducing another similar bug in the same line of code. :p

Revision 2401

GSNull uses GSOpen2. Hacked Openpad to work whether GSOpen or GSOpen2 is used.
arcum42
Onepad, that is, not openpad.
arcum42
And basically what I'm doing here is first, I stuff pDsp into a GtkScrolledWindow, and test if it's a Widget. If it isn't, then we have what we normally expect, a Display* variable, and we can relax.
If it is, we just grab the Display* of whatever window is at the front at the time instead, mainly because while I know how to obtain a Display* from a GtkWindow, a GtkScrolledWindow is an entirely different matter.
And GSNull now uses GSOpen2, though I haven't implemented it on Windows. For that matter, I haven't actually put any widgets in the window, to verify that it will work.
arcum42
Thinking about it, openpad isn't a bad name for a pad plugin. If I feel like changing it at some point, that might work... :)
Jake.Stine
If you want to be really confusing you can rename the ZeroGS hacks version to OpenGS. :p
arcum42
^_^
Trouble is, I haven't really done enough to it to justify a new name.
What I get *really* tempted to do is do a fork of ZZOgl, so that it is in-trunk, keep it up to date with the main branch, and apply any changes on the main branch there.
Then I wouldn't feel quite as silly doing infrastructure work on a plugin I never use, so it can be copied to a plugin that I do use, but don't have svn access for.
Of course, I get tempted every so often to use GSNull as the base of a new GS plugin, too. There's just so much that would need to be done that I never seem to get the time for it.
ivicamar...
Don't know what you did, but from this version FFX pal works again. +1

Revision 2402

PS2E v2 (plugin interface) tweaks and additions.
Zeydl...
Poor me :-). Could you give a brief comment, what API part was changed? Olny functions names.
kaboo...
"The drawback is that every geeks' dream of having 6 different games emulating at once, with each output texture mapped to the side of a rotating cube, will probably never come true. Tsk."
I love it ^^
azte...
tweaks and add-ons are cool. :)
kage.urufu
Awesome commit, __fastcall is perfect for this, and non-supporting compilers arent needed anyways, MVC or GCC is all I see PCSX2 compiled with regardless
Jake.Stine
Zeyd: mostly function names and comments, yes. Tho I did redefine the OSD/HUD options to be simpler. We had brainstormed something more complicated but drk had a very compelling reason for not following through with it, so I rolled it back to a more basic text/icon design.

Revision 2403

GSdx:
- Bring the latest upscale hacks to dx9 mode as well.
azte...
nice stuff ram, btw, Gabest gave up his plugin? :|
jfre1...
He allowed it to be part of pcsx2 dev plugins from memory. And that was a fair while back. Not heard anything from him since then.
diego...
yesss,this is what i was waiting :P

Revision 2404

Whops :p
NEOAethyr
Hi, sorry to say this but this ver is much slower on xenosaga 2 (us), then build 2402 was.
The title screen and some other parts of the game are effected.
Same exact settings with the 2 builds, the older one plays smoothly on a dual core @2.7ghz, while the new one chugs hardcore.
DX9, in windows 2k3(xp).
Majorally Offtopic...
The gui, specifically the plugin selector, crashes with certain plugins.
2 plugins don't work, one of a sound one, and the other a controller plugin, crash the emu when selecting.
Save states, F1-F3 keys work, but the gui part doesn't (seems like it can change the slot though).
When sound is enabled, the emu can deadlock when exiting, and it does quite offen.
Most games need the sound plugin, even when it's set to output no sound, it works fine.
But alot of games won't start or fail shortly ingame when there is no plugin setup for sound (irq???).
Also noticed some sound distorion.
I think the latency needs to go up just a tad, around 20ms should doit.
Totally impressed by the emu so far btw.
If you guys were to fix one game, please let it be xenosaga 1 us, it now skips the intro and goes to a black screen where I can bring up my status menu.
It totally doesn't work right, and it wasn't working in the 0.9.6 version either :(.
One more thingy, there's a texture flickering/banding effect going on with alot of games.
A good example would be grandia 2 extreme.
It's not the interlacing stuff.
Please check it out, seems to effect xenosaga2 as well off and on.
Sorry for the long post.
I can't compile it myself othrwise I'de try to do some of the fixes myself.
Stupid vc++ won't install over bits service being removed :(.
I wish there was a presetup windows gcc env for this emu so I could compile it. :\
Err...
Um, the 2 largest speed probs from what I've seen so far are:
Sound output (when it's allowed to output sound).
And the internal texture res thingy.
If those 2 could be sped up, the emu would get 1/4 more of the fps I think.
andutrache
nice i would love to try this but since my OC broke something on the motherboard i'm having trouble booting the pc even at stock speeds, so much for playing games on pcsx2 for me until i get a new MB.
tenderde...
yeah and for the luv of god fix the broken textures in berserk :P
ramapcsx2
Speed did not change for me. There is no reason it should change either.
All your offtopic bug reports are not helping really.
We don't need vague hints like "there was some distortion", when you don't even mention the plugin used, nor the game played.
Also: Xenosaga 1 to 3 all work, they always did.
I know about the Grandia Extreme bug, it's just this game that has it though.
system.compiler
I can't compile pcsx2 myself.
I got someone that i really trust(and understand) about it to compile it for me(poor me :-().
I'm pcsx2 lover n' will test myself.
I really concern about speed(due to my low spec) but i really loves what the dev done because i believe they have done the best thing for it.so the speed isn't really the problem.
Just wanna supporting pcsx2.
I can't help with the donation...
So i'll help with testing(too bad i just had few gust game n' ff series).
This build gave me no problem(i can give my screenshot,my spec and anything required but i believe it isn't necessary as i didn't get the problem from this rev).
+1 for this rev.
I'm sorry for the off topic and forgive my english as i'm indonesian and my english is terrible(writting this post took me almost an hour :-D .i love my dictionary)
"a Pcsx2 supporter"
NEOAethyr
Again I want to say how impressed I am at the progress of this emu :).
Thanks ;).
Sorry, I don't wan't to piss you off, I just want to report this stuff, then I'll feal at ease lol :).
http://rapidshare.com/files/328128604/Desktop.rar.html
xs2-1.bmp
Banding/flashing like effect on textures(hill) in top left corner.
xs2-2.bmp
xs2-3.bmp
Banding/flashing like effect on textures(grass) on top of screen.
xs2-4.bmp
xs2-5.bmp
Banding/flashing like effect on textures(log) on top right of screen.
xs2-6.bmp
Various 3d-texture? corruption or alignment issues?
Noticable in battle with char icons, text menu's and such
I don't believe it's the aspect ratio code that's causing it.
Because regardless of what your settings are, it still happens.
xs2-7.bmp
All save point images in the load manager thingy are corrupted or plain aren't displayed right.
xs1-1.bmp
Black screen, what you get when you start the game, no new game intro anymore either, it just does this.
I've tried walking and such..., nothing.
xs1-2.bmp
You can use the statues menu and pause the game too.
The status menu shows somethign wrong with the colors or transparency bits.
Regardless of what you have for an interlace filter, it also doesn't flash when the filter is off.
xs1-3.bmp
What happens when you pause the game at the 1st screenshot.
This game is broken, the only diffrence any ver of pcsx2 has done was that with older ver's, the new game intro played, this ver just skips right past it like a hack.
Not unless it plays with dx10 or something.
Otherwise, regardless of plugin, it does the same thing, it bums me out.
This screen is supposed to transparent over top of the original screen, I dn what is really going on with this.
g2x-1.bmp
The shadows show the same banding like issues in grandia 2 extreme that were in xenosaga 2, exact same thing, just a diff shape in this case.
There's also tons of transparency issues in the game, I'm sure you allready know that...
It happens all over in game on diff textures.
g2x-2.bmp
Is it just me or are the colors being clamped down?
Are you guys trying to keep a ntsc type of color going or something?
I did try vsync with the various probs I meantioned, it doesn't fix them.
There is one thing I want...
A fps counter, I'de like to see what fps I'm getting with all of the plugins.
SPU2-X is the sound plugin that's crashing the emu.
I cant' even try it.
So tha only plugin I've used in the current ver's is ZeroSPU2.
It seems like a buffer prob to me, static caused by not having enough buffer.
To large of buffer and you'll add lag, but it seems whatever it's using now, isn't quite enough for everything.
I'm not talking about skips, I'm talking static from directsound, overruns and underruns.
I'm pretty sure..., I don't know of any exact spots in games to test for it though.
But I'de be willing to check if needed to.
And I swear that 2404 is much slower then 2402 on my system.
Way slower.
If it was min I wouldn't of said anything.
It mainly effects the title screen and the intro on a new game.
The rest, in game wise, seems to be about the same as it was before.
Even with the native texture res, it's dog slow are those points, where r2402 was smooth even at higher texture resolutions.
Tekken Tag...
Major 3d graphic problems.
Slow, way slow, the oringal arcade ran on ps1 like hardware, but this is very slow.
Looks like it has timing issues even with no speed hacks enabled, not 100% sure though.
The timing could be related to the sound plugin though, because it needs it to even get to the title screen.
Soul Caliber2, doesn't start, dma issues?
Maybe all of that stuff is known, if so I'm very sorry but I just wanted to make sure.
ramapcsx2
Ok, SPU2-X first. Did you try dsound over xaudio2 yet?
The buffer size I set is fine for all systems with drivers installed / working properly. In fact you could halve it and it'd still be fine.
It should especially not crash the emulator. Something is very wrong here.
All your screenshots:
Well, you're using dx9 mode, so you get free z issues. I know Xenosaga 2 has them (and xs1 and xs3 as well, i bet).
xs2-6.bmp: You mean the upscale glitches on letters and such? Those are the ones I'm trying to fix btw.
Your xs1 must be some strange version, it works for me (and others).
shadowladyngemu
xs2-1.bmp until xs2-5.bmp: looks like you have "logarithmic-Z" disabled, enabling it will cause other problems tho and it will probably look right only with (Software) or D3D10 (Hardware) renderers. Additionally xs2-4 and xs2-5 don't look like you were using 2404 at all because of that border on the right and lower parts of the screen.
xs1-1.bmp and xs1-3.bmp: the game works and has worked since I can remember, I bet it's a bad ISO and if you're trying to read it from disc, try it from ISO. The game does work, it can be pretty slow but it works this is not really a support area place to get your game working tho.
NEOAethyr
Thanks guys, I know this isn't a forum so I'm trying to keep this brief.
I hope I can give you some good feedback on that upscale stuff later :).
Whenever I try to select "SPU2-X", it crashes the emu, closes right out.
When I hit apply, or ok, that's when it crashes, I can't even config that plugin because it's greyed out until I hit the apply/ok button.
I must be missing something.
I have the latest dx redist, realtek hd drivers,... I dn.
I thaught maybe the gui was being worked on and that was causing the plugin crashes.
But maybe not.
I should try it in win7 tonight.
That will also allow me to check the fixed upscaling in dx10 mode and compare it to the dx9 code being worked on now :).
"ZeroSPU2 r2361 0.4.6 [ZeroSPU2]", that's the one I'm pretty much stuck with.
Time scaling enabled, seems to buffer better on avg.
Real time mode enabled..., prevents inf sound loops that happen at faster speeds sometimes.
Mute gives a speed up, but it can still deadlock the emu once in a while when exiting.
Thanks for explaining to me about the z issue thing. :)
I'm defently still getting the upscale glitches.
With both 1x and 2x modes, I checked both r2402 and r2404.
In native mode there gone, no probs.
What may I ask is native mode set to, what res?
I would assume the native resolution for the ps2 it's self is 720x576/480 or something simuler.
Or maybe 512x384.
I dn what the max texture res is though, I would assume at least 512x512.
Which seems alot like native setting, but I'm not sure.
I just want to know so I can go about changing it in a more precise way.
1920x1080 d3d texture res is so nice, but I know it can't be the right aspect or an equal multplier.
My build says r2402 dec 27 even though it's supposed to be r2404.
I got it from here:
http://cid-ec92aae47a89073b.skydrive.live.com/browse.aspx/Emulation/Pcsx2?view=details
I'm thinking I got a funky build from the place I dl'ed...
My xenosaga 1 id is: SLUS-20469.
I'll try a iso of it later on tonight I guess.
Maybe it's pete's dvd plugin that's the prob.
If you have a diff id for xs1, please tell. :)
NEOAethyr
Xs1 worked after I dumped the disk to an iso and used the internal iso loader, no plugin.
I was using pete's dvd plugin when it wasn't working.
It works great, it's faster then xs2, logical z setting thingy fixed most of the glitches/missing text.
Freaking awesome...
I'm gonna have to find another place to dl this rev though so I can be sure of what caused the slowdown's I'm seeing.
I've got a nice 2402..., but the so called 2404 I have doesn't have the changes it supposed to have it seems and it's way slower.
I just compared the exe's, and that are identical byte by byte.
So only the plugin changed I would guess.
Yep.... my r2404 says gsdx 2404.
I just verified this too, if I copy the older plugin to the newer emu folder and select it.
It's fast again, all good.
GSDx r2393, it's what came with my r2402.
Also, the gsdx r2404 plugin isn't fixing the upscaling issues in xs1 (very few at the begining so far), and xs2.
Not sure or not if it was your code or because of where I got r2404.
Sorry for spamming ya.
ramapcsx2
Ok, I've compiled 2 gsdx.dll. Please test them both, and report back if one is (significantly) faster than the other.
http://rapidshare.com/files/328345914/gsdx_test.7z.html
ramapcsx2
Oh, and use fraps to measure fps.
http://www.fraps.com/
azte...
heh, these surely are well made bug reports, congratulations for all of you who submitted a report, ram, i'll give +1 for the 2 dlls. ;)
ramapcsx2
Yes, and my nick is rama, thank you. :p
Jake.Stine
Pcsx2 needs more rams!!
(this is so horribly offtopic already, what the harm?)
tom.mat...
*ahem* I just wanted to ask if there will be any improvements in Hardware-Buffering and Bloom? Newest revisions causes some glitches when in comes to ingame-screenshots (ex: Shadow Hearts 3 in battle). Also most of the blur effects are rendered in foreground (Z-Buffer ignored)
NEOAethyr
Compared both by eye, hacks on and off, and there is no major speed decrease in the intro of xs2.
So the rev I dl'ed originally had a messed up gsdx plugin (at least for me...).
No slowdowns :).
The plugins you compiled are nice, faster then the ones I had too.
Just no fix for scaling yet it seems.
http://rapidshare.com/files/328604311/Desktop.rar.html
hacks-on.bmp
hacks-off.bmp
Xs2 status menu thingy.
The upscaling is still causing probs, and the results are the exact same.
hacks-off native mode.bmp
Showing native mode with the hacks off rev of the plugin.
Works fine when you're not scaling it up or down.
I used a texture res of 2048x1792.
That's my crappy hardware triliner filter on the native mode screen btw.
Didn't try with with hardware filtering off (driver filtering not the plugins).
512x448 looks close to the right res but it seems off.
And xs1, it seems right for that game too but there's odd parts of the game where they have odd filters meant what seems for a higher res.
Capcom vs snk 2 seemed to be 640x448, but then again I might be wrong.
SFEX3, I can't really make heads or tales.
I don't even think native mode is quite right on that one.
That game has a messed up glitche for one of it's female char's..., (wtf lol...)
nexxus86
i have a problem getting GSdx into fullscreen mode, DX9 and DX10,
tried options like "default to fullscreen", deactivated windowed mode, and even alt+enter doesn't work.
doodhwal...
what counts is effort. while gabest is nowhere to be found, let's support rama.:)
NEOAethyr
@nexxus86
I don't have that prob.
In gsdx:
Resolution: "Please select..."
Windowed: Enabled
It starts up as a window.
I can double click the titlebar and it'll fill the screen.
I can press Alt+Enter and it will full screen to my desktop res (my lcd's res of 1920x1080).
I like it like that lol...
I don't have to worry about the refresh rate, display timings, or nothing.

Revision 2405

GSdx: A few minor cleanups to nudge GSdx a little closer to being cross-platform
compatible,
arcum42
Not as big as a commit as it looks, since it now uses _aligned16 instead of
__declspec(align(16)), and that was in a lot of places.
And I don't usually mess with GSdx, but I thought it'd be worth starting to get as much as possible of it compilable with gcc.
(I committed this while in Windows, though, since I didn't want to chance breaking compiling...)

Revision 2406

GSdx: Just committing this so I don't have to recreate it at some point.
ramapcsx2
Good luck with this, arcum :)
arcum42
Thanks. Not sure how far I'll go with it; I pretty much figure that every so often I'll go by it, and try to figure out how to fix a few more of the errors.
Eventually I'm hoping to get it to the point where it will actually start up in Linux using the Ogl code, but that's a long way away. I imagine SPU2-X will be working before then...
arcum42
One of the big issues is that gcc tends to not allow you to do things forbidden by the C++ standards committee, where Microsoft lets you get away with them.
For example, I get a bunch of errors about those GSVector variable types being used in structs and unions because they have constructors. I suspect fixing that would take a bit of rewriting...
ramapcsx2
Yeah, if you need to change that you can basically rewrite all the code.
arcum42
That's what I figured, so I'll probably backburner it for a while. There's plenty of other things for me to work on, anyways.
NEOAethyr
Hey dudes, can you compile a complete windows build (excluding the installer) on linux?
Otherwise I'll have to install windows again, well twice actually...
I don't want to I'de rather install win7 but I need a need dvd burner (I can't read my win7 disks with this old dvd-rom).

Revision 2407

Mucked around with Elfheaders a bit. Cranked up the number of chars in DisR3000A
(Because I own a few games with symbols over 64 chars). A few other things.
Jake.Stine
Hrm, it looks like a whole lot of tab chars got turned into spaces in this commit. I'm not sure the best way to handle that in the future, or even if it needs to be addressed, since up until now it's never been a problem. Having mixed tabs/spaces in source files is a mild annoyance only (like expecting your cursor to move a tab when it only moves a space or vice versa) -- but the bigger one is the huge red areas in the diffs where only whitespace has changed. ;)
I will say that having mixed space/tab chars in the source files is to be discouraged, since different editors handle them differently, for example if I edit something and add a tab to it, and you get something like this:
"[code]..\t\t// text" (where . is a space and \t is a tab)
... it ends up with different alignment in different IDEs (go figure).
MSVC defaults to using tab chars on C/C++/C#/etc files, so that's why most everything has been using tab chars up to now.
Jake.Stine
(the other reason I mention it is because I have a few mostly-cosmetic changes to elfheader.cpp in another branch of mine and now I have to diff it by hand pretty much >_< )
arcum42
I'm going to chalk that mostly up to Code::Blocks. ElfObject is now a class, so a bunch of functions that were in the struct got moved one tab to the left. That *shouldn't* have turned the existing tabs to spaces, but it seems to have.
I may very well re-indent those lines, because I don't like the spaces in there either...
arcum42
The change to VU.cpp is just something I was playing with based on the comments, incidentally. I was curious if all calls to vu0Finish could really be replaced with _vu0WaitMicro. Seems like it.
Something interesting I noticed when testing the Elfheader changes, btw. I have an iso version of uLaunch.elf (as well as the normal elf version), and it boots properly with the skip bios hack on, but with it off, it just goes to the bios screen.
The disc shows up in the browser in the bios, but if you try to boot it from there, it just goes right back to the bios main screen again. It's something I'll have to track down one of these days. (And yes, I checked an older version, and it's preexisting behavior.)
I also managed to trigger the 'not a playstation or playstation 2' screen once accidentally with one of my code changes. That's the origin of one of the warning comments I added. ^_^
ramapcsx2
I'm not so sure about that #define USE_WAIT_MICRO beeing undefined.
What makes you sure it's good? ><
ramapcsx2
Oh, never mind me. I thought it was doing _vu0WaitMicro() before :p
arcum42
Nah, just thought I'd test how accurate the comment above it was about how any function using vu0Finish should be using _vu0WaitMicro...

Revision 2408

Fix messed up indentation from the last commit, turning spaces back into tabs.
arcum42
Think my search and replace hit a spot or two I didn't mean to, but it's mostly back to normal. More importantly, I found an option in Code::Blocks that was off that should have been on, and turned it on. That should take care of the issue in the future, hopefully.

Revision 2409

A couple dozen user interface refinements; notables:
* Implemented GS window hiding on suspend (option was there, but not tied in)
* Added Frameskipping options
* Added option for disabling all GS output, for benchmarking EEcore stuffs.
chuuey
hey jake thanks for the update, i have a few problems with pcsx2 since the last few svns i can't tell exactly which version, but here's the deal: i start pcsx2 latest compile, after i click next on the plugin selection the emu hangs for a few minutes but i noticed it starts to write a lot of data into the log file check this out:
http://files.myopera.com/chuuey/albums/830695/log.jpg
after that the emu windows appears but the log file is still spammed ;) and after that, error:
http://files.myopera.com/chuuey/albums/830695/mem.jpg
is this a known issue? Been happening to me for a long time now, using windows xp sp3, doesn't occur on windows 7 but the SSSPSX pad plugin config window on 7 causes the emu to crash ;)
Jake.Stine
Seeing the size of the logfile is fascinating, however seeing a snippet of the actual content within the log file will probably be much more enlightening. Chances are it's just repeating the 1-3 lines over and over, so just copy out a couple repetitions and paste it here.
I'm guessing it's a thread-related issue since few people seem to be able to replicate the problem.
azte...
i know that's not related, you can erase my comment if there is a problem but when memory card manager will be ready? It's a long time since the last stable release of pcsx2, it's about time to see a new one. ;)
btw Jake, frameskip options are a nice addition. :)
ramapcsx2
Wow, text messages in the GS window :>
ramapcsx2
Ah one thing I feared might happen:
With no GS output, there'll be no vsyncs, and thus no FPS to measure :/
max...
Brocken compilation under linux any problems
-------------- Build: Release in Utilities ---------------
Compiling: ../../src/Utilities/CheckedStaticBox.cpp
In file included from ../../include/Utilities/CheckedStaticBox.h:18,
from /home/maximu/pcsx2/common/src/Utilities/CheckedStaticBox.cpp:17:
../../include/Utilities/wxGuiTools.h:503: error: variable or field ‘pxFitToDigits’ declared void
../../include/Utilities/wxGuiTools.h:503: error: ‘wxSpinCtrl’ was not declared in this scope
../../include/Utilities/wxGuiTools.h:503: error: ‘win’ was not declared in this scope
../../include/Utilities/wxGuiTools.h:503: error: expected primary-expression before ‘int’
Process terminated with status 1 (0 minutes, 1 seconds)
4 errors, 0 warnings
Reported updated issue 524 https://code.google.com/p/pcsx2/issues/detail?id=524
Thanks jake :)
Jake.Stine
>> Ah one thing I feared might happen:
>> With no GS output, there'll be no vsyncs, and thus no FPS to measure :/
Yeah, known. That's why I'm doing an internal FPS counter and profiler. Wanted to get the GS output text working properly first tho, so that I had a place to print various profiling metrics. ;)
shadowladyngemu
"Implemented GS window hiding on suspend" <-- only feature I missed from the legacy gui, great work.
That separation of settings looks good too.
nefer...
Got this small glitch on suspend from full screen DX10 a couple times but couldn't reproduce it exactly later, it took a part of the left side of the windowed output and left it in the window's scaling grey bars part (I changed it to black on mine).
http://img109.imageshack.us/img109/1630/46291942.jpg
jerrymel...
Hey jake, I have the same problen than chuuey, emu freezes after tryin to config the plugins, tryed to copy an older pcsx2 ini but it goes to a write memory error and then close.
Also tryed to run on a new and fres Win XP but y says thas is no well installer and then it close itself.
Do I, need other software to run the emu, already have DX9 las update nov 2009 y C++ runtime libraries.
chuuey
well i have tried to access the logs... but even notepad++ hangs when loading them since they are so huge, i only manage to saw a few first lines, and basically they refer to binding the plugins.. So I have no clue what is wrong with it, and on the same machine using windows 7, this hang does not occur and the huge log + hang appears on windows xp sp3 ;)
Jake.Stine
Use Editpad Lite. It's the only editor I know of that can load and view huge text files (works flawlessly even on files that are gigabytes big).
Or use 7zip and post it ton megaupload. It might compress to like 50k :p
chuuey
i actually compiled my own version of pcsx2 now, and i don't get this error anymore.. ;) but still the SSPSX plugin crashes the emu on config, so i just use the old version :)
Jake.Stine
>> Got this small glitch on suspend from full screen DX10 a couple times but couldn't reproduce it exactly later, it took a part of the left side of the windowed output and left it in the window's scaling grey bars part (I changed it to black on mine).
Known bug, I think. DX10 currently leaks 'surfaces' when suspending/resuming. That is, the DX10 surface never gets free'd properly, and when you resume PCSX2 literally creates a new surface over top the old one (which is still there). With Aero enabled suspend/resume in DX10 results in a black screen because the new surface gets displayed under the old one.
I'm working on a hopeful fix now, tho as usual I'm without DX10 so I have to work blindly in trying to fix it.
(this is the same bug that causes ~6mb of memory to be leaked every suspend/resume, btw).
Jake.Stine
>> i actually compiled my own version of pcsx2 now, and i don't get this error anymore.. ;) but still the SSPSX plugin crashes the emu on config, so i just use the old version :)
Eh, yeah, that doesn't sound like a fix. Your build just (for some reason) uses a slightly different codegen path that avoids the nastiest part of the threading bug, but apparently still has issues enough to crash. I'd *really* like to see a snippet of the content of the 600meg log file. :(
chuuey
kk i'll try to repeat that bug ;)
chuuey
lol check this out:
Loading plugins...
Binding GS : C:\Documents and Settings\alexander\Desktop\Pcsx2-r2410\plugins\GSdx-SSE2.dll
Windows 5.1.2600 (Service Pack 3 3.0)
ATI Radeon HD 4800 Series (6.14.10.7028)
Binding PAD : C:\Documents and Settings\alexander\Desktop\Pcsx2-r2410\plugins\LilyPad.dll
Binding SPU2 : C:\Documents and Settings\alexander\Desktop\Pcsx2-r2410\plugins\SPU2-X.dll
and the rest are just empty lines, opened in editpadlite ;)
and after i cancel the wizard after a minute of log writing at the end of it i can see
Startup aborted: User canceled FirstTime Wizard.
and rest are empty lines again ;)
Jake.Stine
Ok, pretty sure my next commit will have the plugin config threading problems corrected. Just a heads up to check for it when it's up, in case I don't explicitly remember to mention it in the commit log.
chuuey
ok good to hear, it's weird that sspsx pad crashes (in config when i click on a button to assign) though since the old one i have (1.7.0) works perfect ;)

Revision 2410

Should fix linux...
max...
well: D, now it has already cost one less problem:) now back compilable linux version again.
NEOAethyr
Hey I hate to ask for help in here again but...
Can you guys re-open the forum registration?
I can't register.
I need a GCC setup for this in "Windows".
I really need it...
Without adding somoene else's shell...
It won't be easy to port for me without that.
Nor can do anything without it :(.
I can't use vc.
And codeblocks can only compile a very small chunk of it.
I want to at least fix some stuff and add some options.
ramapcsx2
Forum registration works, but the forum emailer is broken.
We're working on a fix, but it might take a while longer. Sorry for that ><

Revision 2411

* Hopeful fix for DX10 memory leaks.
* Likely fix for various plugin configuration button hangs/crashes.
* Worked on the new GS window text label stuff a bit more (still needs more
tho)
Devel Note:
* Lots of code cleanups regarding app message handling
* Added wxAppWithHelpers.cpp/h files (linux projects need updated but too
tired.. >_<)
arcum42
That's all right, I'll add them in when I fix compilation.
idas_zi...
Guau your york its amazing thanks and happy new year
shadowladyngemu
For some reason hotkeys don't seem to respond here with this revision.
pcsx2gu...
Seconded about hotkeys.
Seems GSdx memleaks are gone though :)
shadowladyngemu
There's still the small memleak here :/
DanrleiS...
Muitos problemas com graficos e pulos de frames incômodos para os jogos.
pcsx2gu...
shadowlady: When Jake says the DX10 memleak he means the window not closing/updating when changing settings on the fly, which is fixed.
DanrleiShippuden: English ONLY here. And what you say doesn't make sense, this had no effect on GS emulation.
actact9...
you should learn english before posting a negative so that everyone knows the kind of problem your having and Im for one does not understand a single word in spanish
arcum42
Appears to be Portuguese, actually. Not that I speak either, but google translate gives us:
"Many problems with graphics and jumping frames uncomfortable for the games."
serban.a...
what about the hotkeys that dont work anymore?
azte...
"Comment by arcum42, Today (71 minutes ago)
Appears to be Portuguese, actually."
it is portuguese indeed. ;) congrats for the changes Jake, one advice guys: just delete the posts of this guy. ;)
chuuey
thanks for the update, by the way, is this normal that gsdx doesn't compile with glew 1.5.2? Works fine with 1.5.1 tosses out errors on the newer version about some variable stuff ;)
chuuey
hmm, keyboard input doesn't work anymore? Can't stop with ESC or change interlace modes with F5 or ratio F6 ;)

Revision 2412

Fix Linux compiling, and remove vestigal x64 code in ZeroGS.
pcsx2gu...
Didn't compile here:
12>..\..\gui\wxAppWithHelpers.cpp(124) : error C2065: 'wxEVT_IDLE' : undeclared identifier
shadowladyngemu
Same.
Beat me for a min to say it :/
arcum42
Ah, good. And wxEvt_Idle doesn't compile in Linux, also showing as undeclared.

Revision 2413

...
pcsx2gu...
That did the trick ;)
arcum42
It would. Looking closer at the last revision, Jake changed the name of the constant in the version of wxWidgets bundled with pcsx2. What I changed it to was the normal name of the constant in wxWidgets.
So it wouldn't have compiled with the normal version of wxWidgets in Windows either...
DanrleiS...
Ok. Wxwidgets foi mudado a favor para a revisão. E finalmente para windows
Jake.Stine
ah, crap, my refactoring spillth over my bounds checking. :/

Revision 2414

Fix errant code refactoring mistake regarding wxEVT_IDLE
ptibo...
Im just posting a comment to say .... AWESOME JOB ! You all done on this emulator ! ITS UN-BE-LIE-VA-BLE ! You are for sure real genius even if there is many many bugs of course which btw is totally normal !
Thank you very much and happy new year to all who contribute to this WONDERFULL arcane code art piece ! ;)
Btw : in the last few r2410 and up, the F1-F3 and ESC keys dont work anymore is this normal ? Thx again you Code GODS ! ;)

Revision 2415

Fix hotkeys.
ptibo...
OMG ! 5 minutes ago i talked about hotkeys problem and then God Jake released R2415 ... I cant believe it, wonderfull job ! Thx a thousand times ! omg ... Ok, ill try to stay quite and calm ... YOU TOTALLY ROCK GUYS ! huh sorry my lord ..
Btw : in newvif, textures are all messed up on floor and objects in Hack GU Vol 1 US, this problem doesnt appear in non-newvif version. Thx again :)
azte...
good to see often updates again, updates once in a few days make me fear a bit for the future of pcsx2. :|
kaboo...
yay fixing^^ now testing !!!
@atze that makes you fear ? makes me just more bored somehow XD
programmer are people too so they have a right to be lazy^^
ptibo...
All my humble respects to all programmers !
Especially thos who work on this Genius project !
Btw : Im a C++ and Csharp .net developper ... But my skills are far far away from these code gods ...
And Gods are not lazy they created time, space, speedhacks, pizzas and nerds like me !
YIIIHHHHH HAAAAA !!
"It's me Mario" - Mario
nefer...
Uhm, hotkeys seem to be working (GSdx ones did) but Tab/F4 did nothing for frame limit even when they were noted as toggled in the log, also tried to load a savestate and it freezed the emu after the "loading" message but it works if loading from the GUI... saving a state worked normally but same problem loading that state.
shadowladyngemu
Confirmed, additionally F9 caused this when trying to switch to software:
Suspending single plugin: GS
Saving GS
Closing GS
Closing PAD
Recovering single plugin: GS
Loading GS
Opening GS
Forced software switch enabled.
Closing DEV9
Closing FW
Closing USB
Closing CDVD
Closing SPU2
Closing GS
serban.a...
loading or saving a state does not work f1 and f3...others have problem too...but those areimportant for me:)
azte...
"@atze that makes you fear ? makes me just more bored somehow XD
programmer are people too so they have a right to be lazy^^"
i know, but the problems is: there were more devs active in the past months and they are disappearing, that happened way before christmas. ;)

Revision 2416

More hotkey fixes
ptibo...
Thank you ! Keep on the good work !
chuuey
hey jake, i don't know if you did try to fix those threading issues, but ssspsx plugin still crashes for me as soon as i click a button to assign it to, i have a ps3 controller hooked up with a xinput driver, but strangely it works just fine on 1.7.0 version, with rumble and everything, other then that that's it for now ;)
chuuey
by the way here's the shots of crashes so you maybe can figure out what is wrong, this happens as soon as i press a button i ssspsx to configure
http://files.myopera.com/chuuey/albums/830695/Clipboard011.jpg
http://files.myopera.com/chuuey/albums/830695/1Clipboard01.jpg
http://files.myopera.com/chuuey/albums/830695/1Clipboard02.jpg
look at the values, that weird isn't it?

Revision 2417

Add a header with some plugin helper functions. Mess with the comments in
PluginCallbacks.h a bit.
arcum42
I'm sure it'll be obsolete when we change plugin apis, but the header I added takes care of a bunch of things that get implemented exactly the same way in all the null plugins.
It should allow me to get rid of a bunch of duplicated code. Right now I haven't got anything hooked up in trunk for it because I haven't tested the Windows side at all yet.
That and a Windows basic configuration dialog needs writing. I already took care of the Gtk+ one...
arcum42
Nice thing is that with the code in PS2Eext.h, for plugins that don't need more configuration then a log checkbox, I can eliminate the Linux folder entirely, and all those cruddy autogenerated source files. ^_^

Revision 2418

Convert DEV9null over to use the new header, as a test case.
arcum42
I'll have to check and see if the project file changes for Windows were correct, but if not, it's a quick fix.
arcum42
I see one or two minor mistakes. Nothing major, though. I'll fix them when I get a chance.

Revision 2419

DEV9null: A few minor changes.
azte...
nice, it's good to see updates in things that arent updated often, thanks. :)
arcum42
No problem, I like poking around in places that otherwise don't get much attention. Seemed like a bit of an extension to being the Linux port maintainer.
I'm planning to do the same thing to the rest of the null plugins, incidentally, I just haven't gotten around to it yet. Dev9null was what I was using to test all of the changes, so I already had it done.
I might extend it a bit to take over the interface of some of the simpler plugins, like ZeroSPU2, too, at some point.
And the nice thing is that if I ever rewrite that header to use wxWidgets, half the plugins will already be converted to it. ^_^
Main issue with this is that the Windows configuration dialog is a placeholder and needs a checkmark added. The old one was, too, though, so it shouldn't be a big issue.
arcum42
Actually, the thing I'm happiest about is that the only platform-specific code in dev9null now is that one shared header. I think that's pretty nice...
azte...
nice, when the wxwidgets build will come? i ask because i didnt see anything anywhere.
arcum42
As far as converting the plugins to wxwidgets, they'll probably rely on having the wxwidgets version of pcsx2 (or the dll, possibly; I'm still working out how it'd be implemented), so probably not till most people aren't using the legacy version.
I don't think we're that far from a beta wxwidgets build being released, though, but we aren't so much going on a timeline right now as releasing it when certain bugs are taken care of, and certain functionality implemented, and the trunk seems stable.
We don't have anything public that I can think of, but the list is definitely shrinking...
azte...
nice thing to know. :) awaiting to see how will be.

Revision 2420

FWnull & USBnull have been converted to use PS2Enull.h as well.
arcum42
I haven't tested compilation on these two in Windows yet. They'll probably work, but I'll make sure in a bit.
tom.mat...
Need for FWNull "unistd.h"
Can you add this?
arcum42
Sure. I'll be rebooting shortly to look at these in Windows anyways. I've just been waiting for something to finish on my computer before I reboot...

Revision 2421

Quick fix to FWnull.
NEOAethyr
Comparing this build with that of r2402.
Good stuff:
I no longer have crashes on the lugin config with certain setups.
I can now use the SPU2-X plugin (I like...).
Also, none of the null plugins crash the plugin config dialog anymore.
Bugs noticed:
Browsing for an iso, after you select one it won't show in the list until you've closed and re-opend pcsx2.
In the SPU2-X plugin, the Configuer button does nothing.
Chit chat stuff:
I don't think the aspect ratio option in the gsdx plugin it's self does anything, what seems to matter is the gs window version of that setting.
Perhaps the gsdx ver of aspect ratio should be removed or vise versa...
I like the new? hide windows on suspend option(on esc).
And the more folder options that are present in the build (didn't notice them before...).
I would like to see a finished upscale fix for dx9 eventually.
Doesn't have to be right now or anything.
One more thing I was thinking about is a possible hybrid soft/hardware renderer.
Check boxes or something, so the user can select portions of the code to be processed in diffrent ways (fixing games that don't work 100% on the hardware ver).
Noticed one odd prob a while back, I dn why, but sometimes when I'm slowing down, only 40% of my dual core is being used.
I'm curious to know if a higher clocked cpu or quad would perform better even though this dual has some room left in those cases.
I'll find out in a month maybe when I get another quad or six core(waiting for the six core cpu's).
Thanks again for the builds guys, even better then before :).
KrossX3
Nice tidying of the Null plugins.

Revision 2422

GSdx:
- Converted an upscale hack to the format I plan to use from now on. (Also makes
this hack work better :p)
xat...
Nice, looks like you really cleaned it up.
kage.urufu
looks like a much better method of doing this, thanks
NEOAethyr
http://rapidshare.com/files/333054276/untitled.PNG.html
Diff, but not fixed :\.
Still, I'll give you +1 for trying :).
I just checked the giu baised save state loading and that is working well now.
It's something I forgot about on the last rev.
ramapcsx2
That's the hardest kind of text glitches. I doubt I'll ever get this stuff working right :p
Autor...
rama, +1 for continue working on upscaling
NEOAethyr
Do you have a copy of xenosaga 2?
I would think if you had it, you could check the changes it directly from it's menu text and stuffs.
One other game I would like you to check out, native texture res, is sfex3.
It doesn't seem right at 1x.
You might have to add some sort of bounds checking, then again it might not be worth the speed decrease.
Maybe the best way of going about it would be to doit on a per texture baises.
Scaling it statically, 1x/2x and 4x.
Removing the user defined setting for the texture res, and just keeping the 1x/2x and 4x settings for the user to play with.
I'm not sure if you guys do that allready or not, per texture in those modes.
It looks like some games have multible res'es for textures.
That's why I think it should be per texture.
Perhaps some textures res'es are determained to be 512x448 when they were 640x448.
When you mix the 2 together you would end up with a mess.
When all of them were meant to be the same, example wise.
Those res'es as an example, I don't think they're quite right (even though they don't have the scaling issues with textures at 1x mode).
I dn, but I think the texture res lookup is bugged in some way.
Which would be half the prob.
SFEX3 makes me think that it is.
In the end, if it can't be fixed right now, ohwell.
If it works in dx10, then so beit :).
Autor...
BTW, tested your hack for vertical lines, works great for X2,
X3 and X4 are still buggy but different from normal scaling
NEOAethyr
CAPCOM vs SNK 2 is another good one.
That's the one I thaught might have a native screen res of 640x448.
Bleh, maybe I'm all wrong though.
I think this odd flickering should be checked out someday though.
I've seen maybe 3 types of it.
CVS2 is a good one because it looks like it's drawn from the wrong line off and on.
Whatever though.
Laters, peace outs.
serban.a...
good job this fixes jak , jak & daxter lines problem....but ony if i disable antialiasing...the bad part is that it brings back ghost problem when upscaling in the other games that worked with previous gsdx versions like monster house,kuon
ramapcsx2
Whops, it would help if you add "UserHacks_HalfPixelOffset = 1" to your GSdx.ini. Forgot to mention that detail :p
NEOAethyr:
GSdx gets the texture sizes right, the problems all stem from the conversion of the GS coordinate system (there's 2 of them even) to the DX one, especially when upscaling.
These are slight differences that sometimes become visible.
1zz11111196
CAPCOM vs SNK 2--play this game alot...forget street fighter 4...also love KOF...anyway CAPCOM vs SNK 2 does have lines but its nothing big of a problem but if it is noted and can be fixed--well u know i have 2 kiss ya...

Revision 2423

GSdx:
- Depth texture removal hack can now be configured via gamefix_skipdraw = x.
(Front Mission 5)
serban.a...
gamefix_skipdraw = x was added by you previously in older versions (via gsdx.ini)....does this mean that it can do only Depth texture removal hack or it con do what it did before too?
docutu...
it corrupt part of the hud on the front mission 5 , before it was ok using fixed scaling (example d3d x2 x3 and so on) , i will make a screenshot
Autor...
Btw, pixoff_x and y were removed, i added UserHacks_HalfPixelOffset = 1, and nothing happens, GoW2 has double Kratos or ghost Kratos problem again
ramapcsx2
Autoran1:
I'm still thinking about what to do with the broken games (like gow).
The real problem behind the ghosting is a half pixel offset, so setting the
new hack to 1 will fix that.
Anything still not fixed by that means it's doing something even worse.
docuturno:
Did you compile this revision yourself? Did you enable the new Offset hack?
bloodindark:
For now it controls both removals, since they're related anyway.
serban.a...
ok i thought so:)
adriant...
I was going to ask previously whether it would be possible to add a parse through skipdraw settings hotkey or option in GSDX outside of the .ini
Haven't checked the latest two builds, will do so shortly. Nice to see gsdx being worked on again :)
docutu...
i forgot to do it , i will do right now
docutu...
ok good news :-) the mud transparent layer is completly gone !
the bad news the scaler partially corrupt the hud , but is not bad as having trasparent mud on screen
nativeHW
http://i46.tinypic.com/2jdjpg9.jpg
nativeSW
http://i48.tinypic.com/2wnx0tc.jpg
scaled2xSW
http://i46.tinypic.com/33tq8sl.jpg
ramapcsx2
Ok, that HUD thing is just silly. Spot the small lines which are shining a bit.
In native res they blend over each other, creating a solid surface.
When upscaled however, the blending isn't reaching "far" enough, so this is the result.
Line...
Excuse me, but what number should I write in gamefix_skipdraw line to remove those garbage from screen in Front mission 5 ??
Line...
Oh, sorry.... I guess its "2" :)
gemin...
works great! the ONLY problem now is the shadow glitch!

Revision 2424

Fix to disc type detection. Starting elfs with non-ps2 disk mounted works again.
ptibo...
!! Awesome job guys !!
I see you ... from Pandora ... The people thank you ...
No'ma ka tai ! Sen ka he toh !
JC. ;)
NEOAethyr
I just did this in r2425:
Opened the emu, set to no disk, ran ulaunch elf, black screen...
Pressed esc, clicked on open elf or whatever it's called it the menu to try to load a diff one in the same instance.
Emu crashed.
HDLoader worked though.
I'm not sure what the ver's are, whatever you know.
The elf loading is working good :).
ramapcsx2
I tried exactly the same, and it worked as expected ><
NEOAethyr
I will try more elf loading stuff later on, with iso's loaded and such at the same time instead of disabling the drive.
You're gonna hate me for this, I found a prob with the gsdx's native mode.
http://rapidshare.com/files/334243330/Desktop.rar.html
Shows the diff between software, hardware native and hardware stretching.
In this case, the hardware stretching ends up with a better result then native mode.
Both are messed up.
Software is displaying everything without probs of course.
ramapcsx2
Again, RS is overloaded, and I'm not gonna hit refresh for the next 2 hours.

Revision 2425

Added some info to the GS window title (finally!). Includes an fps readout!
coolraju...
I get the feeling we are nearing a public beta.
Great job guys
jfre1...
Yay. Finally :).
NEOAethyr
Awesome dude, thanks you very much for this :).
On the build I downloaded, the force frame skipping doesn't seem to be working.
It probably is good for a beta release.
I think it's better then it's ever been, except for the speed of sfex3 (used to be way faster on an old ogl plugin on an old ver of the emu).
(can't use that ogl plugin anymore with the newer emu's, or even most older ones...)
The gui is working great, and the compatibility in dx9 is decent as well.
The speed is ok'ish on a 2.5 dual core amd x2.
Dips max so far at a 2x res, 20 fps to 30 fps (1/3 to 1/2 the speed needed during heavy speed dips).
I'm sure that could be inproved on with hacks, better vga, whatever.
1 more ghz on the cpu, more cpu's.
Then the speed would probably allways be 60 fps or higher in dx9.
That's doable.
In dx10 I'm hoping to see a nice boost in speed, not sure :).
I haven't tried it yet, I'm hopeful though.
And I'm, hoping this darn six core cpu's come out soon.
Jake.Stine
This commit also undid an earlier commit that attempted to fix the DX10 memory leak (it failed). Turns out the memory leak is apparently fixed by the thread design of the old 0.9.6 and propr PCSX2's .. they close the entire GS thread, and the GS window is owned by that thread (this is important to how windows manages things internally). So Windows would post a thread-level destruction to the window when the thread was closed, and it automatically cleaned out leaky DX10 stuff.
That's my current (and likely last) theory. Unfortunately there's just no way to simulate that here in 0.9.7. So either DX10 memleak gets fixed at the source (someone with DX10 and PIX finds the leaky object and fixes it), or it doesn't get fixed. ;_;
qqqq.2...
FINALLY!!!
thanks~~~
Wagnar...
:( the FIX for dx10 was working for me for the stop / resume window. But if you say its better to remove I guess it is...
Autor...
indeed, Finally
sitonita...
Hooray! I've been missing this for months!
chuuey
thanks a lot jake, works nice :) on another note i have a bug which i want to report with digital devil saga, should i do it on the forums? Or start an issue here?
ramapcsx2
Please open an issue for it here. But I don't know when someone has time for it, so you'll need to be patient.
kage.urufu
Works great, thanks so much. I've been waiting for this for a while now. Other than that, I get pretty good compatibility, and think we are about ready for a public beta.
Jake.Stine
@wagnard:
>> :( the FIX for dx10 was working for me for the stop / resume window. But if you say its better to remove I guess it is...
That's actually an nvidia driver bug in the 195.xx drivers. 192.xx and 191.xx are confirmed to work fine. I have a workaround planned though, because as it turns out any resize or hide/show of the window fixes it. So (hopefully) all I need to do is force hide/show the GS window on resume and fix it. (yea, silly stuff when dealing with driver bugs).
Jake.Stine
@wagnard: That is to say, the suspend/resume was fixed but memory was still leaking -- and the "fix" was ugly and hackish. I was only willing to put up with it if it actually killed the memleak (which appears to be nearly unfixable right now >_<).
The no-draw after resume is a driver bug, specific to latest nvidia 195.xx drivers when combined with and aero only. It's just to obscure for me to justify hack-killing the GSpanel/viewport and restarting all plugins just for it. ;)
NEOAethyr
It's no wonder then why the quadro drivers are stuck on v191.78.
I've been waiting for along time waiting for the quadro's to step up to 195 or something so I could get flash hardware accellaration going.
Now I know why it's been taking so long, there won't be one until something is fixed that nvidia knows about.
Ohwell, I've been using 178.26 for 2k3(xp).
And the stock driver in win7, when I had that going a month ago.
The stock driver was suprising ok though in win7.
DanrleiS...
O Ploblema continua. Por que sem o fullscreen mode os skip frames são mais visivéis, aí então maximizando é a mesma coisa. Então eu teclava Alt + Enter a velocidade tinha melhorado bastante. A partir de algumas correções anteriores o fullscreenmode foi alterado para a maximização sem a barra. Os jogos ficarão muito lentos. mMe envia o E-mail como posso resolver isto. [email protected]. Obrigado pela colaboração.
NEOAethyr
I are you guys able to use the gui for the game patches?
And are you guys getting these errors in the emu log? :
Loading plugins...
Binding GS : H:\Emulation\Console\PlayStation2\PCSX2\plugins\GSdx-SSE2.dll
Windows 5.2.3790 (Service Pack 2 2.0)
nVidia Universal Display Driver (Widescreen) (PhsyX) (6.14.11.7826)
Binding PAD : H:\Emulation\Console\PlayStation2\PCSX2\plugins\LilyPad.dll
The rest of that section prints out correctly.
I dn how this will look after I post it but there are several CR, LF errors (dw 0x0A0D).
And then there's this, but it's because of my system, not sure if you can even stop that unless you choose not to log that error or use a diff api (I dn anything about it except that I removed ntfs compression):
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 1]
File/Object: H:\Emulation\Console\PlayStation2\PCSX2\memcards\Mcd001.ps2
NTFS Compress Notice: Stream exception: General Win32 File/stream error [GetLastError: 1]
File/Object: H:\Emulation\Console\PlayStation2\PCSX2\memcards\Mcd002.ps2
Plugins initialized successfully.
Otherwise that's all the probs I have left I think.
pcsx2gu...
Loading plugins...
Binding GS : H:\Emulation\Console\PlayStation2\PCSX2\plugins\GSdx-SSE2.dll
Windows 5.2.3790 (Service Pack 2 2.0)
nVidia Universal Display Driver (Widescreen) (PhsyX) (6.14.11.7826)
Binding PAD : H:\Emulation\Console\PlayStation2\PCSX2\plugins\LilyPad.dll
Does that look like an error to you? It's just GSdx getting your driver info from your graphics card.
And then there's this, but it's because of my system, not sure if you can even stop that unless you choose not to log that error or use a diff api (I dn anything about it except that I removed ntfs compression)
That's exactly what caused it (obviously). I can't see why you would want to remove the NTFS compression though.
NEOAethyr
DanrleiS... (Sorry I can't even read my nick right)
Is he talking about full screen fps measuring?
If so, my opinion is that at least we have one on a maximized window.
It's not a big deal to me right now.
Maybe unless you wanted your full screen res at a specific ratio.
Mine is stuck at 1920x1080(native), so maximizing the window doesn't bother me.
I'm not going to be using a 720x480 full screen res or the like, trying to use a 1:1 ratio.
The video's look nice allready so its all good... :)
Sorry for all the posts btw.
NEOAethyr
@pcsx2guide
I removed comrpession because it could improve the speed of ntfs in winnt.
And I can't tell if you're getting the error or not.
I notcied them in notepad.
I guess I'de have to check with a hex editor.
I have a suspicion that it's missing one of the 2 char's needed for a full return.
For 2 of it's plugins or perhaps after/before the vga and os.
NEOAethyr
Besides, I just noticed you just repeated part of my post.
Del your log, and re-check it after you run a game once.
See if you have return errors in your log too.
They look like squares.
NEOAethyr
Err nm, d@mn sorry...
They are tab errors.
They were woupposed to be a mix of tabs and cr/lf's.
1 tab error.
Then a ret+tab error.
Then a ret error.
Exactly like that.
I haven't looked at with a hex editor yet.
Jake.Stine
Use a text editor like TextPad or EditPad. Whatever you're using sucks.
kaboo...
use notepad++ *-*
come on use it.
you know you want it!
USE IT!!!!
Wagnar...
@Jake Thanks for the info.I'll just disable desktop recomposition when using pcsx2 then. Its no big deal :)
NEOAethyr
http://rapidshare.com/files/334215533/untitled.JPG.html
That's what I was talking about so I defently know it's not old notepad's fault. :)
One more thingy about the log, mine hit 11megs from less then a handful of games ran.
gifMFIFOInterrupt was responcible for huge size increase.
:)
nexxus86
now only the GS usage percentage is missing...
but then it's perfect.
ramapcsx2
NEOAethyr:
1. Please use an imagehost for images. Rapidshare is often overloaded and makes you wait.
2. The gifMFIFOInterrupt message means you've hit an emulation bug. What game did you play?
diego...
Absoulute positive,mmm i smell a release soon..
Jake.Stine
sigh. I know about the mismatched LF / CRLF stuff. It's very hard to fix properly in a cross-platform way because of the various sources of log data and the different ways each source handles newlines (pcsx2 logs, real EE/IOP logs, plugin logs, win32 stdout pipes, etc). This is a problem common to many programs, and thats why I use EditPad because too often the output of programs isn't properly readable in notepad.
I may fix it when I'm really effing bored.
Supe...
Could you add the percentage of CPU(GPU) usage to window title like 0.9.6? It's a piece of useful information too.

Revision 2426

Likely fix for Issue 533 (fmv hangs in Final Fantasy VII: Dirge Of Cerberus)
shadowladyngemu
If it's the same thing for the PAL one without patches then doesn't seem fixed, I also get the same thing even when the game works with patches enabled.
*Unknown 32 bit write at address 1f801614 value ffffffff
*Unknown 32 bit write at address 1f801608 value 1
*Unknown 32 bit write at address 1f801604 value 0
*Unknown 32 bit read at address 1f801608
*Unknown 32 bit write at address 1f801680 value 1
*Unknown 32 bit write at address 1f801620 value 1131f0
*Unknown 32 bit write at address 1f801628 value 113200
*Unknown 32 bit write at address 1f801618 value 111100
*Unknown 32 bit write at address 1f801634 value 27782edf
*Unknown 32 bit write at address 1f801640 value 2a2f
*Unknown 32 bit write at address 1f801610 value 80000073
*Unknown 32 bit read at address 1f801604
*Unknown 32 bit write at address 1f801604 value bf
It's this part of the patch that lets it go on if it helps:
comment=patches by nachbrenner
//Fix "**** SQTHREAD ERROR : BAD LOCK STATE"
patch=0,EE,0042d768,word,00000000
fullwal...
Good to see more fixes for games :P. If I could suggest a change, maybe you could put newVifunpack as a GUI option?
wjat....
@Danrlei ... Stop writing in Portuguese ... The official language here is english.
@Danrlei... Pare de escrever em português (e "vocês" não se escreve com cedilha)... A lingua oficial aqui é Ingles.
Good job guys! Sorry for the comments that brazilian guy!
Wagnar...
I don't know if the google rules state is the Official language is English on the comments here or if it is strictly on the devs decision.
But +1 for the commit thoses fix are always welcome :)
diego...
i think its like in the forums, english only,but anyway nice commit.
Jake.Stine
Well it's pretty simple, if you want me, rama, or cottonvibes to have any clue what you're saying, you need to use english. Official or not, that's how you get heard around here ;)
ramapcsx2
I say we all switch to German now. English is overrated.
kage.urufu
forget german, lets all speak latin
Jake.Stine
Please write all requests using COBOL. Thank you.
azte...
damn guys, you could talk about the fix only (i'm not talking about the devs, just being clear) ;)
about that darnlei guy, just erase all of his posts, this will do the trick.
ntcong.it
#include <iostream>
using std::cout;
int main() {
cout << "Nice Commit\n";
return 1;
}
Jake.Stine
This isn't some college intro to comp sci course! iostream is strictly forbidden here! >_<
RebelliousX
True programmers speaks in binary. 10010112l10 101
cottonvibes
IDENTIFICATION DIVISION.
PROGRAM-ID. COBOL-SUCKS.
PROCEDURE DIVISION.
DISPLAY 'Cobol Sucks! :('.
STOP RUN.
#include <stdio.h>
void main() { printf(":p"); }
kage.urufu
def main():
print "Nice commit"
if __name__ == "__main__":
main()

Revision 2427

Null plugins should probably disable HW/addr logging by default...
Jake.Stine
This'll fil the unknown address sspam in some games that poll the USB, but *only* if you clear out your usbnull.in file.

Revision 2428

Should fix Issue 538 : Linuz plugin compression broken.
Jake.Stine
Curious. Was it the fflush specifically that caused the problem, or general log spamming making the system run uber slow?
ramapcsx2
I just did a quick test, disabled the printf and it was still slow.
Figured it had to be the putchar then, which I think goes with the fflush.
Disabled them both, and since that fixed it, commited :p
wespipe...
Does not fix decompression.

Revision 2429

newVif: fixed tekken 5 while keeping games like gradius 5 working.
hopefully this fixes the rest of the problems newVif was having with games..
ramapcsx2
GT4 and Tekken 5 are working now. Harry Potter still looks the same though.
What else was broken?
Good work on this :)
cottonvibes
rama: Breath of Fire 5 was also broken i think?
aside from that not sure..
doodhwal...
hurray !! anything from cotton worth +1
ramapcsx2
Breath of Fire 5: working :)
veaac.fd...
Breath of Fire worked for me for a long time.
jfre1...
GT4 finally working again? Yay
That games not worked in like 6 months
Thraay
newVif still doesn't work with .hack G.U. Vol 1 - Rebirth :(
But Breath of Fire 5 works now.
jfre1...
Hmm GT4 still doesn`t work me with this revision. Black screen soon as I boot the game up. Emulator crashes if skip bios is selected also. Note that this is the PAL version I`m talking about.
jfre1...
If the new vif1 isn`t enabled by default unless enabled in sourcecode then disregard my comments.
pcsx2gu...
It isn't. So before anyone comments again on this, you need to enable the new VIF by changing the source. Else you're using the old VIF and your results have nothing to do with this revision.
Thraay
My comment is based off using a compile with the new VIF on. While .hack G.U. Vol 1 - Rebirth will startup the main menu and all graphics are messed up. Using the same source with the new Vif off the game runs without any problems.

Revision 2430

Minor logging stuff.
ntcong.it
About the message dialog asking for update directX. I think we should have a Info button ( Help ) that link directly to a wiki page that explain why we need to upgrade it. I saw many people complain that their DirectX is already the newest version (9.0c).

Revision 2431

newVif: fixed a bug... fixes Digital Devil Saga crashing.
ramapcsx2
And fixed harry potter :D
azte...
yay for the 2 game fixes of cotton.

Revision 2432

newVif: >= to >
cottonvibes
fixes some console spamming in SO3 in dev builds...

Revision 2433

Enable IOP's detailed bios logs to devel builds (previously debug build only),
and have IOP interpreter always spam bios logs even in release mode builds.

Revision 2434

#endif

Revision 2435

newVif: fixed a problem with the dynarec. fixes .hack gu rebirth.
ramapcsx2
Note to compilers of svn revs:
We found this is prolly not the right fix. Please don't distribute this.
KrossX3
Roger that.
Thraay
This does fix the issues with .hack gu rebirth. No more gobbled interface and you can now play with the newVIF.

Revision 2436

Tweaks to Elfheader & cdvdReadKey. For the moment, lets not read or write Dev9
memory locations in the null plugin...
arcum42
Oh, and there is a checkbox to control ELF_LOG...
ramapcsx2
Got a question:
Have you seen the code that injects the location of an elf file into iop memory by chance?
We need to fix that to get some stuff to reboot properly. Here's a log so you know what I mean :p
http://pastebin.com/m2b7a6d2f
This .elf should reboot into the BIOS (rom0:OSDSYS), not my J:\ drive :p
arcum42
loadElfFile in Elfheader.cpp is a good place to start; filename in it includes the full path, and that is where it goes to load elf files and do bios skip...
ramapcsx2
Yeah, I also started there, but can't find the place it happens.
Ah well, chances were you already worked on that code in the past :p
arcum42
Could also be somewhere in ElfObject. I see the actual file being loaded in memory in loadProgramHeaders, after being read in readFile. Not totally sure. It's something I'd like to see fixed, too, as a bug or two I've noticed are probably related...
Of course, loading elf files that way is kind of a hack anyways. I'd rather have the elf file be in a place the ps2 knows about, like a memory card or a fake usb stick, when its loaded...
arcum42
Ah. In LoadElfFile:
strcpy( (char*)PSM( i ), filename.ToUTF8() );
arcum42
Try something like:
strcpy((char*)PSM(i), wxsFormat(L"rom0:"+Path::GetFilename(filename)).ToUTF8());
Not sure which device it should be; rom0: is a guess.
arcum42
That and there needs to be an if statement, so it only mutilates the file name if it's an elf file.
arcum42
Something like this:
Index: pcsx2/Elfheader.cpp
===================================================================
--- pcsx2/Elfheader.cpp (revision 2436)
+++ pcsx2/Elfheader.cpp (working copy)
@@ -441,6 +441,7 @@
void loadElfFile(const wxString& filename)
{
ElfObject *elfptr;
+ bool iscdvd;
if (filename.IsEmpty()) return;
@@ -449,7 +450,8 @@
if (filename.StartsWith(L"cdrom:") && !ENABLE_LOADING_PS1_GAMES)
throw Exception::RuntimeError( wxLt("This is not a Ps2 disc. (And we don't currently emulate PS1 games)") );
- if (filename.StartsWith(L"cdrom:") || filename.StartsWith(L"cdrom0:") || filename.StartsWith(L"cdrom1:"))
+ iscdvd = (filename.StartsWith(L"cdrom:") || filename.StartsWith(L"cdrom0:") || filename.StartsWith(L"cdrom1:"));
+ if (iscdvd)
{
// It's a game disc.
DevCon.WriteLn(L"Loading from a CD rom or CD image.");
@@ -490,7 +492,11 @@
{
if( memcmp( "rom0:OSDSYS", (char*)PSM( i ), 11 ) == 0 )
{
+ if (iscdvd)
strcpy( (char*)PSM( i ), filename.ToUTF8() );
+ else
+ strcpy((char*)PSM(i), wxsFormat(L"rom0:"+Path::GetFilename(filename)).ToUTF8());
+
DevCon.WriteLn( wxsFormat(L"loadElfFile: addr %x \"rom0:OSDSYS\" -> \"" + filename + L"\"", i));
}
}
ramapcsx2
Awesome, I'll check it out :)
ramapcsx2
Alright, this seems to work as intended.
It now tried to open "rom0:GSM.ELF".
So I renamed my .elf to "OSDSYS", ran that, and it successfully rebooted into the BIOS :p
arcum42
Nice. And it's writing over rom0:OSDSYS anyways, so we could just leave off the else statement, and it will stay as rom0:OSDSYS.
For committing purposes, wonder if I should do that, or stay with the patch I provided?
ramapcsx2
Yeah, we should leave the else statement out.
I don't get the whole picture yet, but the idea is that the homebrew specifies the elf to load.
No idea why we're overwriting it.
Let's wait and see what Jake or Gigaherz think before deciding what to do :p
arcum42
Sounds good to me, since I'm not sure why we overwrite it either.

Revision 2437

ZeroSPU2: Made the way different sound archetectures are done a bit more
flexable so we could conceivably switch them at run time rather then
compilation. And it occurred to me that the dynamic sound buffering Zedr0n is
doing with PulseAudio is probably how it should be done in Alsa as well...
arcum42
Oh, and I switched the dates in the copyright to indicate that it isn't 2007.
And if you can't tell from this commit, I'm getting things ready to potentially add the PulseAudio code in as an option...
arcum42
Sorry, PortAudio, not PulseAudio. :P
azte...
this seems nice stuff but what pulseaudio does exactly? It's a thing some games have or all of them have it?
arcum42
PortAudio is a crossplatform audio api. What I was thinking of doing is rigging it up so that you can switch between different apis in ZeroSPU2 in the configuration dialog, in case one sounds better on your system then another.
SPU2-X already has an option like that. In fact, PortAudio support might be good there, too...
gigaherz
I already wrote portaudio supprot for spu2-x, but no one in the dev chan seemed interested so I didn't commit it.
arcum42
Really? PortAudio support on SPU2-X might make it easier to port to Linux. If you still have the code around, I'd be interested...
gigaherz
okay commited.
arcum42
All right, cool, thanks.
For my uses, the fact that it doesn't have a dialog box is for the best, since any initial Linux port of SPU2-X I do will probably have me pencil in a dialog box later anyways...
azte...
i understad, thanks for the explanation arcum42. +1

Revision 2438

Missed the project file.

Revision 2439

SPU2-X: Experimental PortAudio module. No config dialogs. Will use the system
default output device & whatever the default "api" is in portaudio. Requires
user-compiled portaudio lib, might commit later.
Widnows users probably don't have any interest in this unless you want to play
the audio through portaudio's ASIO driver. Arcum was interested so I commited.
chuuey
hoho, ASIO would be great :D
andutrache
i got Soundblaster X-Fi Titanium Fatal1ty Pro so i think ASIO would be awesome
gigaherz
While true ASIO devices with proper drivers do have a lot less latency, i'm not sure how much latency there is in portaudio itself, which would be added on top of spu2-x's internal buffer. In the end maybe it doesn't really become much better at all.
TheBorde...
I can't seem to compile the SPU2-X source now. Visual Studio 08 spits out several errors when I try to build it. Can anyone confirm this?
gigaherz
it's probably because I hardcoded some paths in the project files and forgot to make them relative before commiting. Lemme see...
gigaherz
Hm no there's no absolute paths in this commit, and it compiles fine for me. Are you trying to compile without the next commit I made? As I said you need portaudio to compile this.
TheBorde...
Thanks gigaherz. I checked and it compiled alright now. I'm not sure what happened.

Revision 2440

Temporarily commit <b>binary build</b> of portaudio for windows users, since I
don't feel like converting the portaudio project files to work the way pcsx2
stuff does, right now.
gigaherz
Pretend the text between <b></b> is actually bold. googlecode failed me.
ntcong.it
Its fine, when you read the code wrapped within <b>, you know that it is bold ;)

Revision 2441

Fetched a snapshot of the source from portaudio site, and embedded it into the
project. I might have missed something, so this will need some more work before
it's fully stable.
gigaherz
A note for anyone wanting to play with ASIO: The ASIO SDK cannot be freely distributed, and so it wouldn't be legal for me to upload it to the svn.
If you want to compile a ASIO-enabled version of portaudio, you will need to get the ASIO SDK directly from steinberg. To allow compiling without ASIO, I created a configuration called "Release (NO ASIO)", which disables the asio host api support, and I set it as default for all DEVEL and RELEASE solution configurations.
max...
SPU2-x and zerospu2 are broken compilation Under VIsual studios 2008?
1 >------ Operation Build started: Project: portaudio, Configuration: Release (NO ASIO) Win32 ------
1> Compiling ...
2 >------ Operation Build started: Project: ZeroSPU2, Configuration: Release Win32 ------
2> Executing pre-build event ...
1> pa_win_wasapi.cpp
2> SubWCRev: 'c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ plugins \ zerospu2'
2> Last committed at revision 2438
2> Updated to revision 2441
2> Compiling ...
2> zerospu2.cpp
2> .. \ zerospu2.cpp (21): error C2146: syntax error: missing ',' before identifier 'MaxBuffer'
2> .. \ zerospu2.cpp (21): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> .. \ zerospu2.cpp (21): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (39): error C2378: 'u32': redefinition; not be overloaded with a typedef symbol
2> .. \ zerospu2.cpp (21): see declaration of 'u32'
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (100): error C2146: syntax error: missing ',' before identifier 'uptr'
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (100): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (100): error C2378: 'u32': redefinition; not be overloaded with a typedef symbol
2> .. \ zerospu2.cpp (21): see declaration of 'u32'
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (100): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (127): error C2061: syntax error: identifier 'u32'
2> c: \ users \ Maximu \ desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ Pcsx2Types.h (129): error C2065: 'src': undeclared identifier
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (68): error C2146: syntax error: missing ',' before identifier 'key'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (68): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (68): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (69): error C2146: syntax error: missing ',' before identifier 'evt'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (69): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (69): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (105): error C2143: syntax error: missing ',' before '__stdcall'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (105): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (105): error C2086: 'int u32': redefinition
2> .. \ zerospu2.cpp (21): see declaration of 'u32'
1> c: \ program files \ Microsoft SDKs \ windows \ v6.0a \ include \ devicetopology.h (2237): error C2061: syntax error: identifier 'KSJACK_DESCRIPTION'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (105): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C2143: syntax error: missing ',' before '__stdcall'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C2086: 'int u32': redefinition
2> .. \ zerospu2.cpp (21): see declaration of 'u32'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C2146: syntax error: missing ')' before identifier 'type'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): warning C4229: anachronism has been used: modifiers are omitted data
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (106): error C2059: syntax error: ')'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (122): error C2118: negative subscript
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (147): error C2146: syntax error: missing ',' before identifier 'lsn'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (147): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (147): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (323): error C2146: syntax error: missing ')' before identifier 'mem'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (323): warning C4229: anachronism has been used: modifiers are omitted data
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (323): error C2182: 'SPU2write': invalid use of type 'void'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (323): error C2059: syntax error: ')'
1> .. \ .. \ src \ hostapi \ wasapi \ pa_win_wasapi.cpp (896): error C2065: 'KSAUDIO_SPEAKER_DIRECTOUT': undeclared identifier
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (324): error C2146: syntax error: missing ')' before identifier 'mem'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (324): warning C4229: anachronism has been used: modifiers are omitted data
1> The build log was saved at "file: / / c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ 3rdparty \ portaudio \ build \ msvc \ Release (NO ASIO) \ BuildLog.htm"
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (324): error C2059: syntax error: ')'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (333): error C2146: syntax error: missing ')' before identifier 'BaseAddr'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (333): warning C4229: anachronism has been used: modifiers are omitted data
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (333): error C2182: 'SPU2setDMABaseAddr': invalid use of type 'void'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (333): error C2059: syntax error: ')'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (336): error C2143: syntax error: missing ',' before '__stdcall'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (336): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (336): error C2086: 'int u32': redefinition
2> .. \ zerospu2.cpp (21): see declaration of 'u32'
1> portaudio - 2 errors, 0 warnings
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (336): error C4430: missing type specifier, int is assumed. Note: C + + does not support default-int
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (337): error C2061: syntax error: identifier 'u32'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (346): error C2065: 'ptr': undeclared identifier
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (346): warning C4229: anachronism has been used: modifiers are omitted data
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (346): error C2182: 'SPU2setClockPtr': invalid use of type 'void'
2> c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ common \ include \ PS2Edefs.h (346): fatal error c1903: can not recover from previous errors, the compilation stops
2> Build log was saved at "file: / / c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ plugins \ zerospu2 \ Windows \ Win32 \ Release \ BuildLog.htm"
2> ZeroSPU2 - 46 errors, 5 warnings
3 >------ Operation Build started: Project: SPU2-X configuration: Release Win32 ------
3> Executing pre-build event ...
3> SubWCRev: 'c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ plugins \ SPU2-x \ src'
3> Last committed at revision 2441
3> Updated to revision 2441
3> Linking ...
3> LINK: fatal error LNK1181: can not open input file '.. \ .. \ .. \ .. \ 3rdparty \ portaudio \ build \ msvc \ win32 \ release (no asio) \ portaudio_x86.lib'
3> The build log was saved at "file: / / c: \ Users \ Maximu \ Desktop \ pcsx2 \ ps2svn0.9.6 \ plugins \ SPU2-x \ src \ Windows \ Win32 \ Release \ BuildLog.htm"
3> SPU2-X - 1 errors, 0 warnings
andutrache
hmm compiling errors can be fixed but NO ASIO...
then ill stick with xaudio
gigaherz
maximu: this commit does NOT change zerospu2. I don't know why isn't compiling for you, but whatever the case, it's not related to my changes.
I don't know why spu2-x failed to link for you, either... I tried it and it compiled in all configurations... :/
arcum42
Regarding ZeroSPU2, see r2442.
max...
already knew that the error in zerospu2, was produced in previous reviews, but did not know where to put it
About the error SPU2-x, my fault sorry: /, seeing pa_wasapi files, I had installed the latest version SDK view, since it seems portaudio requires SDK 6.1 overview
@ note pa_wasapi currently requires VC 2005, and the latest Vista SDK

Revision 2442

Bring Windows in sync with the earlier changes I made to ZeroSPU2.
Thraay
I can't nail it down to what exact change that started this. But as of Revision 2443 (I went from 2435 to 2443). Now there seems to be alot more crash's across the board when using any .hack game. All of the latest sound additions leads to a crash within 5 mins of booting up a rom.
Other then that keep up the great work. Just wanted to put that out there. I use a Windows 7 machine if it makes any difference.

Revision 2443

ZeroSPU2: Add PortAudio, and make it possible for it to be compiled as Alsa,
OSS, or PortAudio on the Linux side.
arcum42
You now can choose any of the three in Codeblocks, in Debug or Release mode.

Revision 2444

ZeroSPU2: Exclude a few files from the project in Visual C++, to avoid potential
issues.

Revision 2445

Started implementing configuration support for PortAudio. Since PortAudio
doesn't have any kind of "Unique ID" for the listed devices, I have to rely on
the "host api" name and the descriptive name of the device, but it doesn't seem
to be 100% reliable. In case the device name can't be found, it will try to use
the default device for the specified API. If no api is specified, then it will
fall back to using whatever default device PortAudio provides.
gigaherz
Note for windows users, the valid HostApi settings are:
DirectSound, MME, ASIO, WDMKS, WASAPI
DirectSound is the most stable option, but since SPU2-X already supports it, there's not much point in using it,
MME=waveOut, same thing,
ASIO requires getting the ASIO SDK, which is not freely distributable,
WDMKS (windows kernel streaming) should have low latency, but it's a complex kernel-mode api so it could have bad results if misused, and comes disabled by default in portaudio,
and last, WASAPI, is a new audio streaming api in Vista and Windows 7, probably a better choice than WDMKS if you have it available, but maybe not as low-latency as ASIO, unless it's used in EXCLUSIVE mode. it also comes disabled by default.
lemuel2010
ok.

Revision 2446

newVif: reverted my last change since it wasn't correct (i wasn't thinking
straight when i coded it)
so .hack gu rebirth will be broken with this revision... i still need to figure
out the real problem.

Revision 2447

newVif: fixed some bugs with mask/mode modes. i had forgotten that
mVUmergeRegs() modifies the source reg's vectors, so data was being corrupted
and breaking some games (sse4.1 users didn't have this problem).
This revision correctly fixes .hack GU Rebirth.
At this point we don't know any games newVif breaks compared to the old vif
code. If you know any please leave a comment.
Autor...
Thanks, btw what about newvif0, will it be implemented?
azte...
yay for cotton on fire and game fix. :)
Thraay
This also fix's some issues with .hack GU Redemption making it playable without any speedhacks on. I believe its mVU Flag Hack that is cashing some random crash's in it. After turning it off the random crash's went away in Redemtion. So its playable now with this build.

Revision 2448

newVif: Cleaned up some code and added some Cleanup code. :D

Revision 2449

newVif: Added support for vif0. Also enabled newVif by default since it seems
compatible enough.
Comment if this revision breaks anything.
Autor...
Now Star Wars 3 completely playable without SPS and other shit, thanks
lemuel2010
Cottonvibes important rev in emulation.

Revision 2450

changed a comment
shadowladyngemu
Does this revision increase speed :D?
kaboo...
ROFLMAO XDDDDDDDD yes I believe it does
I believe so it is!

Revision 2451

newVif: minor changes...

Revision 2452

newVif: fix for rule of rose.

Revision 2453

Cleanup commit:
- Remove code dealing with "EEINST_MMX"
ptibo...
Thanx for all the great work ! This emulator really stand as one of the best.
Btw do you know where i can get the latest compiled revision ?
actact9...
compile it yourself or use google they do not share here the latest SVN revisions
to rama:
any news on the work on FFX-2 fmv's yet or its a really hard bug and its going to a long time before its fixed
ramapcsx2
The flickering? No idea except that GSdx seems to show one black frame, then one good frame again, hence the flicker (or dark tone when using interlace modes).
The lines on it are due to upscaling.
So no, don't expect a fix anytime soon.
danialho...
Several games now freeze,
Canis Canem Edit (Bully) freezes in play.
Topspin freezes on the loading screen.

Revision 2454

Cleanup commit:
- Remove code dealing with "PROCESS_EE_MMX" ( not used without "EEINST_MMX" )

Revision 2455

minor cleanups (no functional changes)

Revision 2456

Disabling the not working backward propagation system in the EErec.

Revision 2457

Document an Elfheader issue, so I don't forget about it.
ramapcsx2
Alright, good solution for now.
[15:06] <JakeStine> the only way to implement it is to have a virtual CDVD driver that creates ISO images from files on your computer.
Jake.Stine
There is no correct device. To the virtual machine PS2, the ELF file doesn't exist. It's as if we "burned" the ELF right into the PS2's main ram, and then turned the PS2 on. The bios has no way to accessing the source.
The solution is to implement an internal "ISO-ifier" that can turn a file (or collection of files) into an ISO image, and then it would mount that in-memory ISO onto cdrom0 internally. Then the PS2 would be able to access it.
It might also be possible to give the virtual PS2 access via DEV9 hard drive or serial connector, but I don't know the details for those (filesystem emulation, etc). So a virtual memory-ISO would be the most obvious route.
Jake.Stine
By the way, Dolphin implemented something similar a while back. They use it to mount and run test apps and junk.
arcum42
Wouldn't be that hard in Linux; Move the elf to a temporary directory, and call
mkisofs -o /tmp/cd.iso /tmp/directory/
from the shell. We'd want crossplatform solutions, though. :)
And yeah, figured I'd document it for now, maybe add if (iscdvd) in later, so it just calls the bios if an elf file was created...
arcum42
Though the source for mkisofs would be a good place to start if we were to do something like that. It's GPLed, after all.
Or Dolphin, if Dolphin's already implemented it.
arcum42
BTW, just remembered. We should actually remove that assert that triggers if there are too many chars in a symbol. I ran across a game with a 511 char symbol recently (not that I recall which one it was)...

Revision 2458

Fix calling of Interpreter routines in iR5900Branch.cpp when EE_CONST_PROP is
off.

Revision 2459

I implemented somethign I called pcsx2hostfs. It's a IOP driver which uses a
virtual device implemented into pcsx2's emulation of the iop memory map, and not
existing in the real ps2, which could be used to allow "host:" access from ps2
applications. THe pcsx2-side implementation currently is only hackedup to allow
reading a hardcoded path, and it would probably not work with normal homebrew
yet.
gigaherz
Its NOT useful for running games. It does not fix anything either. Consider it a toy.
nefer...
Somehow games are just crashing since this revision after a little of boot time and screens, some show screens some don't pass from black screen then crash.
shadowladyngemu
Same, devel/debug builds work tho.
Jake.Stine
Will be fixed in my next commit.
ramapcsx2
+1 for the new stuff. Just hope the IOP memory will indeed never be used :p

Revision 2460

Disable recCACHE, since it calls an empty interpreter function only. Small
speedup in Suikoden 3.
chuuey
no idea what happened, i compiled just now, and all my games crash pcsx2 now, was using rev 2457 before and everything worked fine, i guess the last 3 revisions must've done something ;)
david.jennes
Have you tried a full recompile? 'cause that often solves such things. Otherwise it's this or r2458 (check that one to see if it works or not).
Cya!
Thraay
Somewhere between r2435 and r3459 there has been a large slowdown in the .Hack G.U. Games. I haven't been able to find the exact revision where it happen but its a 10fps + style slowdown on the menu systems and 5fps+ in-game. Fixing to try r2460 to see if it helps any.
kaboo...
@ thraay try 2448 since new vif was activated in 2449
also 2458 works fine here I'll test which revision broke pcsx2
Thraay
I will give it a try and see. I am just double checking and making sure that the settings are all the same between r2435 (the one that works just fine with .hack g.u. (more so testing on vol 2 and vol 3)) I was playing with r2454 last night and noticed that the anytime in the menus and in the virtual computer menus / email that the speed dropped down below the 35fps mark.
So I switched back to r2435 and was checking the same spots and noticed that they are generally 10fps + faster and it seems more smoother overall.
So I will check both 2448 and 2449 and compare them with r2435 speed wise to see what the differences are.
cottonvibes
guys the last revision is the one that breaks pcsx2 in release builds.
the reason is due to some ugly IOP co-routine code we have in pcsx2, we randomly have problems when we change pcsx2's memory structure (whenever we add or remove global variables for instance).

Revision 2461

Removed the old vif unpack code since pcsx2 is now using newVif.
Notes to Devs:
- Linux project files probably need to be updated since I deleted some files.
- In the vif0/vif1 Freeze() functions for saved states, I kept some dummy vars
to keep saved state compatibility. We should remove them next time we decide to
break saved state compatibility.
toammar2...
Yes newVif Now Better...........
But SYPHON FILTER Still Need Fix !!!
http://i260.photobucket.com/albums/ii31/AMMARPB/SYPHONFILTER.jpg
azte...
if compatibility prevents the progress, remove it. ;) Congrats.
cottonvibes
@toammar2006:
Which version of syphon filter is that?
toammar2...
Sorry This problem From R2455…
But The problem has been Fix From R2461 to R 2468....

Revision 2462

Fix glew_static so that it doesn't need glew installed; and add a no_asio debug
build type to portaudio.

Revision 2463

Fix up Linux. Comment out a bit of unused code.

Revision 2464

Commit a modified copy of the CMake files from issue 513 . (Note: work in
progress. Not currently for general use. Builds made using cmake are currently
not supported, and unlikely to work properly.)
arcum42
This is mainly so we don't have such a moving target for getting cmake working. Currently the ZeroGS build definitely has issues, and I haven't had much luck even using copied in graphical plugins with the copy of pcsx2 created with this.
GSnull works nicely, though. :)
arcum42
Build files by Athostr, btw, though I've modified them a bit.
Jake.Stine
Yay, new build system work being done. I'm quite aware of what a thankless job that can be. >_<
arcum42
That's one reason why I'm glad Athostr decided to write these. Modifying them to get them to work properly I'm good with, but if I had to create them myself, I'd probably still be putting it off a few months from now... ^_^
arcum42
Oh, and I forgot; I made a slight change to ZeroGS. The comment is now wrong in the file I changed, because that "b" I changed to "S" is what was breaking -fPIC.
Though I need to test that a bit more.

Revision 2465

Fix some bad/flickering textures, caused by a too big GIF interrupt delay.
Fixes Drakan and a Tekken 5 game mode.
Thraay
Will have to see if this fixs the flickering ground textures in the swamp dungeons of .hack G.U. vol 3.
cottonvibes
rama: the size>>2 is wrong since that function is supposed to return the amount of qwc's processed (it is used for some wrap around logic in one place).
if the timing is the problem then we should remove some of the *2's like in the code below:
mfifocycles += (mfifoqwc) * 2; /* guessing */
that'll be a better fix since WRITERING_DMA() should return the number of qwc's processed.
Autor...
Fixes Issue 290 a bit, but some part on main screen and video on menu screen are filckering
ramapcsx2
Yeah, I should've checked better. Fixing.
ramapcsx2
Autoran1: Could I have another dump? The one you uploaded once is down now.
lemuel2010
ramapcsx2 good rev.

Revision 2466

changed an outdated comment.

Revision 2467

Commit Athostr's latest patch to the cmake build support to svn. Standardizes
the CMakeList files a bit, copies ps2hw.dat in to plugins, preliminary PortAudio
support. Only uses the builtin SoundTouch now.

Revision 2468

SPU2Null: Fix the release version.

Revision 2469

Just a few minor things.
pcsx2gu...
Guess it still needs that include there :P
Breaks compilation under Windows (VS 2008, Release target), but cleanups are nice :)
>..\..\R5900OpcodeImpl.cpp(846) : error C2065: 'macTrace' : undeclared identifier
12>..\..\R5900OpcodeImpl.cpp(846) : error C2228: left of '.EE' must have class/struct/union
12> type is ''unknown-type''
12>..\..\R5900OpcodeImpl.cpp(846) : error C2228: left of '.Bios' must have class/struct/union
arcum42
That wasn't the Windows build breaking (this commit was done in Windows) but the release build. I didn't notice that macTrace wasn't defined if you weren't compiling a dev build. I'll take care of it.
arcum42
Done.
pcsx2gu...
Worked, gj ;)

Revision 2470

Fix a screwup with the Drakan fix. Also commented it with the nice voodoocycles
tag :p
pcsx2gu...
Err is this if /*if (gif->qwc)*/ gscycles+= ( _GIFchain() >> 2 ); /* guessing */
Supposed to be commented out? :P
ramapcsx2
Yes.
// qwc check now done outside this function
pcsx2gu...
OK so this actually reverts the Drakan fix revision right? :P
ramapcsx2
No, it still fixes the 2 games. Only the place where I did it was wrong.
(The return value was also used for some non-timing related code.)

Revision 2471

Some sif fifo revisions.

Revision 2472

Refactor some Sif code.
arcum42
If should be a lot easier to compare what's going on in Sif 0 and Sif 1 now...
ramapcsx2
This is awesome. Proper naming, less lines of code. Great :)
arcum42
Thanks. I'm pretty happy with it myself. The names starting with fifo and sifdata had been bugging me for quite a while.
And I really like how those fifo changes worked out. Though, thinking about it, changing that structure might have broken older savestates.
Oh well, it's svn...
ramapcsx2
It seems to load states fine still. Stuff like this would be ok though if it broke states, just imo.
One major reason no one started rewriting/fixing SIF yet is because it was illegible.. :p
arcum42
Agreed. That's why I printed it out so I could look at it when not near a computer, with pen in hand.
I'm already seeing a few things, now that the code is lined up nicely. I'm pretty sure that that one spot that shoves things into a temporary sifdata variable should be putting it in sif1.data instead...

Revision 2473

Fix the release build. Minor Sif changes.

Revision 2474

A big old crapload of UI and thread management changes. Recoded the
EventSource/EventListener system to be more C++ and less hacky C. Probably
breaks Linux!
arcum42
Main trouble I'm having on this one is undefined references:
./.objs/devel/gui/pxLogTextCtrl.o: In function `pxLogTextCtrl::pxLogTextCtrl(wxWindow*)':
pxLogTextCtrl.cpp:(.text+0x34e): undefined reference to `vtable for pxLogTextCtrl'
I already took care of the inevitable throw()'s and non-POD safe objects...
arcum42
Things that currently seem to be broken:
Resetting - hangs on GS.
The Recent Iso menu - It is always blank when pcsx2 starts up, and new items don't get added until emulation starts.

Revision 2475

... forgot to save the linux cbp files before committing. >_<

Revision 2476

Limit EESIF1 scheduled interrupts to a maximum of 384 cycles, stops a lot of
timeouts and subsequent reschedules.
KrossX3
Ookami is booting up nicely. ^_^
azte...
it seems cool, fix many games?
Autor...
btw, why ee and iop changeas are commented?
ramapcsx2
Eh, they just spam the console a lot.
Should someone debug cycle stuff, the code is there to use though :)

Revision 2477

Hurrah for gcc.
arcum42
I'll fix cmake later.

Revision 2478

Minor fixes to the GS Window regarding suspend/resume and a certain nvidia bug;
and fix a bunch of compiler warnings.

Revision 2479

iop dmac branch: sync to latest trunk. partial commit [1 of n]

Revision 2480

Second try for nvidia driver bug in dx10/aero.
ramapcsx2
This one worked :)

Revision 2481

iop dmac branch: sync to latest trunk. partial commit [2 of n]

Revision 2482

iop dmac branch: sync to latest trunk. partial commit [3 of n]
gigaherz
This commit should make pcsx2 itself compilable, but the plugins will still be outdated.

Revision 2483

iop dmac branch: sync to latest trunk. partial commit [4 of n]
gigaherz
spu2-x is full of conflicts atm so I can't commit it.

Revision 2484

Fix the RecentIsoList.

Revision 2485

Vif Cleanups - did some code refactoring so things make more sense.
I need to do more later on...
I mostly separated the unpack code from the dma/transfer code in this commit.

Revision 2486

I give up on the dmac branch. It will be easier to just do this in trunk, since
it can be easily turned off.
I made it so each part can be enabled separately, but atm they are missing some
code so nothing will work if enabled.
Commit is mostly for backup/history purposes.

Revision 2487

Bring Linux project files up to date.

Revision 2488

Made the new iop dma use the hardware registers for MADR/BCR/CHCR, which lets
the memcards and pads work, at least in the bios.
gigaherz
Actually dunno HOW did it even work... xD
Maybe I was running the wrong pcsx2.exe or something... it's pretty much broken still.

Revision 2489

More vif refactoring/cleanups.
There is a lot of code duplication in the vif0/vif1 files, I will probably work
on getting them to use common functions.
cottonvibes
p.s. sorry arcum since this commit just made linux project files outdated again ><
arcum42
That's all right. This is exactly the sort of thing I split Vif0Dma and Vif1Dma for anyways.
aleing...
great :D

Revision 2490

More fiddling with Sif.
arcum42
This commit is mainly standardizing the functions a bit so they are easier to compare, and making notes as I start to get a sense of what the code is doing...

Revision 2491

Bring Linux project files back up to date.

Revision 2492

Vif: Combined a lot of duplicate functions between vif0 and vif1...
Still got some more to do...

Revision 2493

Get Grandia III working again.
arcum42
It broke in r2490. I'll have to look carefully at what's happening in that area of the code, because it shouldn't be that fragile...
azte...
thanks for game fixes, keep them around. ;)

Revision 2494

Vif: Finished combining all the duplicated vif0/vif1 command functions.

Revision 2495

More sif cleanup. tagMode is no longer needed.

Revision 2496

More Sif stuff. Factor out a few functions. Played around with SIF0Dma & SIF1Dma
a bit.
ramapcsx2
NO_BUSY_TEST sure looks interesting..
ramapcsx2
Ok, since r2490, the psxCycles value is different when we reach the irq time.
No big deal per se (just have to adjust the ecco hack :p ), but thought I'd let you know.
arcum42
Yeah, I was actually all set to enable NO_BUSY_TEST by default before I noticed that Mana Khemia's intro was crashing pcsx2. I might have one or two ideas of what's causing it. It's likely that EE & IOP are a little more entertwined then they should be.
It's still an interesting idea. It saves a lot of if statements, and ought to be a minor speedup. It was pretty late when I tested it, though, so I'm not sure how much speed it gains.
And at a guess, the psxCycle value change was from moving the (sif1.counter > 0) test from the top of the function to the bottom in SIF1IOPDma. It's horribly easy to break things in those functions.
At least I'm getting the hang of how they are organized and what they are doing. And the revision right before this, I'm pretty happy with, because I managed to get rid of the only use of tagMode, which really was a hack...
ramapcsx2
Yeah, don't worry about the slightly diff timing.
It's easy to adjust the hacks, though I want to wait for a better solution.
The psxCycle * 24 thing in particular is ugly. I'd love to get rid of it.
The problem is that our scheduled even testing system can't cope with this
very well, so it'll be hard to find a satisfying solution.
arcum42
Looks like Shin Megami Tensei: Nocturne broke somewhere between r2489 and this revision, too. Wouldn't be surprised if it's the timing. Don't have that game, though, so I'll have to go through my game library, and see if anything I own broke...

Revision 2497

Add some new checks for blocking VM reset/shutdown while savestates are saving
(avoids accidental corruption). Renamed a lot of the new event listener code so
that it's consistent... ish.

Revision 2498

SIF: Some logging that might be interesting when trying to fix this.
arcum42
Yep:
"EESIF1cycles = 0" is popular. Persona 3FES, Persona 4, and Phantasy Star Universe all spam it on opening. I'll have to watch them...

Revision 2499

Fixed a bunch of silly mistakes I'm ashamed of. no the bios can actually access
the memcards.
gigaherz
now*
Retrieved from "https://wiki.pcsx2.net/index.php?title=PCSX2_Documentation/Google_Code_svn_repository_comments_archive_2000_to_2499&oldid=41843"