PCSX2 Documentation/Google Code svn repository comments archive 1 to 999

Am pondering whether this could be responsible for the "Auron: Look!" bug in FFX, testing now.

Hmm nope, didn't fix it, however, there is a new message now:

"vtlbDefaultPhyWrite32: 0x213CA90"

Using European BIOS (not sure of version, but the hardware is the latest version of PS2), r613 of PCSX2, running from an ISO of the game.

QQ.

Revision 601

Completely botched my last commit. Left the IPU's cleanup only half finished.

>_<

Revision 602

Fixed a foopah in the LWL fix from earlier. >_<

Revision 603

Damnit. LWR() is a pita.

Revision 604

Modified the GIF and SPR in my wierd backward dma way :P should resolve problems

with the Avatar games, 24 videos and hopefully anything else which has broken

due to recent changes.

Revision 605

Small fix for a regression i caused in r604 with Ridge Racer V, also fixed a bug

in MAXbc on the VUrecs and added an optimization for MINIbc

voidsen...

somewhere between r595 and r605 the FMVs are broken, showing a bunch of green squares

That was caused by this revision. It was fixed by a reversion in 607/608.

Revision 606

Merged all recent bugfixes and stable changes into RC branch. (RC branch still

uses the old buildsystem)

Btw, my apologies. It's my fault for killing all comments in our repository. I was fiddling with some features in Subversion for changing commit logs and stuff, and apparently they cause Googlecode to erase all code comments. -_-

Omg, you gotta tell me how you did that :D

You can change commit log easily in Windows with TortoiseSVN.

I wonder how we can continue programming without any comment :)

Revision 607

Merged Ref's latest bugfix/opt into RC, after he and cotton finished debating

it's validity. (for score keepers: Ref won this one! ;)

hahah thanks ;p just dont wipe the comments again, or ill have no ammo!

lol

Revision 608

... see above.

Revision 609

RC: Reverted SPR "fix" from r506 for now, since it turned many game FMVs into

green screens, followed by hard locks. >_<

i think is r605!

wtf... the videos looked fine here, plus now the game will hard lock and crash, which i think is worse than the video hard locking after a bit :p

but what games had green blocks and hard locking? none showed here (Ridge racer videos have always had green blocks afaik, not just this change)

fixed now... lol

Revision 610

RC: Some important changes didn't get merged right, thanks to TSVN glitches. -_-

(it's been a long night)

Revision 611

SPU2-X: Another sync regression fix. My earlier experiments didn't fly, so I

reverted the TimeUpdate call in spu2_read also (negative impact on some dma-

related things, but fixes lots of other weird stuff).

Changed several instances of afxres.rc in plugins to be afxresmw.rc (for VS

Express)

Thanks for putting the inline assembly in in both Microsoft & GCC form; one less spot to change when working on the port... :)

It's just copied straight out of pcsx2, yea. ;)

Oh, it was, wasn't it?

I've passed by it a number of times; not sure why I didn't recognise it.

Still fighting with SoundTouch and ZeroSPU2; passing ../../ in the location for SoundTouch seems like it's screwing with when SoundTouch tries to find the configure.ac file, which is back in the ZeroSPU2 directory...

guessous...

hi Jack,

thanks for finally putting the mixer.cpp fix , for cubic.

However I don't know if you noticed that in issue 65 ,

i.e https://code.google.com/p/pcsx2/issues/detail?id=65

I've put additional comments.

Especially I persist to say that doing s32 mu = vc.SPc

is more accurate than s32 mu = vc.SP + 4096 when exiting loop.

Also I'm wondering if it's not worth to clip negative vals from

cubic interpolation. Anyway if this bother you, I won't insist more, promised !

Revision 612

Fix for my earlier mistake causing green blocks on videos, remind me its never

good to alter memory that you arent suppose to alter ^_^

Revision 613

RC: Merged unbroken SPR fix, and set the version number back. ;)

First of all, I'd like to say that some of the latest changes (can't

really say which revision exactly) affect Issue 46 to a certain degree,

something in the latest builds helps cure some of the issues Animaniacs:

The Great Edgar Hunt had with graphics, black and colored polygons no

longer flicker like mad and the textures don't flicker colors either.

Black and while polys do appear and flicker as you play, which looks like something SPSish as far as I can tell (or something of that kind at least), but a good deal of issues are gone by now.

And second, I just wanted to express my amazement at what you guys are

able to do. Being a coder myself, I have to admit that such level of

coding as PCSX2 demonstrates and such level of understanding both

hardware and software is way behind what I can possibly imagine.

PCSX2 is simply an incredible and unique piece of software - absolutely

astonishing. Keep up the wonderful work, guys! :)

Revision 614

Tagged SPU2-X v1.1 release.

quick changes to let ICC compile (note: also turn on /QxSSSE3 instead of /archSSE2 for a 9% speed increase on SSSE3 based PCs)

2 line-by-line comments

/trunk/plugins/GSdx/stdafx.h

r463

line 60:

60: #ifndef RESTRICT

nuke the #ifdef case for ICC, it doesn't use RESTRICT

/trunk/plugins/GSdx/xbyak/xbyak_util.h

r469

line 10:

10: #if (_MSC_VER < 1400) && defined(XBYAK32)

ICC should also take this path, since intrin.h is an MSVC thing and will break compile for ICC.

suggested to change to:

#if ((_MSC_VER < 1400) && defined(XBYAK32)) || defined(__INTEL_COMPILER)

How the hell those last 2 comments got there I have no idea, sorry : |

kva...

If You have error after posting, so don't refresh or don't go back. Just close google code and run it again, Your post will be here. This is google code bug i think.

My error is that it posted in the complete wrong place (meant to be in issues .. some how it ended here?)

strange, but we had a slight screwup with the code comments earlier.

Could be related :p

Revision 615

ZeroGS: Resolve issue 71 .

Revision 616

Linux: Get ZeroSPU2 compiling. May be modified later, because I'm not sure I'm

happy about manually copying libSoundTouch.a in build.sh.

Revision 617

Linux: Missed a plugin or two. Now it should compile.

Revision 618

Fixed a bug in the savestate system that caused memcards to eject when they

shouldn't have (had uint instead of u64 >_<).

Developers: Changed the way PCSX2_ALIGNED16 macros work, so that they're more

friendly to MSVC and Visual Assist X intellisense (more more red squigglies on

vars like cpuRegs!)

Revision 619

SPU2-X: Trying a new (experimental) DMA option which may fix problems in DMC1,

but might break more than it fixes? (we'll find out!)

Also - Added some options to DSound driver. Enabling Hardware mode on dsound

might improve dsound compat on some soundcard drivers, for those who can't use

XA2 or have problems with XA2 stability.

Going to try thanks.

Did you based this on the line code I added on issue 18 ?

Just tried it and the devil may cry problem is still there.

Oh I think I think where the error is, You add my line of code at the wrong place. (mostly my fault the code I copied is there 2 time)

The code should be put at Line 321

Sorry for comment spam. I mean line 302

Well.. i just tryed your new code with the line I added to the earlier code, And My line doesn't seem to fix devil may cry anymore. with this new dma stuff.

Hmm, yeah I should set it up so both of those share some of that code, actually. I think I can, anyway. Or maybe it'd be more trouble than it's worth.

As it turns out I only modified the DMA Reads (which aren't used very often by most games). Dunno if it would actually affect DMC or not. Could be your problem is random. I mean it sure seems random. The DMC Issue has been a series of "it works!" and "it's broke!" for like months from various uses, and I really don't see how any of this stuff could affect it in any significant way.

Well I With my modification (file in issue 18 ) I have tryed it ferry often to not let this be luck. ANd it was really working great.

I havent seen anything bad related to other games.

SO you may consider reverting the dma.cpp and put my linee of code and wait for feedback from others.

Revision 620

Plugins: Add a check for libjpeg-dev to ZeroGS( Issue 60 ), and a few minor

tweaks.

Delete configure file -- it's automatically generated from .ac

Sure, sometime in the next batch of commits.

Didn't even notice it was in svn. looking at the history, looks like it's been there for a long time, too...

And ine thing -- why we have commented cg checks?

Not sure; looks like it's been commented since at least pcsx2 0.9.4....

Revision 621

Quick tweaks to the Compile Guide to make it a little more clear regarding svn

revision tags.

Revision 622

ZeroSPU2: Change the ini file to be more easily editable by hand in Linux, and

assorted cleanup.

Revision 623

RC: SIO's memcard ejection fix from trunk.

Revision 624

Remove forceinlining on a few functions that won't inline, a few minor tweaks,

and add a warning in the build file for Linux x64 people trying to compile.

Revision 625

Linux: Remove the ICO Gamefix, since refraction took it out on Windows.

Revision 626

Linuz CDVD Iso: Fix a major Linux bug that was preventing certain titles from

loading in this plugin. Dark Cloud 2, Atelier Iris 3, and Xenosaga I for

example. No more switching back and forth between Linuz and EFP. :)

Finally tracked the bloody thing down. Surprised it wasn't causing issues in Windows as well, if it was checking if an unsigned variable is -1. :)

Oh, did find one game that still needs EFP. This is a big improvement, though...

Kudos for the fix accum. That plugin prevented me from running my svn compiles until I found out about it in an older post of yours.

Thanks. This bug has been a long standing pet peeve of mine; in fact, it was one of my bigger reservations about dropping 64 bit support, becase it only existed in 32 bit Linux...

Revision 627

Minor Optimization: Added Const support to Vtlb's Load and Store

implementations.

It's actually a significant amount of code, but the speed gain seems insignificant to me. In cases where const prop is available, the vtlb instruction overhead is reduced by 2-3 (10-12 less bytes of code generated). So it should certainly be faster, but might only really be noticable on AMDs, P4s, and older Cores.

I don't know why, but after this change the videos of Persona 3 FES that was sounding crackling until now (even if they got 60 FPS and lots of CPU power free), now sound a lot better (still not perfect though :D)

Anyway yes, i've noticed a little improvement in speed. :D

tiku...

Huh? I see all Persona 3 FES videos correctly, unless i use a 2x (or more) at EE sync hack.

With default or 1.5 they're running great, at least for me.

Yes tiku is right. Some game's FMVs tend to crackle if you're using cycles higher than 1.5. Anyway I approve this change, any optimization is welcome, thanks Jake.

@fea:

even if you are under fullspeed you will have only 60-70 CPU usage.

Thats due to MTGS.

Few percent on suikoden5 here. Anything helps I guess ;)

Revision 628

IOP Fixes/Optimizations:

* Fixed the IOP's recExecute so that it correctly preserves X86 registers (EDI

and EBX were not preserved!)

* Optimized the recExecute procedure, seems like a nice speedup in FMVs and

some games that are IOP intensive.

* Renamed psxMemRead to iopMemRead, added new Virt/Phys functions, and fixed

several instances of DMAs using translated addresses (DMAs are always physical

maps). Our IOP doesn't really emulate the tlb so it won't fix anything, but

it's more correct in cas stuff is better supported in the future.

* Removed unneeded FreezeMMXRegs, since the IOPrec doesn't use any mmx/xmm regs

anyway.

What are some IOP intensive games?

You forgot the "%" signs in front of the registers in pcsx2/x86/aR3000A.S

line 179 and 180. Breaks the build on the gcc platforms. they should read:

pop %ecx

pop %edx

Also in pcsx2/Linux/DebugDlg.cpp there are four occurrencies of PSXM still

left (line 249, 253, 321, 326):

mem = (u32*)PSXM(addrf);

could you change them to read:

mem = (u32*)iopMemRead32(addrf);

Those changes are all is needed to be back on track on the other

platforms, so please apply them since you have svn access.. thanks a lot ;)

I'd send a patch in the GNU patch format but I don't know whether they're usable on ms products.

Cheers.

They are useable in Windows with Tortoise SVN, which the whole team (or majority) uses.

Or, of course, I'm the Linux person on the team, so I'd be able to use this.

This update is a pretty typical issue, though. Any time a *.S file is updated, it's pretty likely that the %'s get left out unless I'm the one doing it... :)

Oh, and I'll change the lines in DebubDlg.cpp, but it's essentially dead code at the moment; it broke, and was already in bad shape when it broke, and I haven't spent the time to fix it yet.

>> This update is a pretty typical issue, though. Any time a *.S file is updated, it's pretty likely that the %'s get left out unless I'm the one doing it... :)

... because %'s are EVIL. X(

Certainly explains why I'm the one always committing them. :)

Revision 629

Linux: Quick fix for the last revision.

thanks arcum... I guess u got enough sleep time :P

Yep. And it was the same type of issue I see over and over again...

Revision 630

LilyPad: Minor dialog updates. Display FF axis names, display version in config

screen.

Revision 631

Fix a segfault issue in ConvertTo16 on ZeroGS, and make a few changes in spu2-x

for later use.

And yes, I'll change that copyright notice later.

yay, yeah I'll help work on some of that stuff in spu2-x soon. I needed to take an spu2 break tho. :)

Cool.

It still doesn't even compile as a null plugin, but figured I'd throw in what I had so far. I still am going to need to remove __forceinline on a few functions that gcc says aren't inlinable, and change a few u32's in Spu2.h to ints.

The Linux folder is still basically a jumbled mess. Adding the dialog won't be an issue; I was just waiting till it works as a null plugins till I did it.

One of the bits that would probably be the most helpful on it would be if you took the contents of the Alsa.cpp file, and changed them to be set up as a module in spu2-x...

I can understand needing to take a break, though. I cycle through different project a lot due to that...

Revision 632

MMI: Fixed a minor issue in PSUBUB/PSUBUH, and implemented recompiled opcodes

for PMTHL/PSUBUW.

ungigned 32-bit comparison? :)

@arcum42

lol, typo :p

cool, more opcodes :D

are there any intensive opcodes left wich aren't yet recompiled?

@nexxus86

Still there are a few in MMI, but genereally MMI opcodes are not intensive.

i mean in general an not MMI only.

All VU instructions, and almost all EE instructions are already recompiled. So this kind of opcode level optimization will not improve performance drastically, until AVX appears.

shagkon

What is AVX?

rbuldo

http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

s2d4thew...

Will this emu still be developed in 2011? :P

Probably. There are still PS1 emulators being worked on up to this day.

Revision 633

Bring in the ICC patch that makes pcsx2 build on that compiler.

Thanks to fea for this one ;)

Now we need only to fix some little details on the various plugins (GSDX crash on ESC and linking error on SPU2-X and Lilypad), to make everything working.

I'll work on it as soon as i can. :)

What 'linking error'?

SPU2-X and Lilypad makes link error on the .def file saying that there are some unresolved external. (on SPU2-X is s2r_replay, i've made a tentative patch on the issue, go and take a look, but i'm still not entirely sure it's the right way to fix this.)

I've completed the fix for SPU2-X. It is ready on the issue tracker, now i'll work on lilypad even though i think its basically the same problem. :)

Maked the patch for Lilypad too, i've posted it in the issue80 on the tracker. (with this the basic plugins compile perfectly with ICC)

Now i'm wrestling with the last plugin that doesn't want to compile. :D

Great work!

it let me re download the ICC compiler and re install it....

@fea: Oh yea, forgot about that one. I ended up just cutting the replay out of the ICC build.

When the dev team will review these 2 patches for SPU2-X and LilyPad and commit them we'll have a complete build set for ICC. :D

I'm now working fixing the minor plugin to build (the various NULL and such)

I test FF12, fatal fram1. It seems the ICC build and VC build have not any difference of the performance, though the ICC build size is almostly 2 times of the VC build. Maybe the critical part is GSDX.

When profiling the binary, it seems that most of the processing time is spent in the CPUs (EE / VU), so obviously this will mean that those prove the highest performance gain.

In saying that, you also have to realize that this is going to be optimized for INTEL processors, not AMD. If you compiled it yourself, remember to also compile the main PCSX2 Binary with SSSE3 optimizations, too.

my cpu is E5200，enabled all possiable optimization, include SSSE3 output. But my video card is N6600 and is the bottleneck. I ever oc my cpu to 3.0Ghz (defualt is 2.5G), and in FF12 the fps no change, so I feel the GSDX is the critical plugin.

Well, as GS emulation is largely to do with graphics, you couldn't hhave honestly expected an increase just by having (compiler-generated) code optimization anyway ; )

Although FF12 isn't really very graphics intensive is it? I've always seen it at max FPS and my system isn't really high end.

It depend HIGHLY on the game, on persona 3 i gained 1-7 FPS depending on the scene...(i have a Core Duo T7250 2 Ghz), on some other no gain. ;)

Revision 634

Yay more header file cleanup chores! Removed most of the Windows.h dependencies

from non-Win32 specific files, and fixed the annoying ARRAYSIZE warnings. Let's

say it together: "We all should love C's archaic include system, because it

makes Jake and Arcum work really hard for no good reason."

C++ and x86 asm are the two languages i program with, and i gotta agree with you, i cannot believe we'r in the 21st century and changes haven't been proposed to replace the include system with something more optimizied, in fact some compilers do the include job for you if they are smart enough. Check Codeblocks.

In /trunk/pcsx2/x86/ix86-32/iR5900-32.cpp from line 148:

ssprintf( filename, "dumps\\R5900dump%.8X.txt", startpc );

That's not a valid path for the non-windows platforms, I guess you should keep if the #ifdef _WIN32_ and use the "\" "/" path separators accordingly.

Cheers.

Actually I have nice functions to fix that, which are #ifdef free. I just got lazy because it's ugly dumps with no labels and I couldn't care less if they never work anyway >_<

So you change ARRAYSIZE to ArraySize? ZeroGS OGL should be fixing too.

Hmmm... Fixed the ARRAYSIZE warnings as in broke the plugin API? So we can start going through and making all the API changes that have been on our wishlists for a while now?

Oh, and don't worry, anyone who uses Linux. I'll have this working in Linux again shortly...

Revision 635

Clean up Jakes commit in r634, and get rid of some dead code in the assembly

files.

And, yes, I realise I left it building in debug mode. I'll worry about that later.

Yeah I forgot to mention that I axed the PerfCounter code. Using rdtsc and/or QueryPerformanceCounter is almost never a good idea for profiling code. It's just too unreliable.

The SamplProf.cpp for Win32 is better (does the same basic thing as like VTune and such, but on a much simpler level). Dunno if a linux equivalent could be made.

Probably. There's some profiling code in the opengl version of ZeroGL for Linux, though I'm not sure if it works.

Since I was in there, figured I'd axe the old x64 bit assembly, too.

Looking at the assembly, I really wish that __delspec(naked) functions wouldn't mix C and assembly, or at least would keep all the C limited to function calls, because that would make maintaining seperate assembly files a lot easier... (I was just looking at the PITA that aR3000A.S is. I'm still not convinced that it's implemented correctly...)

Well the ARRAYSIZE thing was just a problem I've had for a long time now. I actually added it to PS2Etypes myself, as I recall, trying to fix the Windows.h conflicts before. But no matter what I did I'd either get warnings or errors. So finally I decided to rename it completely. >_<

>> Looking at the assembly, I really wish that __delspec(naked) functions wouldn't mix C and assembly, or at least would keep all the C limited to function calls.

Yeah, not really possible, without really hurting performance. :( I tried some various things but I'd loose 5-10% speed usually. DispatcherReg is absolutely critical to performance of the emulator. I'd recode it as all asm but, as you pointed out, the one in R3000a.S is a mess, and the MSVC one would basically look the same, and then I'd have no idea if I did it right or not. ;)

But right now I'm getting errors on std::min/max -- the ones I removed and you re-added. I dunno why those are getting errors.

Hmmm...

I readded them because without the std:: part, they were coming up as undefined.

How about if you add using namespace std; to those files, and remove the std:: again? That'd work on the Linux side...

And it's a pity. I was hoping it'd be practical to, say, move:

s_pDispatchBlock = PSX_GETBLOCK( psxRegs.pc );

if( s_pDispatchBlock->startpc != psxRegs.pc )

psxRecRecompile(psxRegs.pc);

into a separate function...

R635 doesn't compile with vs2008

"std::" error

Yes, that's what me and Jake were just talking about. Removing them in r634 broke gcc, and adding them back in broke Visual C++.

I had a left-over windows.h I didn't remove. It was mucking with the min/max defines. >_< I'm fixing it now, along with finishing up some things I didn't do before.

>> And it's a pity. I was hoping it'd be practical to, say, move [...] into a separate function.

Yea, it'd simplify the asm a lot, but the overhead of invoking a function and returning from the function would be that 5-10% performance hit I mentioned before.

On the other hand, if drk||Razi writes/finishes his new block manager, it'd mean that the whole PC_GETBLOCK macro mess would go bye-bye and be replaced with a much simpler design.

That'll be nice.

And I hate it when an extra include mucks things up.

Still looking at .S files. Interesting to see a file dedicated to a Linux version of memcpy_mmx, and then realize that it's only used once in the program, and that use is only done on Windows for some reason...

Revision 636

Re-re-fixed the Windows.h mess. PsxCommon.h still had a win32 include, and

cdvd.cpp and misc.cpp had some win/linux code which I relocated. Also, cleaned

up the vtlb's SysExceptionHandler stuff -- moved the platform-specific portions

to WinSysExec and LnxSysExec, and moved the shared code portion to a new

function in Memory.cpp.

(Yes, Linux is probably broken again.)

Oops, forgot the other part I was working on when the std::min/max thing came up: I made some of the functions in the Path namespace API to be a bit more user friendly. :) They're not as "efficient" now, but eh, it's all gui stuff. Friendly code is more important I figure.

If you added a file without adding it's name into the list in Makefile.am, yeah, it is.

Not an issue, though. I'll merge the minor cleanup I was doing with fixing this. (I'm adding a header with most of the extern "C"'s for the assmebly files in it, so they aren't scattered all over the place...)

Never mind, you did add it. :)

https://code.google.com/p/pcsx2/source/browse/trunk/pcsx2/Linux/Makefile.am?spec=svn636&r=636

I added it :)

... but I'm sure I broke something else anyway :p

hi,jake

can you add a ICC optimization configuration on the wiki page

after the windows and linux both work ok :p

thanks your and arcum42's hard work

Eh, we'll see. I have to get my code changes working properly before I update and fix anything that needs fixing.

Guess I'll fix up memcmp_mmx afterwards. Looks like it needs extern "C"s for FreezeMMXRegs...

Oh, I can do that. I just put it on hold for a few minutes while I checked to see what broke in this commit. Right now Linux isn't using memcmp_mmx at all, but the reason it isn't is obsolete. That's why I was looking at it...

Incidentally, the only thing preventing this commit from compiling on Linux was the capitalization of "cdvd.h". :)

Revision 637

microVU rec stuff

Revision 638

Fix Linux. Move most of the externs for functions in .S files in Linux to one

header, and reenable using memcmp_mmx in Linux.

Think I accidentally reverted a minor change to SuperVUInitLiveness.

Easily fixed, though, and it's not something that'll really cause problems.

Looks like I need to make a few minor adjustments. Another commit will be on it's way shortly...

Actually, looks like something else broke Linux, though it compiles. Time to play with it a bit...

I may have very well screwed something up in my commit.

In what way is it broken? Ie, does it crash, and where/how?

Running any cd gives:

...

# 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=2003-0325, 32M

loadcore RegisterLibraryEntries (1944c): sifcmd

intrman RegisterIntrHandler (19478): intr INT_dmaSIF1, handler 183c0

Protected memory cleanup. Offset 0x10c0

...

Ok, yeah I broke the Exception Handler. It's probably not masking the pagesize correctly.

Yp, that's what I did, but not to the pagesize. I actually got pageoffset and pagesize kind of confused. I'll commit the fix momentarily.

Oh, yeah, I think I see it:

SysMemProtect( ptr, 1, Protect_ReadOnly );

The debug build's broken, too, but that's easy to fix. a .cstr() was left out of iR3000A.cpp on line 197...

Nah, SysMemProtect on the Linux side automatically transforms the 1 into a 4096 now, so that the code for Win32 and Linux can be the same in Memory.cpp. What I forgot to do was align the pageoffset also.

Ah. Hadn't looked at it that closely yet.

In any case, I'm building it now, so we'll see.

This break the ICC build of PCSX2, i'm working on a patch and i'll post it here as soon as I can. :)

Posted on the last comment of the issue69 . Review it and post it on the svn.

Revision 639

Enabled PCH for w32pthreads library. It compiles a *lot* faster now. ;) [whole

thing rebuilds in under a second on my machine, heh]

Revision 640

Linux: Fix the SysPageFaultExceptionFilter so that it aligns to the pagesize.

Revision 641

Ah fudge. -_-

That did it. Back to normal...

Revision 642

90% of an implementation of memcpy_fast_ for Linux. And fix debug mode.

The copy of memcpy_fast_ in this commit is broken, but is most of the way there, so I wanted to commit it before anything happened.

I've already fixed the conversion mistake I made, but when I commit it, I'm going to temporarily make it optional, till I know how reliable it is.

StarOcean gives different errors with it on, which I find interesting...

And now I can't reproduce that. Weird. Oh well, it'll probably be a short test period.

Revision 643

Finish the Linux implementation of memcpy_fast_. I've disabled it by default

until I'm sure it's working right, but it can easily be enabled in build.sh.

Should be a speed boost in Linux (which Windows already had), but I haven't

tested it enough to be able to tell yet.

And, in fact, even thought it started up properly a minute ago, now it's not working again.

Irritating...

Oh well, I know the fix was right. I probably overlooked something minor.

Revision 644

Win32: One more foopah left over from r634 needed fixing, this one caused games

running at very high FPS to "freeze" for 2 second intervals at a time.

Heh. Brought the multiplier in from Linux, I take it?

Oh well, it happens...

Revision 645

Get the Linux side of things ready for when cotton's done with microVU. I'm sure

I'll have to make significant changes at that point, but it's good to have the

framework in place...

I was probably overparanoid with the #ifdef's, but I didn't want to mess up anything cottonvibes was working on.

Think I'll wait on anything else on this till microVU's actually done, though.

i'm doing major emitter changes now, so i wanted to backup my microVU work.

so its best to not port it to linux at this time since the current code is broken and WILL change.

No problem; I just mainly wanted the structure to be there, and to actually have the assembly file ready, even if the contents were going to majorly change.

And I'd already decided to comment out my changes to configure.ac next commit; I just haven't gotten to my next commit yet...

Revision 646

A few minor changes.

Intel build fixed. :)

Yep. Don't expect me to remember what breaks ICC, though. It's hard enough trying to keep track of what breaks gcc and Visual C++ at the same time. :(

Don't worry, i'll remember and make patch for you whenever it happen. :D

Revision 647

major pcsx2 emitter change.

the emitter is now 'templified' so that you can run multiple instances such as:

eMOVRtoR<0>(EAX, ESP);

this uses emitter instance #0

to use another instance you can simply change the number in the brackets like:

eMOVRtoR<1>(EAX, ESP);

will use instance #1.

all old-functions are mapped to instance #0 by macros.

like:

#define MOVRtoR eMOVRtoR<0>

why do this to the emitter?

so we can have thread safety, and eventually thread the recompilers using

different emitter instances.

note: this took me forever to get working (around 12 hours of non-stop coding).

however for some reason debug build is being extra-picky and still giving

compile errors.

hopefully Jake or someone else can fix this, because i tried a few stuff, and

just got more compile errors ><

I think you forgot the ix86_macros.h file...

yeah i did, sorry :P

And you brocken Linux build too

All right, here are the issues I'm running into so for:

First, none of the functions in ix86.inl are in headers. And they need to be in headers, because some of them are calling functions that are implemented later in the file.

And a few of them are calling functions that aren't implemented at all. I'm assuming eeNOP is a typo for eNOP, but I'm not seeing eLEA32RStoRI anywhere.

Incidentally, there were the ones I ended up adding to ix86.h, becides uncommenting the ones that were already there:

emitterT void eMOV32RtoR( x86IntRegType to, x86IntRegType from );

emitterT u32* eJMP32( uptr to );

emitterT u8* eJMP8( u8 to );

emitterT void eCALL32( u32 to );

emitterT void eLEA32RtoR(x86IntRegType to, x86IntRegType from, u32 offset);

emitterT void eLEA32RStoR(x86IntRegType to, x86IntRegType from, u32 scale);

emitterT void eNOP( void );

emitterT void eAND32I8toR( x86IntRegType to, u8 from );

emitterT void eAND32ItoM( uptr to, u32 from );

emitterT void eLEA32RRtoR(x86IntRegType to, x86IntRegType from0, x86IntRegType from1);

emitterT void eAND32I8toM( uptr to, u8 from );

emitterT void eLEA32RStoR(x86IntRegType to, x86IntRegType from, u32 scale);

You know, I just realised: eLEA32RStoRI should actually just be I. Must be an accidental paste. Never mind...

Revision 648

these files aren't needed anymore

Revision 649

accidentally deleted this file and didn't include some other file ><

Revision 650

minor VU fix thanks to nneeve

Revision 651

MMI: Added recompiled version of PPAC5/PEXT5, and optimized PADDUW a bit.

Another instructions is great always like such sort of commits

Revision 652

Added the second part of emitter macro functionality, by making the emitter

instance configurable. We can't actually use it yet tho, since everything

shares iCore, and thus everything needs to share the same emitter instance (for

now!).

Fixed new emitter so it compiles in Debug builds, cleaned up the header files a

bit.

Linux build is still brocken. How could ModRM<I>(something) be compilable?

Believe me, it is. Linux commit coming out shortly.

Revision 653

Fix a few typos, as well as Linux.

The .inl files shouldn't be compiled as source files. They're actually include files only. So you should be able to remove them completely from the source list and add them as include dependencies instead. :)

This worked, and I didn't see much info on using gcc with include files.

I like having all the files listed there anyways, and it doesn't really hurt; you'll notice I've got headers in the makefile, too...

Revision 654

Committing the beginnings of a new PS2 Exception Handler! This is very much a

work in progress, but it shouldn't really break (or fix) anything in its current

state.

EE Interpreters: Fixed some signed/unsigned mistakes in some instructions,

namely DIVU, DIVU1, unsigned Traps, and a couple unsigned right shifts. (all of

these were already emulated correctly in the recs)

Also: Removed the ThreadPriority stuff from Pcsx2, since it was a throwback to

the days of Win95's unstable multitasker. If you really really feel like you

need to change the thread priority of Pcsx2, use the Windows Task Manager or a

third party util.

What improvements will this new exception handler bring with it?

I honestly haven't got a clue, but it's fun to code! :D

gamersat...

Uggh more ini changes. Just what I need.(Keep up the goodwork :))

Hopefully it should help use easier diagnose emulation problems and give more specific infos to pass to devs for looking at

Revision 655

Fix up the last revision for Linux.

Oops I forgot the GCC magic throw() fix. >_<

That's all right; I'm starting to get used to the general nature of things that Visual C++ likes, but cause gcc to throw() fits.

Oh, and the reason why I deleted #include <sys/mman.h> is because it's already in LnxSysExec.h.

And I'm off to work. Hopefully things won't be too broken when I get back...

Yeah that's fine. I figured it was already included but couldn't really test to be sure, so I made the note so you'd know to delete it or whatever. :)

Revision 656

LilyPad: [email protected]'s suggested changes for ICC compatibility

Revision 657

SPU2-X: Fix for DMC1, closing Issue 17 once and for all; also added ICC patch

from Issue 75 .

By Issue 17 I mean Issue 18 . >_< I'd fix that, but last time I modified a commit log, it wiped all of our user comments.

This comment is off-topic to this revision but not really relevant any where else either.

I was doing some digging around on assembly optimizations (bored, trying to learn). I happened to come across this site (http://www.agner.org) by Agner Fog, Ph.D; he's written some papers, proposed theories etc..

Anyway, I came across a part of the site where he keeps an 'optimized' asm library of various functions such as quote:

"This is a library of optimized subroutines coded in assembly language. The library contains faster versions of common C/C++ functions such as memcpy, memmove, memset, strcpy, strcat, strlen, etc.."

I know you have an optimized version of some of these already in pcsx2; had support for sse2/sse3 optimized versions and in another zip file gave insight on future optimization in regards to sse5/avx.

Anyway the relevant files are @

http://www.agner.org/optimize/ < Optimization Page

http://www.agner.org/optimize/asmlib.zip < Lib & Source

http://www.agner.org/optimize/asmexamples.zip < Comments about Future Optimizations

Sorry if this stuff is of no use. I wouldn't doubt you had seen it before.

Yep this work. Great job.

I have a question for jake.

Do you know if this is common in programming that you compile stuff and it work a way then you compile it again and the result may be different?

Thats see to what happen to me with my "suposely fix"

first time I compile it make a working DLL for dmc. THe second day, I compiled the same code and it didnt work :/

Thanks.

@Wagnard: Admittedly, your "fix" was a pretty dangerously random thing, and I have no idea how it actually ever worked. :)

@trigunflame: Thanks for the info! Great stuff. I've been wishing for a good optimization info source.

Glad to know it could be of use to you. From what little I've read from the papers, this guy really knows his stuff.

Hopefully it will help you and the others gain some insight and tips.

@jake hehe I know. Its was kinda random. I took some code from the working old revision in playground and patch them in.

I guess I just got ultra lucky.

Revision 658

Set up the x86 emitter so that it always uses MOVAPS over MOVDQA. This

generates slightly faster code since movaps is 1 byte shorter than movdqa (both

instructions are functionally identical). The optimization is optional via

AlwaysUseMovaps defined in ix86_sse.inl

Enabled optimization stuff for zlib and bzip2 projects (Release/Devel build

targets).

I hear, that MOVDQA have one advantage over MOVAPS on AMD processors (when moving fro reg to reg).

p.S. There is also one difference in Real Mode :-).

Screws Shinobi's FMV :) Sorry

Persona 4 FMV too.

voidsen...

if i'm not mistaken this also breaks fxii when entering the ingame menu

http://i97.photobucket.com/albums/l230/kebrus/bug.jpg

i'm not really sure if it was this revision specifically, but since it's breaking other games i thought it should be related (it's somewhere between r634 and r662 :P )

FFXII problem is caussed by r651. I'll fine an issue and assign it to tmkk.

Revision 659

Fixed a problem that VU clip flag wasn't propagated correctly between recompiled

blocks in some cases. SPS in Rule of Rose will be fixed by this.

And one more SPS game down. Great job! :)

I don't know why but this rec screwed Shinobi FMVs

Is that confirmed to be caused by this revision? Ie, did you check r658 also to see if it had the same problem?

Sorry I made a confusion. It's rev. 658 that screwed Shinobi's Fmv. Thanks for fixing Rule of Rose anyway.

YAY

Many thanks for you tmkkmac!

I suspect this revision for breaking God of war.

There is a lot of SPS

Change my "suspect" to confirm. rev 658 work and not this one

Look's like yuo've broke old VU CLIP Gamefix for God of War *we need it once again*

Revision 660

Fixed a bug in r658 caused by some sloppy macros.

Win32: Moved various debugger-related dialogs into a new debugger.rc file, to

help reduce clutter between both the std resources and the debugger resources.

s2d4thew...

debugger.rc(3) : fatal error RC1015: cannot open include file 'resource1.h'

Woops, I totally botched the commit for the new .rc file. ;)

Revision 661

Proper uploading of new debugger.rc and it's header file. :)

Revision 662

Linux: Fix Issue 78 (Pcsx2 crashing if you change graphical plugins).

Revision 663

Fixed the problem in recompiled version of PPAC5/PEXT5. I forgot about the case

with Rt == Rd.

Revision 664

SPU2-X (Linux): Did some preliminary work on the Alsa driver.

Cool. That'll help a lot...

Revision 665

Nneeve coded a new FPU clamp mode "Full" that can help some games which wouldn't

work with the other modes.

This fixes the Digimon menu for example (Gamefix will stay a while longer

though, until we confirm ingame is fine as well).

He also updated the advanced dialog a bit.

Remember that this mode can break games if VU clamp is below "Extra + preserve

sign"

<nneeve> it fixes FFX's reversed controlls on some screens (like the airship)

<nneeve> it fixes klonoa 2's green balloon positioning

<nneeve> it fixes ape escape 3's backgrounds (not to be confused with tmkk fixing the major SPS issues with the game a few revisions back)

it's likely to fix other things as well.

As said, a few games may have issues when "full" is enabled in EE but "extra+sign" isn't enabled in VU. Ar tonelico is one such game.

The games listed above seem fine even with EE at "full" and VU at "normal".

Revision 666

You might need this one as well :p

I'll include my comment about the "Full" option here as well:

<nneeve> it fixes FFX's reversed controlls on some screens (like the airship)

<nneeve> it fixes klonoa 2's green balloon positioning

<nneeve> it fixes ape escape 3's backgrounds (not to be confused with tmkk fixing the major SPS issues with the game a few revisions back)

it's likely to fix other things as well.

As said, a few games may have issues when "full" is enabled in EE but "extra+sign" isn't enabled in VU. Ar tonelico is one such game.

The games listed above seem fine even with EE at "full" and VU at "normal".

Another one "revision of the beast"... :-) Congrats...

PS: Sorry, even if I've read RevisionReviewEtiquette :-)

And adding the new sourcefile into atohell configuration file, so it could be compilable under Linux. I don't know -- windows does not require exact listing of all sources?

Sorry, I don't touch linux stuff. I'd break it instantly.

Linux compilers, makefiles, configuration files and command switches all look like some alien language to me :D

This change (the EE "Full" Mode in particular) appears to fully resolve Issue 46 with Animaniacs, a quick run through the first couple maps has showed that no flickering polygons or other trace of SPS is present in that game, I'll try to check and see if it's fully playable now.

Magic number revision :p

Comment by ramapcsx2, Today (61 minutes ago)

Sorry, I don't touch linux stuff. I'd break it instantly.

Linux compilers, makefiles, configuration files and command switches all look like some alien language to me :D

XDDDDDDD

that from the guy who learned programming for pcsx2 on the hardest way I can imagine^^

Actually, adding a file in Linux is pretty easy. Most of the folders in pcsx2 have a Makefile.am file in them, and near the bottom, you'll see all the headers and cpp files in the folder listed, separated by spaces, with \ symbols at the end of the lines to tell it that there's more filenames on the next line.

All that has to be done is adding the file name in the list. But I can do it, of course...

Thanks for the explanation, arcum.

Still, I'd like to take you up on your offer, especially sine I can't test anything I do in regards to Linux.

(No, I'd rather not fight with some distribution in a vm or stuff like that ^^)

Hey, Jake writes whole Linux files without testing them. :)

Actually, though, any time I update, I always look for files added to the svn, and add them to the appropriate makefile, so it's no big deal.

Adding things to the advanced dialog box is trickier for me really. Mainly because I have to connect what you do in the gui to what the Windows code says, which isn't always obvious...

bfb...

It fix lot of things in ICO

1)intro doesn't freeze now.

2)FFX was not the only game with "reversed controls bug"

3)Small graphic bug with dissapeared geometry also fixed.

Thanks. :)

Yes, I've already noticed it myself...

Guys, this build is awesome, best of all!!! Maybe it's because of it's number?.. :-)

Does all that mean that we must have top-of-the-line PCs to be able to play most games WITH good fps and WITHOUT glitches when we enable "Full" EE clamping and "Extra+sign" VU clamping?.. When I enable theese most games run 2 times slower at least...

The "more" clamping you do, the more pcsx2 behaves like the ps2 would for special cases.

So yeah, if it wasn't so expensive to use, we'd just put it all on maximum and remove the options :p

Well FULL on my pcp didnt seem to affect compared to none. :)

Good work!! Too bad it didn't fixed Shinobi SPS.. Damn game. =p It simply refuses to get fixed :)

Basically, EE's "Full" doesn't slow down things much (a few FPS might be gone for a few games). But it's not fully compatible with VU clamping options aside from "Extra + sign". And that's slow (very slow if you don't have SSE4.1)

Revision 667

Added Nneeve's fix for some issues in VU pipeline. SPS in Arc The Lad will be

fixed.

Added a temporary gamefix option for God of War, which has been broken since

r659. Anyway I'll fix this problem in a proper way.

And as usual, linux part is not touched.

UI changes are done mostly in Glade-2 (or 3), and I'm not even sure that runs on Windows, so not a problem...

Arc the Lad Fixed! Now I would have another testgame.

Thanks!

Arc the lad fixed? AWESOME.

Revision 668

Fix Linux, and update to match gui changes.

For those curious about how the Linux end works, all the changes made to pcsx2.glade were made by a program called Glade. It then generates interface.c & h, callbacks.c & h, and support.c & h.

The other changes were done manually...

It is theoretically possible to dispense with the c files I mentioned, and generate the gui from that glade file, incidentally. The times I've tried to switch over to doing that have resulted in nasty segfaults, though... :(

It's due to having to be *really* careful about threading issues.

You made a "full" radio independent of all others -- it stay always turn on.

Oops; didn't notice that. I'll take care of it.

Weird; the copy of glade 3 I have isn't letting me change radio groups; it just stays blanked out. Guess I'll use glade 2, instead...

Revision 669

Pontifice from our forums fixed some cheating related code he wrote for pcsx2

earlier.

This supposedly makes using codebreaker / ar max cheats more reliable :p

Thanks for that, Pontifice ;)

Makotech...

through codebreaker.elf? or patchfiles? patchfiles always need help... :) thanks

Given what code was modified, it would be patchfiles.

Revision 670

minor emitter fix and dialog text tweaking.

hah, I wonder how my search/replace missed it?

nah they were added after your search/replace.

nneeve added new emitter instructions for his fpu fix, and forgot to change them ;p

Revision 671

Quick fix for r668; the new radio buttion hadn't been assigned to that group.

Revision 672

backup, just ignore this

Revision 673

necessary change to properly compile microVU's templates (c++ is picky with

templates :p)

How much longer do you suppose until this is actually integrated?

Revision 674

i assume these headers aren't needed anymore but were accidentally left in VS

project file :p

Revision 675

Major GUI API Cleanups. Most likely buggy as all hell.

* Moved most of the shared code between the two GUIs into platform independent

source modules (System.cpp, Saveslots.cpp, and RecoverySystem.cpp)

* Created two new namespaces which house functions that need to be implemented

by OS/platforms: HostGui and HostSys. HostGui is useful -- HostSys I'm not sure

I'll keep around in the long run.

* Moved keyEvent struct from PS2Edefs.h to PS2Etypes.h

* Many improvements to the logic flow of the GUI (should be a little less

fallible).

Yep. Given that once I got it compiling, no keys worked while running the emulator, and I got lots of messy warnings when saving, buggy as all hell.

Fixed the first, and I'm working on the latter.

Like the abstraction, though.

Well, tracked down what's happening when the segfault happens, anyways.

It tries to save a slot, States_Save gets called, which then calls SaveToFile. g_RecoveryState is NULL and g_gsRecoveryState is NULL. g_EmulationInProgress is true. So it calls States_Save, which calls SaveToFile again, ad infinum...

This also tells me that a variable isn't being set properly somewhere in the Linux files...

Revision 676

Damn buggy TortoiseSVN >_<

Revision 677

Savestate version upgrade and stability fix -- added some vars that the SPRdma

might like to preserve between states, and removed some old hacky VM-related

stuff while I was at it.

Fixed up the Saveslot detection somewhat (File:Load > menu now greys out

unavailable saveslots).

Applied ICC fixup patch from Issue 84 . :)

I keep getting errors like these with ICC on gsdx for some reason, trying to figure out what's causing it.

Any idea? Here's a link to the output thusfar.

http://trigun.linkpc.net/console.txt

Ah, fixed it; was the same issue as jdastridge; had to to enable restrict support.

Revision 678

Gah! I forgot a line in my prev commit, so the SPRdma savestate fix wasn't

actually being used. Btw, this *may* fix unstable savestate problems

experienced in many games, including FFX and SMT3:Nocturne (but it;s so random

it's hard to know for sure).

Revision 679

Linux: Get everything compiling again. There is still a nasty crahing bug or two

from r675, in particular when using the menus for load and save states rather

then keyboard commands. I'll work on fixing that tomorrow, but wanted it to at

least compile and run.

Gah, the pad plugin API is such a crapfest. I tried to do the one thing to fix the double-key problem that happens whenever you have 2 mismatching pad plugins, but it doesn't work either because some PADs don't return null. Maybe I can fix it yet...

Also, sorry for forgetting to go back and remove ExecuteCpu(). I ended up refactoring code like 5 times, and by the 4th or 5th time my win/linux changes were completely out of synch -_-

It could partially be ZeroPad, too. Keep in mind that it's the only pad plugin for Linux. I have an issue or two with it otherwise, but I think it's the SDL api it uses for joystick input...

No problem on the ExecuteCpu()s. The one that's really worrying me right now is the fact that OnStates_Save (which is called when a savestate is chosen from a menu) crashes pcsx2. It works fine from the keyboard.

I mainly committed now rather then waiting because people start filing bugs if I leave the Linux version totally broken for more then a few hours...

Revision 680

SPU2-X: Resorted the mixer so that it's a little faster, and will be easier to

apply some SSE2 opts in the future.

What I did here is set it up so that the mixer is organized into a set of smaller loops, instead of one huge unrolled loop. This makes the code much more cache friendly. Additionally, I've sorted all the data so that it can have SIMD optimizations applied to it in the future (although I may have overlooked some alignment requirements in V_Core... >_<)

I hope all that optimizations will not break DMC1 again... ;-) Good luck anyway...

Revision 681

SPU2-X: Fixes alignment condition for SSE2-dependent members of V_Core. I

wanted to sneak this in quick since to do it later would have meant another

savestate version.

Revision 682

pork chop sandwiches!

GI Joe - Pork Chop Sandwiches ?

It's great that you're still working on MicroVU :)

Good luck

fnh800: indeed ;p

ntcong.it: thanks :D

Revision 683

IPU Bug/Feature fix: Pseudonym has coded a new yuv2rgb decoder which is up to

IPU spec (which differs slightly from MPEG spec). Improves color hue/saturation

on many vids, and is a bit faster too.

Dynarec: Removed RET2().

Good Job!

Right now Linux accepted only PCSX2_ALIGNED16(u16 C_bias[8]) format, no

PCSX2_ALIGNED16(u16 C_bias)[8]. I could be a bug here, or in ALIGNED realisation.

sudonim1

Oh, you're right about the aligned macro, my mistake.

As usual, I see the comment mentioning the problem after working it out... :)

Revision 684

Tagged the 0.9.6 Official Release, in all of its glory.

Revision 685

microVU stuff

valeri...

god of war no longer works properly

When this new mirovu stuff get in action what should we expect?

Is it supposed to help the speed?

@valeriok9.

The gamefix is back for god of war. Check if you have it enabled.

valeri...

@Wagnard28

sorry I had not seen who had been reinstated the GameFix

Revision 686

Linux: Fix compilation and a typo in my last commit.

Revision 687

Pseudonym Crazy-Opts Projects Inc presents: Improved block managers for EE/IOP

recompilers! Basic asm optimizations combined with a technique of replacing

NULL/invalid pointer checks with a direct link to a JIT dispatcher. A collab

effort on irc produced this gem, which improves speed on all accounts, and even

makes the linux .S files uber-simple and clean. (no more wondering if they're

broke or not!)

You forgot to change Linux #ifdef part for psxDispatcherReg!

And you made

.global JITCompile

instead

.global iopJITCompile

in R3000A.S

Afther this two fixes, Linux build is compilable again

I'll patch that up. Having this code actually be the same for Linux and Windows is great, though...

Seems like there are quite a lot of "IOP Recompiler data reset"'s now, though...

Yea the recClears aren't optimal, but then they're not critical to performance either.

As long as it doesn't add a performance hit... I was just startled to see it printed a dozen times within minutes of starting up a game...

sudonim1

There was some communication mixup, the patch was just a snapshot of my working dir and wasn't commit ready. It's buggy because it's buggy.

This breaks ICO

Revision 688

Linux: Quick fixes to the new .S files, and did a mild cleanup of the recLUT

macros.

these 2 revisions broke grandia 2.

Revision 689

Experimental commit!

Hacked in a way to make GSdx change the renderer on the fly.

When you press F11 it will switch to DX9 sowftware rendering.

Press it again to get back to the setting you were using before.

Notes:

-For this change I had to modify a few lines in GSdx. If that's not acceptable

we can do more drastic measures and modify the gsdx.ini :p

-F11 is currently also used for doing gsstates in debug modes, it will likely be

changed.

-When in dx10 hardware + fullscreen mode, pressing this key will crash GSdx.

Sorry.

And why this should broke linux build too?

extern bool renderswitch -- it does not defined. I prefer that such variables be defined in os-independent files, and externed in os-specific.

chuuey

just tested this new feature with Persona4 and FFX, seems stable and there are no problems switching between two states, also there could be a note in the main window somewhere that we're in the software mode currently, or in hardware mode, anyway this thing helps pass some low fps moments with hardware mode etc, good work :)

Zeydlitz:

Ok, complaint noticed. It will get changed anyway.

This commit is to show what i wanted to do and it's not final in any way.

Zeydlitz:

I prefer that linux isn't supported at all, but i don't write to comments about it.Be happy with what you get, and if you have any complains about how the project works either write your own ps2 emulator, or use the last release.Svn is for developers, ppl with no life, and internal testers that can understund what wip means.

MadRabbi...

Nice Hack. ATV Offroad Fury 4 playable very simple now, thanks.

RAMA! You did it! :P

Yeah, as I said: gabest doesn't accept any feature requests :P

Revision 690

Better implementation of MSVC's _SCL_SECURE macro, plus some PrecompiledHeader.h

cleanups.

Revision 691

Patch up the last few commits for Linux.

@arcum: Did you notice the cool new "noprefix" thing I found?

No more evil %'s! Yay :D:D

Yeah, I saw that. Might go through and apply that to the rest of the Linux assembly, just to make keeping it in sync easier...

On the other hand, it decreases my position as purveyor of evil in the pcsx2 code... :)

Thanks a bunch, arcum. I'll make sure to care for these defines when the thing gets changed ;)

No problem. I thought about just adding the code to Linux, but unless the directX and openGL versions of ZeroGS get unified into one plugin, I didn't see a need...

Plus, this is specific to Gsdx. ZeroGS plays most FMVs well enough in either mode. GSdx doesn't replay some vids correctly (sometimes not at all) in hardware mode.

Revision 692

Added Path::GetFilenameWithoutExt, and fixed some other PathUtil API layouts.

Revision 693

Remove lots of evil %'s.

I skipped any code that wasn't in intel syntax. And I'm pretty sure that first one should have been in intel syntax, but I wasn't as familiar with assembly in gcc at the time...

Revision 694

pcsx2: -highpriority switch, other processes generate too much noise and I

cannot trust my performance counters without it :P

GSdx: nothing new just committing a few cleanups and my findings on AA1 before

doing it, tested a few things with ps2dev on a real machine, got really strange

results when not using the standard 0 1 0 1 blending mode, but it doesn't seem

harder to implement than a line drawing (which it is), and only adds a few extra

pixels here and there, should be fast at least.

Revision 695

Added googlecode's sparsehash / densehash classes, which may or may not be

useful in the future.

Removed various instances of legacy VM code that is no longer needed for

reference purposes.

Lothar...

Missing HashTools.cpp

Revision 696

Added missing files from prev commit.

Lothar...

Thanks

Break the ICC build, i've posted the patch in the issue69 .

Revision 697

Linux: Some work on the plugin code.

Revision 698

Made the GSdx render switch thing a bit cleaner, moved it where it belongs

and changed the hotkey to F9. (Sure hope no plugin uses that yet :p )

changed the code a bit :D

if (mt == 2){ //pcsx2 sent a switch renderer request

//renderer = 1; //DX9 sw

renderer = AfxGetApp()->GetProfileInt(_T("Settings"), _T("switchto"), 0);

mt = 1;

and it works.

set switchto=7 in the gsdx.ini and press F9 in Valkyrie Profile 2 when you're in Solde, you'll see this game is so damn much GS dependent.

It seems Ridge Racer V (PAL I think) doesn't like this hard/soft render

change mode on the fly at all. The game is hanging in the intro FMV.

Revision 699

Move the configuration section of Misc.h to a new file, Pcsx2Config.h.

Revision 700

Fixes for the new block manager optimizations by Pseudonym.

There's a bit more speed even :)

Revision 701

Nneeve patch for "Full" FPU, improves some clamping and adds missing values to

the savestate info.

Savestates: Pcsx2 now errors when it encounters a savestate made by a newer

version of pcsx2.

Added a new SafeList type to the SafeArray collection (not well tested yet).

I hope "version" -- is savestate version, not revision number?

You use IfDevBuild, that defined in System.h in SaveState.h, but I don't see any signs of #include "System.h" in it.

Revision 702

Buged my last commit (as usual). This one fixes savestate support. :)

Revision 703

More block manager fixes/optimizations by Pseudonym.

This should be the last one (but you never know :p ).

Wow that's a lot less multiplications.

Well the *2 muls don't really matter mcuh, except that they save the CPU from having to use as many temp registers. But it does mean that Pcsx2 uses almost 50% less ram now!

And new function iopJITCompileInBlock -- should be added in NakedAsm.h and aR3000A.S.

Sorry, two functions: JITCompileInBlock too :-). In aR5900.S and NakedAsm.h

And after that the PCSX2 is crushed right after the start in Linux, because I overlook this *2 part form .S files. But yes, At the end I was able to compile it under Linux

Excellent, these recent commits stop the Jak games crashing, they now show an "Impossible block clearing failure" instead, which i prefer to be honest lol

Zeydlitz: could you attach a quick diff?

Fixed the NakedAsm.h part myself just fine, but I am not able to fix the asm

files.

thanks

Zeydlitz: forgot to say, don't bother if it currently crashes on Linux.

I am not sure I understand whether it does or not from your post.

It does run (one of the) Jak games in release mode, it seems

Don't worry about it, I'll be committing a fix shortly. I just finished comparing aR3000A.S to iR3000A.cpp and aR5900-32.S to iR5900-32.cpp, and fixing anything I saw that was changed.

I've been able to start up a few games; I'm just going to do a bit of cleanup before committing, though.

Revision 704

Fix for games which start VIF1 off while the DMA is paused (Crash of the Titans

being one of them)

Jak3 now also loadable

You will probably find that was fixed in one of the recent Recompiler dispatcher fix/optimizations

Hi,refraction

glad to see you working for pcsx2 :P

the revision seems fix the unstability issue for fatal frame when framelimit disbaled

Revision 705

Fixed bug in VIF causing Tenchu "weapons" and some backgrounds not to be

displayed which was introduced in r454

Tekken5 crash on R705.

Yup, I confirm the Tekken 5 CTDs before showing the "Loading memory card" in r705, as well as r709. I think r705 might be one of the first versions to have this problem, because r700 didn't crash for sure. Reporting this as an issue as well.

It seems the VIFDMA's modification must be very careful.

can you please check earlier versions. The changes made here should NOT cause CTD's

please recheck on r713

tekken5 works on 713 again

Revision 706

Linux: Fix up the .S files to match recent changes. Make changes to SafeArray to

avoid compiler warnings on every file.

thanks arcum,

sadly I am getting this at any game just after the bios intro:

terminate called after throwing an instance of 'R5900Exception::TLBMiss'

Aborted

Odd. Everything seems to be working properly for me, and I tried messing with a buch of settings to see if it was a setting somewhere.

Though it might be worth deleting pcsx2.cfg, just in case something crept in...

I tried that but I get the same behavior.

The games I could test are "Saint Seiya" (both sanctuary & hades (EU PAL))

and "Hokuto No Ken" (Jap/NTSC).

Hokuto no Ken has sound but no video(black screen), I think it's a zerogs

problem.

The Saint Seiya games crash with this:

<snip>

# Initialize FPU ...

# Initialize Scratch Pad ...

# Restart Without Memory Clear Done.

EE: Unrecognized op dc

EE: Unrecognized FPU/COP1 op 45100000

branch 10250043 in delay slot!

terminate called after throwing an instance of 'R5900Exception::TLBMiss'

They were working fine some revisions ago.

I have Multithreaded GS on.

If anyone can test those games on windows, it would be great.

Revision 707

wheeeeeee

time for some fun edits :D

laurence...

wheeeeeeeeeeee!

Revision 708

implemented alot of microVU shit...

Hey! There might be kids reading this changelog someday!

Kids generally excrete, too, contrary to populate belief. I'd be more concerned about the effect of a non-capitalized "I" on their fragile psyches.

I like this changelog :p

That's not all to worry about; this commit also contains nudity. Look carefully in the diffs in one of the files, and you can see the exposed end of a naked function.

This is clearly not a kidsafe commit. :)

lol

this commit is Rated 'R'.

May contain adult themes, adult activity, hard language, intense or persistent violence, sexually-oriented nudity, drug abuse or other elements not suitable for children.

zman...

I've been watching the svn for a while but never created an account until now. I'm 14, which is probably the closest to a kid you will get.

Has cottonvibes scarred you for life? If so, do you have any objections to being scarred for life?

Don't forget the question if you're scarred was it more the "I" part or the part about excretes XD

Revision 709

LilyPad: Safely exit fullscreen on escape hack now sends the escape back to

PCSX2 as well after un-maximizing the GS window.

Minor changes to the general config screen's hack section.

Revision 710

implemented more microVU 'crap' :D

ICC build was broken again

HashTools.cpp

1>..\..\HashMap.h(622): error: argument list for class template "HashTools::Dictionary" is missing

1> UnicodeDictionary( const Dictionary& src ) {}

cotton: let me guess, Rated X this time!

spam.Sai...

@junrgao just apply the patch from https://code.google.com/p/pcsx2/issues/detail?id=69 this will fix the icc build. the error originates from rev696.

yep, i already submitted a patch, but is waiting for someone to apply it. :D

Revision 711

A fix for some VU clamp functions, by Nneeve.

Revision 712

Fixed a bug in the new patch code introduced in r669, and applied a patch for

ICC from Issue 69 . Thanks, feal87 :)

Revision 713

Fixed a silly error (on my part) which stopped the Gran Turismo games loading,

looks like it was the same reason Tekken 5 broke too.

This should fix ATV Offroad as well and any other games which experienced crashes/infinate loops on r705

hope this revision will not break other games :P

It shouldnt do, was a massive mistake in 705 which i overlooked, so any games broken in the process should be resolved ;p

Yes, Offroad is fixed. Thanks.

Tekken 5 works nicely now, thanks! :)

zman...

Yay! Gran Turismo!

Revision 714

SPU2-X: Fixed some problems with saving/loading states, when loading from old

savestate versions.

Pcsx2: Small speedup for the IOP's recClearMem (used a forceinline to cure

MSVC's laxidazical inlining)

Revision 715

added some missing CRC's for the ffx hack when MTGS is enabled

What games does the FFX hack break when it's on, anyway?

Why not make it a gamefix instead so that people would want to get rid of it?

I believe this is exclusive to FFX, that's why.

Well from what I read in the documentation, the FFX hack seems correct. I once asked around what the FFX hack breaks but nobody knew. I didn't ask refraction, though. So I guess I am now.

Pretty much, this section of code predates the gamefix dialog. This fix is turned on for FFX, FFX-2, and Harvest Moon.

There's also a gamefix specific to Erementar Gerad, and the path3hack for Sprint Cars and Flintstones Bedrock Racing hardcoded in there. Crazy Taxi and Spacefisherman used to be in there, too, but the hacks they turned on have been removed by now.

This function is one of my pet peeves, actually. And you are right, they probably ought to be in the game fix menu. Bet we'd get a lot of complaints if we moved it, though...

NLOOP hack breaks the bios :p

im guessing there is potential to break other things until its worked out why that breaks the bios

That's odd.. It doesn't seem to break the bios at all over here... I tried both executing the bios through the null plugin and run->execute and I see no difference.

This is with g_FFXHack replaced with 1, MTGS mode and GSDX's nloop hack on.

try without MTGS mode and the black tick in GSDX

I tried and the BIOS works fine with the nloop hack enabled, both through MTGS or without MTGS.

I think this problem was fixed a while back. Cotton and I fixed some bugs related to the processing of the XGKICK and GIFtags, and I had a hunch back then that it probably solved NLOOP issues. Unless someone can find any breakages, I'm thinking we might be able to retire this one.

If we retire it, I'd suggest we add two patch files to replace the 2 crcs with the path3hack, and that we just drop the VUFIX_XGKICKDELAY2 hack entirely. Then we could get rid of the function.

The path3hack is already in the patch system, iirc, and the kick delay hack only effects erementar gerad, a game that has scrambled graphics on several scenes, and only runs on ZeroGS.

I'd assume that since it's in the VU code, that function is slated to be rewritten at some point, anyways...

Revision 716

Don't try this.It will bite you.And it'll be your fault.

--removed most of the code from iR5900-32.cpp

--Added blockmanager.cpp/h that i worked on before

keep in mind, this is a wip attempt to update/rewrite the rec (eerec), and it

won't even compile.This is the last warning i'm going to do for non devers,

you'll have to check the URL of the changes on your own to decide if any commits

are for this branch or not.If you can't live with that then stop reading the svn

changelog.

Ok, it wont work. I think people get it :p

Keep going :)

get what? *compiles*

Oh-oh. So you rewrite assembler part in r5900? I better wait, until you finish, because for Linux this stuff should be merged.

I don't code for linux, someone else will have to port it over.If it ever works that is.

Which would probably be me or Jake.

shogun.n...

I know you will do a great job here raz :)

new block manager?

maybe it will fix lots of games when it is complete :P

i tried it and it bit me :(

Revision 717

A frog in a well won't know the ocean.

this changelog is philosophical

heh, it was in some anime i watched:

"Translators Note: this saying expresses the idea that one can never fully comprehend anything beyond his experience."

its a pretty cool saying :D

anyways, since all my updates for the next few weeks are going to be for the new (non working) VU recs i'm working on, it'll get boring if i keep saying "microVU rec stuff" in the log messages :p

Can certainly understand that. I get pretty bored with typing "Fixed Linux" over and over again myself...

"You're cuter when you're fat." - Uzumaki Naruto to his wallet frog

http://www.afroginawell.com/ lol

Pork Chop Sandwiches is more interesting :P

The caged whale knows nothing of the mighty deeps. If it makes you any happier. :)

(Terry Pratchett)

I hope this thing will become... overwhelming.

Did you say mighty or nightly? :)

Revision 718

Linux: Straighten up or remove a few Windows/Linux differences in the code

(experamental), remove some dead code, fix a mistake in the Linux version of

memcpy_amd_ (still broken, though), and change optimization levels due to gcc

optimization induced errors.

The -msse2 flag, incidentally, was so I could include xmmintrin.h & emmintrin.h, allowing me to comment out that assembly in iVif.cpp, and just use the same code Windows does.

And I'm not sure why __builtin_bswap32 wasn't used in the first place in Mpeg.h...

Ragha...

Or you could use this:

mov ebx, eax

shr eax,16

shl ebx,16

or eax, ebx

mov ebx, eax

and eax, 0xFF00FF

shl eax, 8

shr ebx, 8

and ebx, 0xFF00FF

or eax, ebx

Or you can use pshuflb xmm0, xmm1

>> And I'm not sure why __builtin_bswap32 wasn't used in the first place in Mpeg.h...

I think because mpeg.h was written in 1997 or something ;)

Revision 719

Many small bugfixes and optimizations:

* Fixed Memcard init so that Memcard1 isn't default in both slots (oops!)

* Fixed Memcard path logic so that cards outside your pcsx2 folder can be

browsed/selected.

* Fixed CDVD-to-BIOS time sync (I simply forgot a function call!)

* Optimized yuvrgb_sse2, by using Mod/RM form instructions.

* Win32: Same optimization applied to FreezeXMMRegs and FreezeMMXRegs (linux

already had this optimization)

Hmmm... in ix86_tools.cpp, should I apply the same asm changes as on Windows? I already have to fix the extra ); anyways...

Nope, GCC already has the optimiztion:

>> "r"(g_globalXMMData)

That assigns the offset of g_globalXMMData to a register of GCC's choosing. Thus, all the %0's are mapped to a register when GCC does its optimization pass.

.. at least I'm pretty sure that's how the inline asm syntax works. I'm probably wrong or something. :S

Think you're right; I believe the "r" does stand for register. I'm just used to tuning out that section of code... :)

Hmmm... The changes to yuv2rgb.cpp are giving me issues. Unlike the .S files, it isn't feeling like processing the defines (though I'm sure it would if I used the same gimmick ix86_tools does).

I'm sure I can fix it, but I have to leave for work. So the Linux port'll be broken till I get home, possibly longer... :(

The #defines might work better as an enum{} -- I dunno. Worth a shot. I'll commit it in a bit and I'm sure Zey well let me know if it's broke or not ;)

You should install Linux, where're you from, so I can send you my Ubuntu DVD as a gift ;).

Revision 720

Linux: inline asm fixes.

I am very sorry, but you could not use static variables in GCC asm :-(,

Or enums, it looks like. Unfortunately, Since it's a workday, I don't recally have much time to fix this right now.

I was able to get it to compile by removing the static and const keywords, and then turning the enums to u32s. This resulted in most of the FMV's I tested sending pcsx2 into infinite "Protected Memory" loops, which is already something it seemed to be doing a certain other times, like starting up FF XII.

Protected memory cleanup. Offset 0xe169440

...

Essentially...

Actually, not FFXII, but I know I've been seeing it recently. I'd better get to bed, though...

Revision 721

GSdx: Implemented edge anti-aliasing (aa1) for software mode, bios or ffx are

good test subjects (not many other games use it). It's still a bit slow but

could be improved a lot by not doing 4 pixels with sse for each single edge

pixel, that's just a lot of unnecessary texture lookups. The bios config screen

cubes are still bogus, gs_user on aa1 isn't too helpful...

I am getting a few fps speed increase in software mode with the AA1 selected though.

Does the hardware renderer support AA? if I disabled the AA function in the driver setting.

and the software renderer will be the future main method?

Change the d3d internal res in the hardware renderer for effects similar to AA

Change internal res similar to Supersampling AA...Am I right ?.

afaik, supersampling a bit slower than multisampling ( I read it in nForce website ), so is there any performance increase in gsdx if we use multisampling

This helps the BIOS edges on cubes nicely. FFX seems to use it only on geometry.

Hope this is a simple flag, and every game can be forced to use it :p

A question:

Only FFX and Bios screen gets advantage from this feature ?

@junrgao:

yes it does, but only by your videocard driver, not by GSdx.

gdt1978

I can't compile this rev

Yea, compiling everything below SSE4 is broken atm.

AA1 is not like the AA of directx, more like an extra anti-aliased line drawn at the edges. It enlarges objects so can't really be applied on everything, just selectively with care by the original programmer of the game.

It is less important for the hardware renderer, but at native resolution it will be possible to implement it with dx11, that passes the coverage value to the pixel shader.

wtf, no text wrapping, google roxx.

Revision 722

LilyPad: GSDX10 + fullscreen + escape workaround that's lamer than the last

one, but seems to work much better and should cause no issues with GSDX+DX9,

other than a slight delay.

Revision 723

microVU's upper instruction implementations (second pass) finished (except for

clip instruction)

No more "crap" or "shi" microVU things :P

Does that mean it's already implemented and working on Pcsx2?

chuuey

it means we all have to test it ;)

I don't think so.

MicroVU is not yet used by PCSX2 because it isn't complete.

I think that MicroVU can be used ... after 1 or 2 months

only half part of it, the lower part is wip...

Revision 724

started on the lower instructions

Revision 725

more lower instructions implemented

Revision 726

something.

at least cotton does something O_o

...from somewhere by someone...

it seems that the lower part was completed

Revision 727

Fixed a bug in memcpy_fast that caused memory corruption on blocks not aligned

to 32-bits in length (this might fix the linux memcpy fast problem too).

And with that, SF:EX3's crash on load is finally fixed. GJ.

good job

You've made a small mistake in comment on line 384 in fast_routines.S -- you put a semicolon (;) instead two slashes (//). But except this, everything fine.

That's why it wasn't working in Linux. Seems to work nicely now, and I just enabled fast_memcpy by default in Linux for testing.

Revision 728

nneeve improves the software-emulated FPU accuracy ("Full" mode in Advanced

Dialog).

Appended notes:

* ADD in iFPUd should be bit accurate (unless it isn't. needs TESTING)

* MUL in iFPUd with Software Emulate MUL is as much as I could get near bit

accurate (not quite enough, probably. needs TESTING)

Correction : This commit adds a "Software Emulate MUL" option in Advanced dialog. This emulates MUL a bit more correctly but is quite slow. It's probably only useful for a hang in Tales of Destiny, but who knows.

It has nothing to do with "Full" mode. ("Software Emulate MUL" works both with and without "Full".)

Revision 729

Minor cleanups to NTFS_CompressFile error handling, and the Linux YUV/RGB

thingie.

Revision 730

GSdx: sse2/ssse3 build fixed

sse.h fixed but still get tons of errors on GSVector.h

lines 1480, 1493, 1540, 1571, 2130, 2443, 2458

Doramon1...

could you please tell me how can I download or try this project

[email protected]:

Which config and what errors? I have tested all and they compile for me.

Gabest: Any chance of looking into the cause of the race start crash in Gran Turismo 4? Been happening ever since many many gsdx revision updates a year ago roughly.

Note that the crash only occurs in the gsdx9 version.

@autoran1

They are warnings not errors, signed/unsighned mismatches are fine

gabest11:

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1488) : error C3861: _mm_castps_si128: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1493) : error C3861: _mm_castps_si128: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1493) : error C3861: _mm_castsi128_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1540) : error C3861: _mm_castsi128_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: идентификатор не найден

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castps_si128: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2130) : error C3861: _mm_castsi128_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2443) : error C3861: _mm_castpd_ps: identifier doesn't found

1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2458) : error C3861: _mm_castps_pd: identifier doesn't found

Ali this combination of errors repeats for me several times

Check your C:\Program Files\Microsoft Visual Studio\VC\include\emmintrin.h file. It looks like wrong\old version of this file. I have no any errors...

BTW, what MSVS version you are using?

Revision 731

wxgui -> New Branch! This is to be an eventual replacement gui of the future for

Pcsx2, based on wxGui. Initial content coming soon.

By wxGui I meant wxWidgets. >_<

lol, i was thinking about why you were using a Tcl/Tk library. :D

I feel the whole pcsx2 will be rewritten :P

Which would be a good thing. I`d love to see the gui take a change to be more of a transparent display (ala zsnes`s gui) as that would be alot more game friendly, rather than having to start games from scratch or having to run a command to continue.

Dunno if we'll get that far. There are problems inherent to the GS Plugin model that make it potentially difficult for us to embed the display window into Pcsx2's gui. Ultimately it could be doable, but it'd just be a lot of work and would require plugin API changes and planning and such.

But what the wxWidgets gui will do for us here is simplify the whole win32/linux cross-platform mess. And it should also allow us to thread the GUI (Something I would have done already except it'd break linux or get ugly with lots of platform dependent code and stuff).

One of the benefits of doing it this way, too, is that wxWidgets uses gtk+ as a backend on Linux, and standard windows widgets on Windows. So the plugin configuration boxes will still be consistant without being rewritten, though I'm sure they'll be rewritten eventually.

And it ultimately means I can stop fiddling with the Linux gui so much, because the Linux gui will be the same code as the Windows gui, which *everyone* works on...

coolc...

Why you guys do not consider Qt4 as the GUI front-end?~

Choose Qt4, WxWidget or Gtk+ are depend on developer's choice, it's probally the same.

afaik, pcsx2 for linux is now using gtk, gtk is x-platform rite ?, why not use gtk+ for both linux and windows version

Revision 732

Pcsx2-wxGui: Initial commit of "non-functional" gui (WIP). It compiles but

doesn't do anything yet (none of the menus have been bound to actions, except

for the GameHacks dialog). Initial wxWidgets project additions and prepwork are

courtesy of Feat87.

The copy of wxWidgest on the repository is for Win32 only. It's presumed at this time that Linux will use/link to some system-global distro pre-installed/compiled or something. I think that's how some other projects do it, and it keeps the wxWidgets install at around 17 megs instead of 50 megs needed for all the unix distro stuff.

Yeah, that's what I was planning on. That's what we do with most of the other Linux libraries, and Linux is good at handling that sort of issue.

Any version requirements as far as wxWidgets is concerned, though?

the actual version included is the 2.8.9.

Revision 733

Folder Structure change: Renamed the 'Win32' folder to 'Windows' for several

plugins. It's technically more correct and alleviates some confusion with the

Win32 target/build folders generated by MSVC.

Now how about consistancy on having the plugin source in src, Src, or directly in its directory? That one's bugged me...

Revision 734

Pcsx2-newgui: I missed *just one* file in my last commit to the newgui branch.

This'll fix it so it compiles. >_<

Revision 735

Fix the yuv2rgb.cpp issues, per Zeydlitz's patch in issue 100 . fast_memcpy works

in Linux now as of r727, so I'll leave it enabled for a while, and if it seems

stable, I'll remove the switch for it, and have it permanently enabled.

I'm still not sure why GCC needs the volatile switch. :|

And I am *so* going to have to do that naming trick in some of the other areas of the code that have %0's and %1's all over the place...

Beats me, but if it's what gcc wants to run, I'll go with it...

BTW, stumbled upon this perl script:

http://technicrafts.com/AssyXlate.htm

Volatile is useful if you want use complicated structures in assembly. It's not 100% needed (you could remove it, and it does not crush), but someday compiler could guess about optimization of you data and rearrange it's fields. I think for MSVC it's good too -- not to try optimize such data.

p.S. I think if you wrote assembly, you know better how to arrange data, than compiler?

Revision 736

R3000air; New branch housing my rewrite of the IOP's interpreters and

recompilers (also very much a WIP). Initial commit of branched materials will

be up in a few mins.

It's a big project......

I'm almost feeling left out that I don't have my own WIP branch in with nothing works yet. Guess I'll just have to share the wxgui one.. :)

Please do! Working on GUI stuff is *exhausting*, and the workload is pretty big, since we have many dialogs in need of restructuring. >_<

I probably will, though not likely till Thurs...

Initially, of course, I'll probably just be getting Linux to compile it. And I consider having "Run CD", "Execute", "Reset", and "Exit" to be the highest preiority commands to link up... :)

Are you trying to grow a PCSX2-tree with hundreds of branches?... :)

Revision 737

R3000air: A new IOP, from the ground up! Currently it is Interpreted only, and

buggy (doesn't boot, but does run some thousands of instructions before

erroring). I did a partial branch, which means checking this out and running it

is tricky -- you need /trunk/common and /trunk/3rdparty, and you need to make a

new solution file. This is also part of my experiment to see how life fairs

when using a partial branch as such.

I of course provide no technical support for people daring to use my broken code. But I figured I'd give an explanation of how it's set up anyway, in case people out there enjoy torturing themselves on this sort of thing.

i have a small question: doesn't the IOP use pretty much the same processor as the one in the PS1? can't the team use code from pcsxe or something? plz correct me if i'm wrong :)

And have fun rewriting the recompilers :P

We are right now. I believe that's what Jake's rewriting... :)

It's not about speed. It's about not sucking in terms of compatibility, stability, and debugging. And ya, the IOP was originally pased on pcsx (the original), but it's not exactly high on the compat scale or the "not a total hackfest" scale either. ;)

well the way i see it, the IOP recompilers can be slow as hell and not prevent pcsx2 from reaching high speeds :P i mean the iop uses a 25MHz CPU iirc, and as long as it's running on a different thread, it won't hinder performance, because even if the code is very slow, any modern-day cpu will be able to emulate it afaik. So yeah it's not about speed :P

thx for clearing up the compat thing. i used to think pcsx had a very high compat rate (yet i never played ps1 games on the pc).

Anyways, have fun ;)

>> and as long as it's running on a different thread, it won't hinder performance.

True. Unfortunately current IOP code in Pcsx2 isn't thread safe. That's one of the things I aim to resolve. :)

PCSX2 is in a great period now !!!!

maybe one day it will boot also psx1 games :)

whats about the recompilers in epsxe or pSX?

couldn't the devs share it for pcsx2?

they work more than perfect, especially in pSX.

i mean r3000 as the iop for PS2 Emulation, not for PS1

This is why the code is being rewritten, the iop interpreter/rec originally WAS the one from PCSX (the Ps1 emulator by the original team) but the ps2 IOP isnt quite the same, although it is close, it didnt work as well as it could have. So the best thing we can do from ps1 emulation is use it as a baseline reference, as the lack of documentation on the IOP is extreme.

Indeed, documentation lackage on the IOP is annoying.

Anyways, I'm fixing bugs and making it easier to fix more bugs and reverse engineer unknowns. And if pSX wanted to have their code open sourced, they'd have open sourced it. Sheesh people.

That's why I love you guys. Keeping such a project as Ps2 emulation as open source.

Those guys who work on emulators in "closed projects" should shut themselves in hell and rot, kyahaha. Best of luck in the new IOP :D

Hey Jake here is a very juicy document about R3000 instructions os PS1. Hope it can help: http://psx.rules.org/system.txt

yan.eml...

I think you already know this, but in case if not: http://members.at.infoseek.co.jp/DrHell/ps1/

Revision 738

Improved PCR/TIMR support -- fixed a case where games would try and read from

the PCR multiple times in the same recompiled block, reuslting in bogus values,

and fixed some sign extension errors on the interpreted version of MFC0.

For the PCR0/1 updates I just call the new C functions from the recs, since the C funcs don't need any flushing, and the PCRs rally aren't checked that often afaik. If it actually seems like a performance issue on some games, we can update the inlined versions later.

I doubt it'll be a performance issue tho, and only having to update the C versions makes life a lot easier. :)

This fixes Orphen.

Revision 739

Fixed a problem in the new VU clip flag code that a history of the flag is

cleared wrongly in a certain situation. Unfortunately the problem in GoW is

still there :(

MMI: Optimizations for some opcodes.

huh?

wasn't the GOW problem just the bug in the PLZCW rec?

i'm confused...

This here is a different bug that popped up after a fix for the VU clip flag beeing "forgotten" sometimes.

This commit breaks BIOS loading!

The GOW problem is not the clip flag being forgotten, but it issues double CLIP's (one straight after the other) and it has to use the most recent result to get the next calculation correct, which is why i put that bit of code in to update the flag, but due to other recent changes this no longer functions (unless you tick the option)

Revision 740

Added some preliminary exception handler code to the PCR's. No point in

finishing it right now since the rest of the EE's exception handler is still in

flux, but at least it's ready for a quick upgrade now. :)

pcsx2gu...

Causes the GS window to freeze on init with speed hacks on. Not fixed in later revisions until 744 at the time of writing this

Revision 741

Fixed my stupid mistakes in the previous commit.

Revision 742

cleaned up some code (knocked off 100+ lines in Alloc.inl), and implemented

'ESUM' opcode.

<drk||Razi>cotton2: write more helpful logs kthx ;p

<cotton2>doesn't matter, no-one cares what i write since it doesn't effect

anything for now

<Krakatos>cotton, stop posting those useless commit comments XD

<feal87>no no, please continue. they're fun, i look forward to read them

<feal87>from time to time

<feal87>:°D

<cotton2>lol :D

<Dwarg>Please spend more time making them more amusing.

<drk||Razi>cotton2: it does matter

<cotton2>dwarg: yeah i know!

<Dwarg>drk||Raz: Why? They're useless for reversion testing

<cotton2>i have to think of good stuff to write :O

<drk||Razi>when the next vu coders (if any, ever ;p) want to look at your code

.. and the history is full of crap

<drk||Razi>that won't be much useful

<drk||Razi>;p

<cotton2>there won't be a next vu coder!

<Dwarg>Comments in the actual code would be more useful, wouldn't they?

<cotton2>my code is perfect!

<drk||Razi>lol

<cotton2>>.> <.<

<cotton2>but seriously

<cotton2>i don't think it can get better

<cotton2>unless like

<Dwarg>Rather than going back and comparing SVN comments to changes made way

back when

<cotton2>you want to support AVX

<cotton2>or w/e intel's new SSE thing is called

<feal87>and anyway AVX is like 3 years away

<feal87>in that timeline pcsx2 i think will be stabilized

<feal87>:°D

<cotton2>yeah

<drk||Razi>cotton2: just log kthx

<drk||Razi>implemented y,x,z

<drk||Razi>:>

<cotton2>thats what the diffs are for!

<feal87>and anyway really its useless for this stage

<drk||Razi>yea i know

<feal87>until microVU is active and used by PCSX2

<cotton2>i'm just implementing different opcodes though, its not like i'm

chaning features

<drk||Razi>you can tell anything from the code -- no comments or changelog

needed.Right ? ;p

<feal87>then every change should be documented for regression testing

<cotton2>drk: yup!

<cotton2>well

<cotton2>its not like i'm changing stuff

<cotton2>i'm just implementing things that havn't been coded

<cotton2>so theres nothing to regress to

<feal87>yep

+1 :D

+1 because it doesn't feature me saying any of my usual stupid IRC crap!

Now, thats helpful :p

+1 for lowest entropy (relative to the amount of words XD)in a pcsx2 commit ever XD

This thing will make my day... Really... :D

Lol, nice commit log :)

especially changelog :P

should +2

I Lold, helpful indeed :P

I totally agree that more useful comments would be alot more welcome, as joking comments only is useless, and leads to the inability of knowing what happened on a commit unless you go and check the code, which is all just wasted time.

Alot of us do read what you write in the commit logs so it is of use to us the users of the emulator to know exactly what changes were made in the background. If all the appears in a commit is something like "humpty fell off the wall again" then thats completely useless to everyone.

Also: "<cotton2>there won't be a next vu coder!"

Famous last words :p. Please write more useful comments.

It's his own rewrite project so nobody else has really to check whether the code is right or not or even when the code was implemented so i think

so long as he knows where he implemented what the commit log should not matter...

Revision 743

FPS2BIOS.

Small changes to makefile to enable code to compile out of the box. Fix to

romdir.c to avoid uninitialised data being written to output.

Revision 744

nneeve fixed min/max FPU opcodes to be more precise when running in "Full" clamp

mode.

he also cleaned up some other stuff in iFPUd.cpp

somewhat with the last commits, the emulator doesn't start emulating, tried even with GSdx and ZeroGS and the same thing happens.

Here a screen showing that.

http://img26.imageshack.us/img26/2648/ps2hang.jpg

make a thread in our forums for help the emu is working fine for me.

I think it started happening with r742 or r738 and up..because before it was working fine

that was EE sync hack's problem..

I figured out! The EE sync hacks seems to got broken,only with default cycles is working

lol we posted in the same moment ;P

Yeah I can confirm this. Pcsx2 break in BIOS loding from rev 739

Revision 745

Fixed the bug in r740 that broke speedhacks; and improved the PERF support a bit

more using bitfields and more correct mode tests.

Thanks! Ahh much better with speed hacks =P

Revision 746

More work on the PERF counters. Counters now selectively count or don't count

depending on mode (which should keep some games happier which might try and use

them, if still not being totally accurate or correct).

1 line-by-line comment

/trunk/pcsx2/COP0.cpp

r746

line 191:

191: Console::Notice( "COP0 - PCR0 Unsupported Update Event Mode = 0x%x\n\t(Nneeve says this should probably never happen!)", params cpuRegs.PERF.n.pccr.b.Event0 );

I don't think I ever said that, but whatever :P

Revision 747

Added option to control PCSX2 volume only with volume keys, instead of global

windows volume. Release shift, control, and alt on deactivate. Fix for

changing skip mode on alt-F4 (Accidentally removed the old fix for it in 0.9.5)

Forgot to mention changes affect LilyPad only. Also, volume control is Vista only.

nice feature!

i hope spu2-x will get a volume booster too.

The sound is sometimes too quiet.

For most apps, default volume level is 100% and can't be increased. As a result, I keep my system volume a little on the high side so I can turn down app volume to suit me. Problem is most everything has to be turned down a little, but at least I can adjust everything to a level I like.

Revision 748

Minor PERF fixups -- moved the diagnostic msg to a less spamming-like area (on

PCCR assignment, rather than on PCR update).

Revision 749

optimized some stuff, and implemented all EFU opcodes.

note: most of the microVU EFU opcodes are implemented with completely different

algorithms than zerorecs. this might prove to be more accurate, but i mainly did

it to avoid using x87 FPU instructions (since i'm using mmx regs for storage).

Revision 750

implemented ERCPR (seems i forgot about it on my last update).

Revision 751

some tweaks based on some optimization tips jake found.

the idea is that with SSE, doing operations that don't modify all the vectors

can give false-dependencies, and in some situations prevent CPU's out-of-order

execution (slows things down).

so the solution is to only use stuff like "movss" when you need to preserve the

upper 3 vectors, if not, its always better(faster) to use movaps.

asm optimizations are always good

(on a side note ... funny how the many positive comments abruptly ended around the first normal change log^^)

Revision 752

Fixed a bug that caused pcsx2 to crash when loading/saving savestates using the

"other..." menu option.

Added new command line options for running pcsx2 without a gui. Using "pcsx2

[filename]" where filename is the name of a cd image, will run the game. use

"pcsx2 -nogui" to boot whatever you have configured in your CDVD. Use

-bootmode=1 to enable the quick boot method (same as RunCD) .. default boots

through the BIOS. [untested feature! please report if it's broken]

Thanks!

MadRabbi...

TNX! But, ESC Hack not working, fix it, please.

Revision 753

R3000air branch updates -- added Instruction disassembler and diagnostic info.

(Merged all relevant trunk revisions.)

Revision 754

microVU recs: fixed a bug in LQ, and implemented LQI and LQD.

question: Any particular reason you nuked the const modifiers on the various SIMD tables?

Revision 755

R3000air branch: Interpreter working nicely now booting games. IT's (inredibly

slow* but it's booting. :)

Revision 756

Linux: Bring in sync with recent changes. (as usual)

Too bad that usegui/nogui thing is only half done. :/

Also for some reason I thought testrun stuff wasn't on Linux. I guess you ended up adding it recently-ish?

No, think it's been there for a while. Could be mistaken, but I'm sure I remember going over it in passing, and wondering if it even worked a number of times...

I think it might have a long long time ago (0.9.4) -- but even then it's usefulness was limited. The most interesting options -- the PAD keyrepeater for example -- aren't implemented. And without that there's not much point to automated running of games via batch.

Quite true. It probably was about time to rip it out.

I'd thought about revising the command line args for a while. I'd just never gotten around to it...

Revision 757

Linux: Fix Final Fantasy XII. (memcmp_mmx appeared to be freezing MMX and not

thawing it, and it didn't freeze it in Windows.) Comment out some unused code.

Remove some code I commented earlier. And consolidate some of the calls to

FreezeXMMRegs/FreezeMMXRegs.

Looks like I deleted a semicolon in IopDma.cpp without noticing it. I'll take care of that next commit...

Revision 758

Should warn when can't write to config files. Getting sick of repeated posts by

the unwashed masses about this (Though also find it bizarre that Vista chooses

to not allow an app to write to its own subdirectories). Also, included VC 2005

project now builds successfully as long as you have an svnrev.h.

Again, LilyPad only. Really need to remember to add that to my logs. Should be able to edit it, dangit.

You can edit it! But ... it wipes all the comments on googlecode, so it kinda sucks either way.

Damned if you do, damned if you don't. -_-

veaac.fd...

I really like Vista's approach. They tried to clearly separate configuration from program data - like Linux and Unix based system. That forces all programs to have user specific configurations. All system wide settings should need administrative rights.

All data in one place just seems insecure to me... I mean, does GTA III really need access to, say, your tax returns? Storing everything in one place also completely negates the need for an uninstaller, other than to clean up shortcuts, which I think is a good thing, as a lot of installers leave random junk sitting around.

Also, there are legitimate reasons to have two versions of an app installed, or two copies of the same app, and want different settings for each. Former not working could be blamed on the software developer, but latter I'd blame on Microsoft.

It might not actually be a bad idea to move the ini files out of the pcsx2 directory.

For the wxwindows port, wxStandardPaths::GetUserDataDir returns

'C:\Documents and Settings\username\Application Data\appname'

on Windows, which Vista would like, and

'Unix: ~/.appname'

which some of the Linux people would like. And it's already possible to override that location on the command line, iirc...

The difficult part would be telling the plugins where to get the ini files from. Which is one reason why I've been wanting to have pcsx2 pass the plugins the ini file directory path...

I'd be happy with passing the plugins the ini directory.

'C:\Documents and Settings\username\Application Data\appname'

i hate applications that store their ini files in a completely different directory than the executable file.

cuz then i have to track it down, and its just annoying.

every app should have their ini file in the same directory as the executable file (or in a child folder) IMO...

it makes things alot easier if you ever have to modify or delete it.

and yeah, pcsx2 should pass the ini directory to plugins.

Probably the best way to go is to let the user choose inside the program.

My only difficulty with that is where to store the location of the ini files...

Revision 759

Linux: memcpy_fast seems stable enough on Linux, so I'm removing the switch, and

turning it on by default.

Revision 760

implemented some more opcodes...

Revision 761

Minor fixes to the IOP Interpeter and const prop regarding the SLTIU

instruction.

Removed the rest of the references to the UseGui global boolean since it wasn't

used anymore.

Revision 762

Some header work, get rid of some dead code, and rename PsxCommon.h.

fatal frame is broken when take photo, 720 is ok.

Revision 763

R3000air branch: Interpreter is pretty much finished now (tho not extensively

tested at this point). Performance is roughly 15-25% better than the old IOP

interpreter. Additional feaures include:

* Support for branch instructions in the branch delay slot (known cases exist

on the PS1, may not be an issue on PS2 tho)

* Correct support for delay slot exception handling.

* #define free, and lots easier to trace usingt he debugger.

(merged trunk revisions into branch)

I'll mention now (and probably later too) that this new IOP will not be backwards compatible with old savestates. I took this opportunity to redo the iopRegs structure to have relevant info, and to remove some of the non-relevant stuff.

good job :P

Is it already implemented in the place of the old IOP ??

This is great can't wait it to be applyed in emu :P

Revision 764

pcsx2-wxgui: maintenence merging of trunk revisions into the brance (always a

good idea to update branches after header file renames)

Revision 765

cleanup: moved 'software emulate mul' to gamefixes section since it seems to

only be needed by 1 game.

Revision 766

Preliminary work on a new version of the plugin api. Not hooked up, and very

subject to change. Mainly committed both for backup, and for other devs to mess

with...

Oo multi tap support O_o pretty please with sugar on top

alright after this unnecessary action can I please go to bed now?^^

(just my way of saying cool could be nice)

Thanks.

It has potential, but right now, it's mainly the old API, broken out into more files, using EXPORT_C_ instead of CALLBACK.

I did make all the init functions pass the ini directory to the plugins, merge a few spu2 functions together, and change a few variable types. Other then that, though, I wanted a base in svn that we can build on.

I'd encourage any of the devs to play with these files, especially the ones maintaining plugins...

If PCSX2's still going to use PAD plugins instead of only SIO, you should rename PADinit, so pad plugins can maintain PSX emulator compatibility.

Also, might not be the best spot to ask...But how exactly are SIO plugins supposed to work? Looking at SIO.h, looks like you get a u8 value indicating device type, to which you respond with a value indicating device exists or it doesn't, and port and slot are indicated by a register value. How is this supposed to be handled by an SIO plugin? Plugin has a different function for each port/device type it supports with its own SIOchangeSlotCB function? So if supporting multi-taps and pads on ports 1 and 2, you'd need to 4 different functions? Or do I have something wrong?

One other thing: PADfreeze and SIOfreeze might be useful. Pad mode and force feedback setting need to be recovered when loading a state, otherwise some games will give you a "please plug in a pad" screen for a few seconds, which can be annoying.

@matt: go ahead and modify/comment the code itself as you see fit with regard you PADs and sio. I think you know the subject better than most the rest of us.

That was pretty much the intention. I made the main changes that I could think of and then committed it so that everyone else could make changes. And I figured that the people actually working on plugins would be the best people to make changes to those particular apis.

And I'm in about the same boat as you are with sio. Wouldn't be suprised if the person who introduced it isn't currently on the team...

As far as compatability, I suppose we could rig something up. I just pretty much figured we'd lost compatability when I yanked all those useless void *pDsp's from the open statements.

I could potentally create a new call just for passing the ini location, though.

Actually, those void pDsp's weren't useless - they were used to pass the gs's Window handle to the pad plugin, which basically all Windows input APIs need. A pad can just look for the topmost window for the current process, and pray to God (To Microsoft?) it's the GS, but that's not too robust unless you trust Windows to always put a window on top when it should, which I don't. With MTGS, you can figure out which thread the Windows belong to, and compare that against which thread the pad is being initialized in, but that doesn't work in single threaded mode.

Other plugins can also use a Window to receive Windows events (Audio device state change, audio file finished playing, etc), though in practice, they haven't been doing this. Best just to keep them around, I'd think.

If it is actually being used, I suppose we should..

I'd looked at a bunch of plugins, and hadn't seen them used, but my focus had been on Linux plugins, naturally, and I hadn't really seen it being used.

I'll put it back, rename the variable to something more appropriate, and document it's use in the code, then. Besides PADFreeze, any other functions that you'd find useful, or information you'd find useful to be passed to the plugins?

Nothing I can think of, though might want some standardized way of passing volume control keyboard input from the pad plugin to the SPU plugins. No idea how Linux handles it, but on Windows, unless a process captures volume control input, modifying the volume control affects system wide volume. This doesn't work all that well if you just want to affect PCSX2's volume and have music or something playing in the background.

Not sure if Jake is interested in implementing this on the SPU side of things. Volume messages can already be passed to PCSX2 through the KeyEvent stuff, so only the SPU api would need to be modified.

Right now I use Vista's single process volume control stuff to do all this from the pad plugin, but it might be nice to do something more general that doesn't depend on using a single pad plugin and is cross-platform compatible, at least in theory.

Also, thought pDsp was already documented:

// s32 CALLBACK GSopen(void *pDsp, char *Title);

Opens the plugin, return 0 on success, else -1.

The plugin must fill the 'pDsp' arg (32bit) that'll be

passed to other plugins (*1), this is OS dependant (*2).

On Win32: pass a HWND value, ie:

*(long*)pDsp = (long)GShwnd;

On Linux: pass a Display value, ie:

*(long*)pDsp = (long)display;

*1 Even if this value is passed to every plugin, this

may not be used by the plugins.

*2 This could change anyways, ie. maybe you can code a

GS/PAD plugin for a speacial library, so the pDsp

will be a value that you need to communicate between

them (if you need to do this).

Hmmm... Perhaps we could pass keyEvent to all the plugins, rather then just GS, as an extended function.

And I was thinking of in-code documentation, and documenting what it's currently being used for, as opposed to the theory of what it can be used for...

matt: hmm, I have some problems with pDsp, casting it normally like

GShwnd = (HWND) *(long*)pDsp);

will suffice for pcsx2, but whenever I try/debug it for PSX Emus, it gives me

expression can't be evaluated! although GShwnd points to the same address as pDsp but it says unused?? I even tried IsWindow IsBadPointer..

anyways for now I get the GShwnd using GetForegroundWindow() as soon as GS window created (it's temporary solution)

I tried a debug build of your plugin LilyPad, with SSSPSX emu, it doesn't work and when pressing ESC the emu crash!! I thought you might give it a look :)

arcum42: about plugin spec, I don't know if there is anyway to let plugins send messages to GS plugin to display them for specific time (like savestate slots changing), does GSprintf() do that! and how can other plugins use this function sorry for the noobish questions, I am not familiar with pcsx2 code :)

Rebellious: Sometimes pDsp is an HWND and not and HWND*. Depends on the GS plugin. I copied SSSXPad's solution to this. (Use IsWindow on pDsp, and if it's not, it's an HWND*). IsBadPointer should prevent a crash, but honestly, haven't played around with it much. LilyPad works with epsxe and PCSX2, haven't tested it with PSXeven lately (Or whatever it's called), but it used to work with that, too. I used to use GetForegroundWindow() as a backup, but no longer do so.

If you were running fullscreen and using the fullscreen escape hack, then the hack's the reason, particularly if you weren't using the SVN version.

It's actually PCSX2 itself that uses GSprintf(), not the pad plugin. That's how ZeroGS displays plugin state changes, and how things should be handled. My display saveslot number in window title thing is just a complete hack, and not really how things should be done.

Also, you might want to look at either SSXPad's or my PADinit() functions. SSXPad's has less extra junk in it, so it probably a better choice.

Err...PADopen, rather.

SSSPSX's crashes are due to what I'd call an SSSPSX bug. I suspect it's not opening the plugins and subclassing the GS window in the same order it closes them and unsubclasses the GS window. As a result, any pad plugin that subclasses the GS window (Only mine?) causes a crash. Without source code, hard to be sure. Works perfectly with epsxe and PSXEven, though, both with and without the fullscreen escape hack enabled.

Revision 767

Forgot two files.

Revision 768

forgot to commit this...

Revision 769

wx: Get the wx port to compile in Linux. (Note: will not actually run games at

this stage.)

wxWidgets has it's own text formatter you should use instead, called wxT().

I didn't think it would be an issue in Linux (it's needed in Windows when I enable Unicode, which I haven't bothered to do yet). But yea, better off using wxT( "Text!" ) instead of _T :)

Also! I plan to implement my new translator, which will take regular non-T strings always (as keys), which is the other reason I didn't add _T to everything. Hrm. I really didn't think Linux would need those _Ts since it compiles using UTF8 anyway. Oh well. :(

I'm learning WxWidgets now..thanks for the pro code :P

@Jake:

Yeah, it immediately started complaining about using const char*'s, where wxStrings should be. And I'd gotten the impression that _T and wxT were interchangable when reading the wx docs. I can change them, though.

Using wxBORDER_THEME instead of wxSIMPLE_BORDER was rather important, too. At least, if you think having a title bar and close box is important. :)

@ntcong.it: Keep in mind we're learning wx as we write this, so this may not be the best code in the world initially...

Revision 770

Further work on the block manager.

Grandia 2 is still broken but this is a little faster, less clear happy and

"impossible block clearing failures" shouldn't occur any more.

Revision 771

Adjusted the backwards timing on GIF for intermediate transfers, this resolves

issue101

hmm gonna make another small update to this, something ive done there i didnt realise before lol. stupid boolean..

Hopefully you got the dump to work? Was annoying to mess with I know. Regardless, gj.

i think there was a modification made to savestates in a plugin, which caused it not to work for me (as i had older plugins) but i got it sorted

Revision 772

Fixed a slight error in my last commit, fixed a bug from another previous commit

and put in rama's hack for FFX which was bugged from r604, i know why its

happening, but how to solve it properly is the issue.

Revision 773

Disabled whole program optimization for dev builds, it really isn't needed for

development builds, all it does is slows us down :P

Yeh, good thing :)

Revision 774

Grandia 2 is playable again. The old block manager was incorrectly clearing a

block which didn't need clearing and thus masking this constprop bug.

so no more freezings after FMVs?

uh sorry, i meant Grandia 3 loll..

crushtes...

For no FMV freezes in G3 you have to use Gabest's CDVD plugin (maybe giga's will work too).

Thanks! hope that works.

Revision 775

wx: Add a logging dialog box, and a debug menu.

Revision 776

Realised that I probably broke MOVZ/N with my last commit and tried again.

Revision 777

Made a rough start to what will hopefully be helpful in the future with dma

timing and control. So VIF1 (and MFIFO) now have a restructured layout, i have

left old code in place for the moment just incase its all a waste of time :p

ee cycle hack was broken :(

Jak & Daxter is playable now o_o

no more crashes when collecting precursor orbs :p

The EE cycle hack? can you check other revisions please, i dont think this should effect that at all

Older savestats don't work anymore,it gives me:

Error: Out of Memory

Not like before with error in the console,and the problem is on exactly this version(on 776 is ok)

yeh old savestates will no longer work :P

Revision 778

Made constant register saving more simple and certain. Grandia 2 is probably

the only game that this would've fixed, but maybe there are others.

Revision 779

Plugin APIs: Restored pDsp, renamed to pDisplay for clarity (Though arcum42's

right and about needing documentation). Renamed PADinit for psx emulator

compatibility. Played around a bit with SIO api, thinking for simplicity best

to just use one plugin of each type (SIO PAD/MTAP, remote, and memcard. Could

even be separate types, but no real need for it). Added PADFreeze() and its

friend SIOFreeze().

Oh yea... Also modified PADinit to not have a "flags" entry, so only one pad plugin can be active at a time. Multiple pad plugins has never really worked, and basically just been a nuisance in terms of additional support requests.

agree, but if pad plugin can be selected either as pad1 or pad2, so would it be the emu is responsible to check if both selected or what?

btw: I suggest to pass "char *configPath" as constant, plugins should never change the working/config path, that will lead to problems if it happened to other plugins and the emu.

Revision 780

Plugin APIs: Corrected a few things that got missed when I committed initially.

Moved the ini path passing to a separate function. Restored a few functions I'd

deleted, and depreciated them instead.

Is there a need for each plugin type to have its own *configpath function? Could just have PS2Econfigpath() or something, and just call it in or immediately after every call to SysLoadLibrary() for all plugin types.

Not really. I was just following the established convention, but it could easily be moved out, and that might be a bit cleaner...

I think there is a typo in GSApi.h, SGSconfigpath instead of GSconfigpath :p

Revision 781

The joys of unrestrained find/replace. :(

Revision 782

Rewrite immediate jumps from the block manager instead of having dispatchers to

do this at execution time.

Should be a tad faster.

Revision 783

Fixed a problem around the VU clip code, introduced in r659. GoW and Persona

(and more) now work without a gamefix.

I'll remove the gamefix if there is no problem.

All problematic games I had are fixed by this :)

well done :)

Revision 784

Removed a VU Clip gamefix.

Revision 785

Forgot this.

Revision 786

LilyPad: Removed "Axis" binding buttons. Try to autodetect full axis bindings

instead, also a dropdown in case that fails. Experimental, untested PADFreeze()

implemented.

Fixed a bug with full axis binding, too... Since no one has mentioned it, and it's been around since 0.9.5, guess not a whole lot of people need/care about it, anyways.

Revision 787

Linux: Bring the gamefixes dialog up to date.

Revision 788

Plugin APIs: Now that I've figured out how multitaps work, fixed SIO API so it

can theoretically actually work.

Oo you probably don't know how much this means to me oO

thank you

valles...

To make the speed limit disable (with tab) more useful, it would be nice to make the GS api able to disable/enable vsync anytime. That way games could be played normally without tearing, and sped up using tab, disabling vsync only then.

Just a thought.

I thought vsync is broken and atm only halves the fps

valles...

@kabooz:

When that does happen, it's usually gfx card drivers being broken. I've seen it with other apps/games on two of my old nvidias.

Sync to vblank works fine for me with hw/sw and dx9/dx10, with gsdx.

Vsync works here, but it instantly halves fps on any short stutter.

So except your game usually runs 80fps minimum, it will be annoying :p

Revision 789

Plugin APIs: Added the changes in r788 to PluginCallbacks.h. Changed the config

path function to be one of the general functions, not plugin specific, and it

now passes the whole pcsx2 config, not just the ini path. I can see all sorts of

uses for that...

Is a dependency on PCSX2 like that really a good idea? I know there aren't exactly a whole lot of other PS2 emulators out there that might want to share plugins, but still...

Also, should Pcsx2 continue to support pad plugins once I have SIO working? I'm planning on writing a very simple SIO wrapper than can be added to any existing pad plugin to convert it to an SIO plugin. Only real advantage of SIO plugins for pads is that they support multitaps, though I suppose we could just update the pad plugin spec to support multitaps instead of implementing SIO, and make multitaps be handled internally by PCSX2 (Requires like 10-15 lines of code, at least for my test game. Bunch of values don't seem to be used by it, so I can't play with them).

Just need to add a PADsetSlot function or something. Might be simplest to go that route, actually...

That's a point. Maybe I'll make it an alternate function, and leave it up to the plugin developer to choose.

I could go either route, as far as the plugin spec goes. The latter might be easier, as we wouldn't have to update every pad plugin in existance.

OTOH, I'm perfectly willing to take that SIO wrapper, and apply it to ZeroPad, and if gabest applies it to his pad plugin, we have most of the bases covered. (Except for SSSPSXPad, anyways...)

Revision 790

LilyPad: Fixed some binding stuff that some incompetant person broke in his

last release. PADfreeze fixed so should work when called twice (Once for pad 1,

once for pad 2).

Just to be clear... The aforementioned person is myself.

Revision 791

Save States: Added PADfreeze calls to PCSX2, though they're currently only

implemented by LilyPad. Also fixed a bug where a save state would failed to

load when the last plugin's freeze function actually saved something. Minor

changes to new plugin API as well.

Because of a convenient bug in load state function, older save states with no

saved pad info should still work. Don't blame me if they don't, though.

Combined with the LilyPad update, this will get rid of the "You need a DS2 plugged in, damn you!" messages in FF12 and other games when you load state too soon.

Looks like this breaks savestate loading with PadSSSPSX, since it has its own PADfreeze function for some reason. Can't find any reference to anything actually using it, and it's not open source, and there's no documentation on it...Hmm....

guhun...

Really I cannot load from new revision's save state from any pad plugins from recent revisions. Load from old revision's save state work fine though (before r791). But from new revision save state I got hang (Trace back into Lily.dll).

Unhandled exception at 0x0db7ad8a (LilyPad.dll) in pcsx2.exe: 0xC0000005: Access violation reading location 0x00000004.

And yes PadSSSPSX cannot even save (pcsx2 close its self), but it can load old revision's save state.

Game: FFX and FFX-2

Try on r791, r794 and r797.

I hope this help.

I can't reproduce the crash - save states work fine for me with LilyPad (latest and the one released in the SVN plugin update, which was 694). Works with SSSPSX 1.6.0 (It's on the SVN, though it doesn't automatically compile), too. Only thing I've tried that it does not work with is SSSPSX 1.7.0. You are using LilyPad for *BOTH* pad 1 and pad 2, right? If you use SSPSX 1.7.0 for either pad, it will crash.

The freeze call in padssspsx is just a ret, no one pops the arguments off the stack there.

But I also cannot use save states, pcsx2 just crashes upon reload, going to debug it.

Found it :P

Revision 792

implemented all vu lower instructions (second pass).

All? and what about lines 599-606^_^ in microVU_Lower.inl

those are branches, they're handled differently.

i can't implement them till later on :p

blackclaw

Nice one

btw ... are you sure you want to keep line 878 like it is now ?

The domain seems kinda dead and sold ...

blackclaw

mehh line 878 in microVU_Lower.inl

forgot that ^^

Why do you avoid SET** in FCOR and not in FCAND and F*EQ? You can do something similar in both.

FCOR only sets VI to 1 if the result is all 1's.

that's why i can do the trick to avoid set**

the same trick won't work for FCAND and FCEQ.

FCAND :

AND r, imm

SUB r, 1

SHR r, 31

FCEQ, FSEQ, FMEQ :

XOR r, whatever

SUB r, 1

SHR r, 31

there :P

the one for FCAND you posted gets the reverse of the result we want.

so it work work unless i add a few more instructions:

AND r, imm

SUB r, 1

SHR r, 31

NOT r

AND r, 1

that might be more expensive than using set**, i'm not sure.

but that trick of subtracting 1 seems to work nicely for the F*EQ opcodes, i didn't think of that :p

Whoops, yeah.

FCAND:

AND r, imm

ADD r, 0xffffff

SHR r, 24

that would also work.

hmm yeah that works :D

i had thought about that trick before, but initially i thought it wouldn't work for all possible values, but after reviewing it again, it does seem to work :P

Revision 793

Looks like the new PCR/TIMR code wasn't called correctly in recMFC0.

This broke Fatal Frame (yes, again..).

Thanks to Nneeve for finding and fixing it so fast :)

I don't know what should to say, rama :P

nice work !!

but the ee cycle hack still was broken for FF

Use intc_stat hack then.

Yeah, looks like an oops. I deleted some code by accident.

Revision 794

LilyPad: Lots of new code that (ideally) makes absolutely no difference. And a

fix for saving rumble settings in PADfreeze.

Revision 795

seems i had misunderstood ACC's pipeline rules.

turns out there only needs to be 1 instance of it, so i had to fix all opcodes

that use ACC.

Revision 796

LilyPad: Couple GUI fixes and cleanups, with intention of releasing soon. Added

mysteriously missing check for binding same control on different pads, fixed

rearranged pad type stuff.

Revision 797

work in progress stuff...

Revision 798

Disabled global optimization properly, and enabled Incremental Link, on devel

builds. Minor code changes compile fairly instantly now. ;) I'll make some

property sheets for enabled/disabled LTCG/WPO in the future.

Added a new Threading class: ScopedLock. Used as an automatic unlocking mutex

(safe for use with C++ exceptions, and cleaner/simpler code too). It works like

C#'s "using" and "lock" directives, for those familiar with that.

Optimized the AtomicExchange implementations for MSVC.

Revision 799

LilyPad: fix0red the save state reload crash (memset overflow randomly null'ed

the global dm variable and other things).

Erm...Oops.

Tyvm, i was wondering whether to report this or not.

federelli: In general, best to report something that significant if it's not getting fixed quickly, IMHO, especially when the author of the buggy code (me) can't reproduce the issue and if you know what you're doing and speak articulate english. No offense to those who don't, but someone who can tell you exactly what problem they're running into, making it clear he knows what he's doing quickly, really helps quash these things quickly.

Indeed, but you guys keep a clean issues list, unlike Dolphin project, and i wouldn't like to see it cluttered with stuff that is likely to be fixed due to the obviousness of the issue. Will report more often from now on though!

Revision 800

Emitter: encode negative 8 bit immediates for some instructions and EAX forms

for MOV

Revision 801

more W.I.P. stuff..

Just because I love to nitpick irrelevant things:

#define writeQ ((mVUinfo & (1<<5)) >> 5)

.. is generally compiled more efficiently when written as:

#define writeQ ((mVUinfo >> 5) & 1)

(compiler uses an 8-bit immediate instead of a 32 bit one)

yeah i should have used the latter method you mentioned.

most those macros were copy+pasted, so i didn't really pay attention to efficiently, but rather if i got the shift-values correct.

i'll probably fix it on my next commit :p

eh, i meant 'efficiency' :p

Revision 802

LilyPad: Minor GUI rearrangements and attempts to beautify. Relabeled "Hacks"

that aren't really all that hackish. To be released as 0.9.11.

Revision 803

xpad: repaired broken keyboard event forwarding to pcsx2

Revision 804

Improved CDVD seek timing; should speed up some games that had abnorally long

load times -- hopefully without breaking other games. (testing needed)

Fixed a condition in the INTC hack that could cause it to hang in rare

occasions.

yay!! gonna test "Test Drive: Unlimited", "Street Racing Syndicate" and "Need For Speed Carbon". Will report in later :)

ok i tested TDU, it's the same...not a single thing has changed...still runs at 50FPS (PAL) while it actually displays 1 frames per minute. (GPU usage is at 3% and CPU usage is at 62% . i have a core 2 duo P8400 at 2.26GHz and an ATi HD3470)

As for Need for speed carbon, it starts to slow down on the "Loading" screen (just like it did before), but now it's causing the emu to stop on a Tlb miss. (dunno when this started happening. Haven't tested anything for at least a month).

Still haven't tested street racing syndicate tho.

hope that helped a bit. And if anyone needs some dumps, just let me know :)

muhi...

There is a typo in CDVD.cpp

static const uint Cdvd_FastSeek_Cycles = (PSXCLK*30) / 1000; // average number of cycles per fastseek (37ms)

may be should be

static const uint Cdvd_FastSeek_Cycles = (PSXCLK*37) / 1000; // average number of cycles per fastseek (37ms)

or

static const uint Cdvd_FastSeek_Cycles = (PSXCLK*30) / 1000; // average number of cycles per fastseek (30ms)

Revision 805

Fixed a bug in the vtlb constprop support (stores weren't using the right

macro).

Reduced the BIOS rom warnings from gaudy red text and stars to simple yellow

warnings (since they really don't matter).

Gah I keep saying stores, but it was actually Loads. >_<

Revision 806

R3000air: Revamped the interpreter's setup to use some nifty virtualized

functions for super-compact and clean interpretation + constprop + optimization

info tracking. And, oddly enough, using virtual functions yielded a speed

increase.

(merged trunk revisions to current)

Revision 807

Removed unnecessary rs flushes for loads and stores

Revision 808

Save a few bytes on const flushing using 5 byte eax movs for 0 and -1 instead of

10 byte immediate movs.

Revision 809

Minor optimizations to vssprintf.

Revision 810

R3000air:

* Added support for the R3000A's DIV unit (runs mult/div instructions parallel

to other instructions)

* Moved Instruction Implementations into .inl files and added some forceinline

directives (15% speedup, thanks to MSVC's global optimizations being bigtime

fail still, when it comes to class member functions).

* Improved the disasm diagnostic, both in terms of speed and output quality --

tho it's still incredibly slow.

For those keeping score:

I'm up to 95 fps in Disgaea's menu .. original IOP interps were ~65 fps (tested by specially enabling the IOP interpreter with the EErec).

The latest speedup came because I implemented pipeline perfect cycle timing for the R3000's DIV unit, which as it turns out, is almost never used in parallel by the IOP kernel code (so it generates tons of 35 cycle stalls, which cut down on the instruction throughput considerably).

Oh and for the record, I get 154 fps when using the current IOPrec, so the interps are still plenty slow in comparison to that, obviously. (however my experimental Threaded IOP Interpreter got about 147 fps ;)

kenzozus...

Compiled error.

1>..\..\SaveState.cpp(143) : error C2065: 'PAD1freeze' : undeclared identifier

1>..\..\SaveState.cpp(144) : error C2065: 'PAD2freeze' : undeclared identifier

1>..\..\Plugins.cpp(74) : error C2146: syntax error : missing ';' before identifier 'PAD1freeze'

1>..\..\Plugins.cpp(74) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

1>..\..\Plugins.cpp(91) : error C2146: syntax error : missing ';' before identifier 'PAD2freeze'

1>..\..\Plugins.cpp(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

1>..\..\Plugins.cpp(91) : error C2086: 'int _PADfreeze' : redefinition

1> ..\..\Plugins.cpp(74) : see declaration of '_PADfreeze'

1>..\..\Plugins.cpp(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

1>..\..\Plugins.cpp(358) : error C2146: syntax error : missing ')' before identifier 'SysLoadSym'

1>..\..\Plugins.cpp(358) : error C2059: syntax error : ')'

1>..\..\Plugins.cpp(391) : error C2146: syntax error : missing ')' before identifier 'SysLoadSym'

1>..\..\Plugins.cpp(391) : error C2059: syntax error : ')'

1>..\..\x86\iFPUd.cpp(394) : error C2065: 'CHECK_FPUMULHACK' : undeclared identifier

1>..\..\x86\iFPU.cpp(656) : error C2065: 'CHECK_FPUMULHACK' : undeclared identifier

Kenz: You must manually do Svn update your /Common and /3rdparty folders, if using the r3000air branch. That will fix your errors.

Revision 811

pcsx2: got rid of the compile warning.

microVU: minor changes/cleanup.

Revision 812

Added a BastTaskThread class to the threading tools.

Revision 813

Implemented more correct support for the IOP's "isc bit" (bit 16 on the COP0

status register), which in turn allowed me to simpify some of the IOP's memory

access and paging logic.

Revision 814

More changes to the IOP's memory model. Some of these are experimental and

might cause problems (needs testing). Quick rundown:

* The R3000 does not have a TLB, and has no valid addresses mapped above page

0x2000 in physical memory [lower 512M]. Thus all addresses can have the top 6

bits masked off and still retain full validity. For example, address 0xbfc0 is

simply a mirror of physical address 0x1fc0. Technically speaking, a full

emulation of the IOP memory model would raise bus error exceptions for accesses

between 0x2000 to 0x8000 segments (instead of treating them as mirrors of the

lower 0x2000 segment), but buss errors are generally fatal (unrecoverable)

program errors that would never happen within the context of game emulation.

* The IOP's SIF register space is only 256 bytes, and then mirrored repeatedly

through it's 64k page at 0x1d00.

Revision 815

Major overhaul of the savestate system!

Since backwards compat of savestates got totally broken a few revisions ago

anyway, I decided to take this opportunity to revamp the savestate system with

some significant cleanups (yes it loses all backward compat once again).

Improvements include:

* Reduced state size by removing some unneeded data (faster saves now too!)

* Added string tags to varios "sections" of the states to assist in

troubleshooting and retaining savestate compat in future versions.

* Better error handling and fewer memory leaks.

* Removed some unused/obsolete data from psxRegs, Counters, and psxCounters

structures.

* Removed all old savestate versioning code, since none of the old versions are

supported anymore anyways.

Woot, no longer 5-10second pauses when saving :D. A good milestone's been reached today, grats.

does(/should) this solve the IPU issues with savestates?

Revision 816

LilyPad: Svn release builds now have svn numbers, some configuration

load/save/populate code cleanup. Two additional checkboxes that at the moment

do absolutely nothing useful, so don't get too excited, probably be quite a

while before I get around to hooking everything up...

Revision 817

A few very minor comment cleanups; getting all my code branches in sync for when

I hit the road today.

Revision 818

Linux: Fix a minor breakage in the gui code I just noticed...

Revision 819

Fix for some random slowdown introduced in 815 (bad cacheline coloring caused a

random 30% speed drop when not using speedhacks) >_<

I can't compile pcsx2.I get error message:

..\..\vtlb.cpp(53) : error C2086: 'vtlb_private::MapData vtlb_private::vtlbdata' : redefinition

c:\documents and settings\VSUB\my documents\visual studio 2008\projects\pcsx2\vtlb.h(89) : see declaration of 'vtlb_private::vtlbdata'

The problem is in this rev. not in any other(811-819) and I've tried to rebuild pcsx2 including pthreads and zlib.Everything is up to 819

Sorry,ignore my post...after I reinstall my windows I forget to add the common folder back to my update program(the common folder was rev 798)

Revision 820

Linux: Make some of the assembly look a bit better. Change the

PCSX2_ALIGNED_EXTERN defs a bit.

Revision 821

wxgui branch: Full merge of trunk into the new wxgui, including a revision from

way long ago that somehow got missed (when I renamed Windows folders in some

plugin dirs)

Revision 822

Nneeve worked a bit on our lovely floating point cpu's (mis)ability to do rsqrt

the way the ps2 does.

Should be better now ;)

Revision 823

Get rid of some duplicated code in cpuException...

Revision 824

LilyPad: Fixed PADfreeze bug. Also some stuff that shouldn't do much yet.

what's the purpose of PADfreeze anyways..?? can you enlight me.. is it saving PAD mode and state or what?? without this function seems I can't resume execution when I pause the game..

Just saves the state of the pads. When you're configured for both pad 1 and pad 2, it's called twice with different arguments. Just look at SaveState::FreezeAll(), memSavingState::FreezePlugin() and memLoadingState::FreezePlugin() in SaveState.cpp. Or LilyPad's implementation of PADfreeze(), though LilyPad's a bit of a mess.

*Twice with the same arguments, rather. Called with different arguments for loading/saving/determining how much memory you need.

Thanx alot, didn't notice since I debug with earlier revision builds..

Revision 825

microVU: implemented first pass for upper instructions.

Revision 826

GSdx: a few games should be sharper (example: persona 4, guitar hero), blurring

effect done inside the output merger is overridden when detectable, hope nothing

got broken by it.

This is a nice fix. Agreed, Persona4 just looked like crap with the blurring.

You couldn't make out anything really, even at highest render targets :p

Does this remove blurring effect of FFX?

If you mean the blur in battles then no, that's a different thing.

Excellent, there's lots of games I've tried that have the same issue like Persona 4 that looks blurry and refuse to look great whatever internal res I set.

Would be great to list titles that improved, or did not improve, those I could examine further.

I think God of war 1 is a little sharper.

Can't test God of war2 because of the Green screen when using hardware acceleration. (like God of war 1 used to have some month or if not a year ago.

isn't it possible to remove the blur completely or just shift everything to center that pixel for pixel is correctly displayed?

hope you know what i mean

I'm not sure what you are referring now, ffx?

beenn1...

nice work! gabest

but this don't work on blurring

effect of dragon quest V ,check it out if you can

@ gabest

no, i mean games like god of war, jak1, GT4, etc... they are also blurred

ok, going to check dq4, gow, gt4, I have those

- gow was similar to persona4, just shifted the other source

- dq5 also used the output merger for blurring, just a bit different

- gt4 does not seem to do anything suspicious there

Revision 827

Linux/SPU2-X: A bit more work on the Linux port of SPU2-X.

Revision 828

2 more things by Nneeve. Let's see:

A few changes to the full fpu mode, so it behaves as erratical as the ps2 fpu.

And a fix for a MMI opdcode.

Revision 829

Buildsystem improvements - Added two new property sheets for Incremental Linking

and Global Linking. Incremental Linking is fast and allows for Edit and

Continue debugging (debug/devel builds), Global Linking is for Release builds.

Applied new property sheets to Pcsx2, SPU2-X, ZeroStuff, and NULLs.

Not sure if having Edit and Continue enabled is worthwhile or not. I've never had much success with it in the past. But I don't think it really hurts compilation times either, so I guess it's not a loss either way.

valles...

Stuff now fails complaining /Ox and /ZI can't be enabled at the same time.

Lowering them to /Zi fixes that, but it's the same as reverting this.

Lowering optimization would also fix it, but it'd make devel slower, which isn't desirable.

Ok, I'll set it up so that Edit and Continue is disabled by default. I don't think it's a very useful feature anyway.

Revision 830

microVU: implemented CLIP instruction + minor changes...

Revision 831

microVU: moved stuff around, and implemented some other stuff... also added the

file microVU_Analyze.inl to project.

Revision 832

Linux: Fix up console logging so it both doesn't insert newlines every time the

color is changed, and doesn't log the color change codes in logs, as unless you

are using a console based text editor, it's harder to read.

Revision 833

Linux: All right, this will have to be fixed properly at some point, but hack in

a printf so that Linux users can at least see the exact exception games crash on

if they crash (Though it won't get logged at the moment).

And, yes, there's a reason why I'm not using 'Console::Whatever' here.

And I have tried to catch the exceptions; I'm just having no luck with it.

Chances are if the esp or ebp registers aren't holding the right info (and I think we use one or both int he current recs, which is bad) then the exception stack unwind could fail depending on how the compiler implements SEH exceptions. The current recs fail to preserve either of those registers. Someday that will be resolved I hope. :/

In any case, my idea for SEH exceptions for instruction-perfect error handling from the recs won't work in its current form. I neglected the impact of register alloc and const reg flushing, meaning that when an exception is thrown, the register state in cpuRegs is not current. There are two ways to go about fixing that, but neither is especially neat or easy.

Sounds messy.

The printf statement I put in will work for now, I suppose. I noticed it because I was looking closer into why Star Ocean's unplayable on Linux.

The last warning before crashing was:

terminate called after throwing an instance of 'R5900Exception::TLBMiss'

and was never displaying:

(EE) Tlb Miss, addr=0x33eb3434 [load]Aborted

Which it should have been. Of course, one could argue that it shouldn't be displaying that either, but at least it's more informative... :)

Revision 834

GSdx:

- more thorough blur detection

- makesnapshot delayed until the next vsync (so shift+f8 won't crash randomly)

xpad:

- fixed " Issue 38 : Bad performance with Xpad"

wow it auto-linked the bug report page :D

Yeah, that's one of the cool things google code does for you. It links to issues and revisions.

Though it doesn't check to make sure the link actually works. It will quite happily link to invalid revision numbers, in my experiance.

Thanks a lot again for the nice fixes gabest.

Does this changes only for SW? Thanks anyway

God of war blur is gone now :)

Would hbe great if God of war 2 green screen be gone too :)

Nice job.

the revison number is still 826.

and what's the difference between 826 and 826m ?

m means there may be changes to that revision not checked in yet

I re download the gsdx code and compile again, the m seems related thread safe opitimize (some scene increase 10fps).

and the revision number is cerrect :P

The white fog in GOW is fixed ??!?! Wow ! Great job! If you fix the green screen in Gow2 you're a GOD! Thanks Gabest !

Its not the white fog that is fixed. The game is just less blurry. (It look sharper.)

Will try with Gran Turismo 4, for some reason in previous revs the higher the internal res, the blurrier the game became, i'll try this rev tonite.

Revision 835

- Various fixes to MMI and more changes to opcodes to mimic ps2 behavior, thanks

to Nneeve.

- Brought back a gamefix for Persona games. They still have missing geometry

without it (VU clip flag problem)

Revision 836

microVU: backing up current code, going to have to rethink some things :/

looking for the best solution, don't implement it so quick temper

Look for worst solution, implement it with a quick temper.

lol

Revision 837

wxNewGui: Cleanups of the Logging dialog layout (yet unfinished).. added some

helper functions for common dialog layout stuff. Still learning my way around

wx. :/

Revision 838

LilyPad: Loading savestates made with other pad plugins should work a bit

better.

Attempt to fix keyboard input sometimes not working until window is

unfocused/refocused. Happened to me once (And only once), when I was

experimenting with disabling read input in GS thread. There are a number of

potential causes of this, and I've added workarounds for several of them.

Slightly updated code to determine when to update pad state - added both a

timer, so read state less when fast forwarding, and Multitap support (to that

particular chunk of code).

Just to be completely clear, Multitap is not yet actually working. Change refers to the particular chunk of code that determines when to read the state of controls, which now works with my extra Multitap stuff, which isn't fully hooked up yet. This just prevents me from reading the state of all controllers each time the state of any of the 4 multitap pads is read, when reading pad state in GS thread is disabled (When it's enabled, there's no problem, even with the old code).

"Attempt to fix keyboard input sometimes not working until window is

unfocused/refocused."

Oh, at last :P

Revision 839

LilyPad: Fixed logging bug, log slightly more data.

Revision 840

GSdx: disabled blurring can be re-enabled in the settings or with the END key,

the image shifting is corrected back to 1 pixel even if the internal rendering

resolution is upscaled.

is possible to implement something like postprocessing on-off with a key ingame?

It's disabled because it does not work, not because slow :P

:) i didn't say it was for slowness.

beacuse of some games works better without but we have to manually find them and tell the CRC to you.

it was a curiosity to know if it is tecnically possible.

I've just noticed that DirectX March 2009 is out...

<a href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=24a541d6-0486-4453-8641-1eee9e21b282">DirectX SDK</a>

<a href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0cf368e5-5ce1-4032-a207-c693d210f616">DirectX Runtimes</a>

Oups, I thought it can handle HTML... Sorry...

cool, let's see what's new in dx11

Well, if there is no crc added yet then there is no drawing skipped, you won't miss the garbage appearing on screen.

I think only one thing will interest you - COMPUTE SHADER!!! Yeah!!!

Can't wait when it will happen... I'll buy new PC when DX11 hardware will be available for reasonable price...

Compute shaders should run on dx10 cards with limited blocks or something, but november's sdk was a bit unfinished to try even with the reference rasterizer, documentation was sparse too.

I don't understand what's up with GT4's car selection, it looks better in native res than 2048x2048 (looks uber blurry).

Looks awesome in 4096x4096 tho :P.

Revision 841

GSdx: persona 4 character shadow error fixed, might break other things (hope it

doesn't :P)

This is great.. One of the more annoying bugs down :)

beenn1...

is "shadow error " mean those rainbow floor texture?

chuuey

nice work :)

crushtes...

Wow! I thought this would never be fixed :P

alfre...

You are te best, thank you!!!.

PD: I do not want to be thankless, but you can watch the ICO error in Hardware? Thanks

This is great Gabest. Thanks a lot for improving the hardware part of GSdx again. Just wanna report a tiny bug. The shadows under the characters in Dragon Quest 8 are missing. No big deal. Anyway, just reporting, nevermind. Thanks man.

archer.mac

Looks like that last post of mine about the rainbow floor caught your eye? :D Excelent work!

Persona 3 had the same floor issue and it's gone now too!

awesome!

i was waiting for the day the persona 3 rainbow floor bug would be fixed :D

great fix, now I can play persona 3 without any problems :) Thanks gabest.

it doesn't happen anymore but i am getting missing floor textures on Persona 3 FES, software or hardware doesn't matter dx9 or dx10 ether.

archer.mac

P3FES here works like a charm (but still,noticeably better in DX10 over DX9! dx9 cuts off some textures a bit like the old gsdx in dx9 did too) with no "missing floor",latest pcsx2 build.I tried it all over town and tartarus,I'm guessing SPS?There is a gamefix for it but I didn't encounter any in P3FES even when it's off,only in P4.

Found the problem it needs the VU Clip Hack the same for God of War.

Dunno if its this revision, but the annoying ghosting in digital devil saga is fixed :)

Revision 842

Linux: A little bit of catchup with Windows; Add the VU Clip hack back in for

Persona.

Revision 843

Replaced more SysPrintf's with Console:: functions then I want to think about. A

few minor changes in passing, mainly format-related.

Revision 844

Since WriteLn is used for logging, and it automatically appends newlines, remove

a bunch of legacy newlines from various logging functions.

It doesnt automatically append new lines, ive just got a big mash of text now, it might do in linux but it doesnt in windows.

Ow, yeah. This really messed up logs ><

nvm fixed it :p

I hate Windows/Linux differences. :(

Revision 845

LilyPad: PADfreeze() now saves state of current poll, just in case it hasn't

been completed. In practice, state never seems to be saved in the middle of a

poll, but best to be safe.

Note that this "breaks" old LilyPad savestates, but that just means you'll need

to wait for your pad to be initialized before loading older states for picky

games, like you do when using states saved with other pad plugins.

Revision 846

Added a new CheckedStaticBox panel, which is something I like to use a lot

(semi-working test use in frmLogging).

Revision 847

Included Nneeve's recent fixes to DIV / DIVU instructions, regarding MIPS

specific behavior in div by 0and div by -1 scenarios.

Added a preliminary codebase for new IOP memory system (not anywhere near

finished, but my laptop is failing and I don't want to risk losing it before I

get home).

forgot to mark my last 2 commits as branches, sorry. :/

hm the Harddrive is dying? this is indeed bad.

Revision 848

- Nneeve fixed the Tri-Ace gamefix so Gradius5 doesn't crash with it enabled

anymore.

- Moved one global variable for the VU interpreters, which surprisingly speeds

up Star Ocean 3 for me.

- Set Flush to Zero for FPU and VU back to on. Let's see how long it lasts this

time :p

- Removed the FFX hack from pcsx2! It's still toggled in the GS plugins, the

correct behaviour is having it always on.

Oh, and most likely fixed a few bugs concerning the cop2 or vu interpreters by reverting a strange hack :p

"- Moved one global variable for the VU interpreters, which surprisingly speeds up Star Ocean 3 for me."

Hm... how much? I don't have speedup at all.

85 to 87fps here.

Given the nature of the code change, I'd mark it as random :p

That's like 2.3% increase, so yea don't expect to see a difference unless you do very accurate comparisions while checking the fps meter closely. :p

I suppose I should probably set ZeroGS to default to the Final Fantasy Hack being on rather then off now...

Yeah, please do so :)

All right.

I'll take care of that once I figure out the best way to do so. I'm just not sure if I should turn it on by default and allow the user to turn it off, turn the current hack into a "Disable FFX hack" option, or just remove it...

Bets to completely remove it.

We determined that what the hack does is correct gs behavior.

Sounds good. Guess I'll take care of that tomorrow, then. (Tomorrow probably still being Saturday, just Saturday after I've gotten some sleep).

Then it'll just be up to Gabest to remove it from GSDX, and Zeydlitz to remove it from ZZogl...

Revision 849

Fix the vu interpreter thing again. This should be right now (according to

cotton, blame him if its not!) :p

Revision 850

General cleanup in Gif.cpp && IPU.cpp. Did a bit of refactoring in Gif.cpp.

Moved the path3hack to patches.

Always irritating when you notice typos in your comments after committing. Guess I'll get those next commit.

Great stuff, arcum. Hope you find the time and will to take care of SIF and maybe even VIF, too! ;)

Thanks. I had several projects going, and I didn't really feel like working on any of them.

So I decided to polish some code instead...

I may look at Sif and Vif at some point. I was also looking at Cache.cpp, and realizing that all the code in it is dead, broken code. Most of Decode_XA is unused, too. In fact, all that's used is one structure in the header... :)

Oh, and if the IPU changes seem fairly minor, I managed to break the Atelier Iris 1 opening the first time on my local copy, reverted it, and redid some of the changes. :)

I'll probably be returning to it at some point.

Oh my. Just noticed. You know you've been coding too much when you use && instead of & in your sentences. ^_^

LOL, I also didnt notice :D

Freaks. :D

Revision 851

LilyPad: Fixed bug detecting enabled multitap pads. Multitap support now seems

to be working on the LilyPad side of things now. At least it seems to work with

the one game I've tested, after modifying PCSX2. Necessary PCSX2 changes have

*not* been committed.

Still need to hook it up to the PCSX2 GUI and figure out how to say the extra

memcard slots are all empty.

Revision 852

ZeroGS OpenGL/Linux: Took out the FFX hack, and turned it on by default. Removed

a few options that weren't doing anything, and added a few into the Linux list

that were missing.

I might do the same for the DirectX version at some point, and the Windows gui of the OpenGL port. I'm just not as familiar with either...

Would have committed some cleanup work on Sif and Vif, but:

a) I broke old savestates. (mainly because I turned some ints to bools that clearly should have been bools.)

b) I broke the background on FFX's opening. It looks like it was done by Gust. ^_^

aren't there some games wich tend to crash when the FFX Hack is forced on?

Revision 853

LilyPad, Plugin APIs: Slightly changed how multitap API additions work. Now

enabling is handled completely by the pad plugin. If anyone ever really feels

like adding support for more memcards, can move it over to PCSX2 itself.

Also add some documentation to PadApi.h.

Revision 854

Pcsx2: Added experimental mtap support, must be enabled through pad plugin.

Fixed bug in default PADfreeze function that would fail to load states created

with LilyPad when using other pad plugins. Added support for disconnected pads

(Mostly a convenience for mtap support, for games that use pad presence to

assign pads to players).

PADfreeze bug would affect loading any state made with a pad plugin supporting PADfreeze and trying to load it with a pad plugin that didn't. LilyPad's just the only plugin that currently support it.

Also, I updated the SaveState format, but save states should be backwards compatible.

Revision 855

LilyPad: One more quick bug fix in mtap stuff.

Revision 856

Forgot to remove a couple debug lines.

Revision 857

More work on Gif.cpp & IPU.cpp. Got fed up with straightening IPU.cpp up by

hand, so I ran Artistic Style on it, and then strightened the results out.

For anyone who doesn't know what I'm talking about, Artistic Style is a little code reformatter I use occassionally:

http://astyle.sourceforge.net/

Since we have several programmers with several different coding styles, I don't use it that often, but it can be very useful on occassion.

I keep it with fairly minimal settings:

--

indent=tab

indent-switches

indent-classes

indent-cases

pad=oper

unpad=paren

recursive

brackets=break

Oh, and I actually did pull a few pieces of code out into new functions in IPU.cpp, to get rid of some redundant code, incidentally...

skynet-r...

3>HwWrite.obj : error LNK2001: unresolved external symbol "void __cdecl dmaIPU0(void)" ([email protected]@YAXXZ)

3>HwWrite.obj : error LNK2001: unresolved external symbol "void __cdecl dmaIPU1(void)" ([email protected]@YAXXZ)

3>D:\EMULATION\EMULATORS\PS2\SRC\\bin\\pcsx2.exe : fatal error LNK1120: 2 unresolved externals

Let me take a look...

The 2 have to be declared "extern" in ipu.h ;)

Got it; I'll be committing shortly.

Yeah; I didn't notice because gcc didn't care about it...

Btw, I kinda like this tool. Seems we could use it on a lot of files in pcsx2.

(SPR, Vif, VifDma come to mind :p )

I'd love to use it on a bunch of the files, honestly. I've already used it on a few plugins in the past. (CDVDiso and ZeroSPU2, possibly others.)

Always scan over the code afterwords, though. It'll ruin ascii art, for one. And I seem to recall some of the complex defines being messed up before I figured out the settings I wanted.

It'd be a good idea to use it on some of the really badly formatted files. (The ones you mentioned *are* some of the main ones that come to mind.)

Credit where credits due; this tool was pointed out to me in the comments on one of my revisions in pcsx2-playground...

uh, much edits on the IPU.

are there noticable Changes? :x

No, shouldn't be. Except it looks better now ;)

Revision 858

Add dmaIPU0 & dmaIPU1 externs. :(

Revision 859

LilyPad: Fixed a binding bug due to old debug code still hanging around, added

ability to swap pad bindings (Right-click context menu).

Сколько можно...

Сколько нужно.

DantePinky все что не делается все к лучшему

Indeed

When will make vibration?

It is necessary to sit on sssspsx 1.6.0...

как то так

Huh? Vibration has been supported and working since at least 0.8.4.

English only. k thx.

Vibration is working, both motors even (as opposed to ssspsx which only drives one motor).

levanchuong87

Vibration? It's not work on my gamepad (made in China)

I don't particularly care if it doesn't work for your controller. You either haven't configured vibration, which is hardly my fault, or your controller adheres to no open spec (In other words, it's buggy), and I can't be expected to get it working.

levanchuong87

But,it's work with SSSPSX 1.6.0! I even get it vibrating without any complex Configuration.

My code adheres to DirectInput spec. Blame either your hardware vendor or Microsoft for your hardware or its drivers not adhering to spec. Code is open source, so if you have any doubts about that, feel free to take a looksee. I can't fix problems with buggy hardware that I don't possess myself.

levanchuong87

I get it vibrating after going through your $%#%^&@! configuration.

WTH,why does it have to be so complicated?

And one thing: The FF Effect much too long than SSSPSX,and it's one thing which's not real.

Ex: In GOW,when I use combo with the final strike,SSSPSX make a soft and quick vib,but your little Lily make it a whole second.

Anyway,perhaps i don't config it properly?

Because I believe in working with every device out there. SSSPSX only works with devices that behaving in a certain manner. Some devices don't like forces with more than one dimension on them, some don't like forces with a bunch of dimensions. Some devices only trigger certain motors with periodic forces, others adhere to spec and trigger motors based on which motors you actually tell them to trigger. My code should work with all of them, rather than just those that behave as I hope they will. Regardless, it only takes a minute to configure, for most devices.

I vibrate until I receive a signal not to, while SSSPSX vibrates for 10 milliseconds and then stops. If GOW doesn't tell me to stop vibrating, I don't.

Revision 860

miscellaneous microVU changes...

Revision 861

microVU: some lower opcode changes...

Revision 862

More cleanup. Ran Artistic Vision on a few of the files rama had suggested, and

did a few changes that make things easier to read. Still more work to be done

here...

Revision 863

removed an incompatible option from devel builds (it refuses to build),

presumably whoever changed it wanted the debug option on, so ive removed the

optimization.

Revision 864

Fixed issue with DBZ Tenchaichi 2 not booting, also fixed line endings for the

logging to file, man that was hard to read!

Revision 865

Set zlib to use fast compression for savestate (big speedup for when making

savestates).

Disabled Edit and Continue and re-enabled optimizations in devel mode (thought I

disabled Edit and Continue earlier, but I guess it didn't get saved/committed

correctly).

Save states are much faster now. Thanks a lot.

Revision 866

Fix for crash of the titans, unbroke FF12 in my last commit, fixed a couple of

other things. Now handles DMAs which are enabled while the DMAC is stopped, so

they start when the DMAC is re-enabled. Might need some testing to make sure

stuff isnt broke :p

Thanks

I guess it will break something :P

probably :p

Revision 867

Fix for Crash N Burn

Whoa, Refraction is on a Rampage ! Go, go ! Fix everything you come across man :D

Next commit, everything works! :D

i wish lol

keep on, everything will perfect.

Yay!!!!!

azd.bai...

How to download these DLLs? i can't find it

next WTH are you talking about? XD

nice going refraction *cheer*

azd.bai...

i mean how can i download this updated emulator? cause in the official website i found only the release of march the 1st

you can get it from the official forums

Revision 868

GSdx: just increasing the revision number of gsdx to test something...

doesn't look like "just" rev# raising XD

strange way of "just" increasing revision :)

beenn1...

Gabest,just let you know,this reversion crash when I hit Esc,it didn't happen in R841

Replaced individual pointers to the privileged registers with a large struct, so the compiler only has to care about one pointer now, but I did not notice any problem with it.

Revision 869

wxGui branch: More improvements to CheckedStaticBox. It's mostly complete now,

and I'll likely move on to implementing some new dialog boxes now.

guhun...

Will this new UI be used in all platforms?

juz...

If I remember correctly that is the very reason why they began to implement new gui in the first place.

Someone correct me if I'm wrong.

Revision 870

LilyPad: Fixed a bug in list of bindings when go to config screen after running

Pcsx2 for a bit, and some devices enabled on the config screen were not enabled

in game (Either due to focus issues, or, more probably, due to mouse API not

being disabled, but not running with mouse focus).

Also bug fix for cursor clipping rectangle not being reset after window resize.

Revision 871

I don't think we really need someone's random Thumbs.db file on the SVN.

Not really worth its own commit, but Thumbs.db files spewed everywhere just annoys me.

Revision 872

Increased the MTGS ringbuffer from 2 to 8mb. Fixes slowness in games with lots

of data moving.

(Xenosaga series for example)

crushtes...

Thanx rama, this sounds very promising. I have a feeling (wishfull thinking?)it will affect many other games with slowness probs.

Depending on how much difference this makes, might be interesting to have this adjustable in one of the dialogs...

great ^^ but now i'm curious why don't we set all buffers a notch higher? is it because memory bandwith?

vesnikos

whats the impact on overall performance by doing that?

Mostly it just benefits games which make frequent use of large texture uploads, since those large uploads were previously 33-50% th size of the mtgs buffer and caused the MTGS to stall to the point of nearly being single-threaded in nature.

The buffer was supposed to be 4MB but it was bugged and set to 2MB instead. 8MB yields a very small benefit over 4MB on a select few games such as XS.

veaac.fd...

Does this improve the slow mech scenes in XS2?

Nope, the mech scene slowness is a GSdx problem.

I'm going to test this when I get home tonight. Quick question though (since I'm an impatient ass :D ). Is Breath of Fire V one such game that'll be affected by this?

BoF 5 is slow because of one function in GSdx thats not optimized.

Doing a profile guided build of gsdx using this game fixes it.

Which?

CadeFost...

Nice work!Does it Fix Tales of Legendia Slowness or is it gsdx bug too?

Gabest, I've sent you on the forums the modded function by chickenliver, if you want to take a look at it. I think it would be worth it.

rodiablo...

OMG. Thanks very much, Jake! I tested Xenosaga with my usual setup and noted an amazing increase in performance with my poor E2180 @ 2.8GHz. Xenosaga is one of my few and favorite ps2 games. Again, thanks very much :)

rodiablo...

Sorry, I said Jake :P I meant ramapcsx2. I was reading the changelogs and got confused when writing this. Anyway, sorry rama for the mistake. And Thanks very much again and again =)

Revision 873

GSdx: updated the delay loaded directx dlls to match the latest sdk

any real difference using older directx versions? because i have a modde dx10 on XP but it is stuck at rev "39".

It will search for the dll version it was compiled with, but I don't think dx10 would work on xp anyway.

There are modded 'hacks' of DX10 available that do work on XP, so long as you have a DX10 compliant video card. They get updated later tho, since obviously they're not a microsoft thing.

Revision 874

A few tweaks to more often called functions = general speedup :)

How much more fps?

Ghe, test it, will ya? :p

Its not much, but its there..

When rama talks about speedups he means like 85 -> 87 FPS. j/k :p

nickolas...

Even 1 fps is significant. Little by little folks and even an atom cpu will be able to play at normal speeds all the games. J/K

Ami.Mizuno.87:

Exactly, and that in every game. For free.

Add that to the 20 other small speedups and see where you are then ;)

Nope the speedup really is here, i get about 5-12 fps+ in MGS3 and about 3-6+ in God of War, didn't tested my other games yet, anyway thanks Rama

Revision 875

wxGui Branch: Added some console logging code (not yet finished). Can't really

use wxWidgets built in version because it's not extensible (grr).

Revision 876

wxGui branch: Merged with trunk (2 weeks of changes!)

Revision 877

Shortcut for intc_stat reads. Speeds up games that use it a lot.

85-87? :P

Thanks for all those tweaks Rama. I come along observing Pcsx2 for a long time, I know that those little improvements makes a great difference in the end. An 1 Fps gain tweak is worth gold xD

Revision 878

<cotton>for april fools i can put on my next commit that microVU is finished and

doubles fps

<cotton>but i guess i shouldn't do that on the svn :D

<cotton>or maybe i can >.> <.< >.>

:) imagine that!

Hehehe !

lol

oh, it fix the green screen issue for GoW2. :D

valeri...

junrgao:

is the green screen problem is solved, but GoW2 PAL version at the end of the mission (the cavern hand) the game freezes on the movies and does not go ahead .... sorry my English

Revision 879

Still messing with Sif, Vif, and SPR.

VS2008 compile error - Sifcmd.h(61) : error C4430

skynet-r...

1>d:\emulation\emulators\ps2\src\pcsx2\Sifcmd.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

1>Sif.cpp

1>d:\emulation\emulators\ps2\src\pcsx2\Sifcmd.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

/trunk/pcsx2/Sifcmd.h

line 61 : u32value; -> u32 value;

Already noticed. I'm just in awe that that compiled and ran in Linux. And even emulated several games properly.

It'll be fixed in a moment.

Revision 880

How that compiled with a space missing, I may never know...

I really have to assume value isn't used for much. :)

I think declaring stuff like that in C/C++ defaults to int, if I remeber

correctly.

*nuts*

Right, but anything trying to access "value" should have errored out. Unless it's unused, anyways...

Revision 881

wxGui branch: major progress on many fronts!

* Added new files AppConfig.cpp and StringUtils.cpp, and removed memzero.h

(we'll use the win/linux platform dependent implementations)

* Enabled wxWidgets memory tracing since we don't use a memory trace util of

our own.

* Switched many instances of std::string to wxString.

* Added preliminary support for configuration settings and ini file creation.

* Added a set of parsing and splitting tools to StringUtils.

* Set it up so that the Console log is attachable to the main window, when

dragging (fun!)

* Main window and console log window record and restore window positions

between runs (only partially implemented yet)

Revision 882

wxGui branch: Moved and renamed some files and classes. I'm quite a bit more

fond of the C# / Java naming schemes for forms and dialogs over the wxGlade

frm/dlg prefixes. Namespaced all dialogs into Dialogs::. (all two of them at

this point, but many more will come! .. someday)

kenzozus...

..\WinMain.cpp(84) : error C2143: syntax error : missing ';' before '*'

..\WinMain.cpp(84) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

..\WinMain.cpp(85) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

..\WinMain.cpp(86) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(87) : error C2146: syntax error : missing ';' before identifier '_argv'

..\WinMain.cpp(87) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(100) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(100) : error C2059: syntax error : ')'

..\WinMain.cpp(103) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(103) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(103) : error C2064: term does not evaluate to a function taking 1 arguments

..\WinMain.cpp(106) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(106) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(118) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(127) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(127) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(137) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(146) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(146) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(149) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(157) : error C2065: '_argv' : undeclared identifier

..\WinMain.cpp(158) : error C2065: 'argv' : undeclared identifier

..\WinMain.cpp(161) : error C2065: 'argv' : undeclared identifier

Error log. :(

spam.Sai...

compile the debug version not the release config

Yeah I hadn't even bothered to test compilation of release builds on that branch yet. Noit much point after all -- it doesn't actually run anything yet. :)

Revision 883

Implemented some more vtlb optimizations: Regalloc should be working a bit

better now, and removed some unneeded code on the LWL/SDL/etc interpreter

callbacks.

Emitter: Added Rm/RmOffset forms for AND32 - Untested. I'm pretty sure they're

valid instructions but I could be wrong.

Revision 884

More vtlb optimizations: Switched over to full const resolution of the TLB, and

added a shortcut for the INTC_STAT register (replacing the one rama added to

HwRead.cpp a couple days ago).

Revision 885

Final pass of today's vtlb optimizations: Improved the codegen for const-

propagated direct reads and writes (very minor optimization).

Optimisations are almost always good...

Can someone tell me is making PGO build for my most played game worth doing?.. It seems that there's almost no perfomance boost... Maybe I'm doing something wrong, I have no experience with that... Tried to make PGO build for pcsx2 and gsdx for Final Fantasy X...

The general speed increase is 1-2%. Sometimes it's more, sometimes it's less.

A very few games benefit more, especially in case of gsdx (but then again, gsdx has other problems when doing PGO...)

AT any rate, all our betas of the pcsx2 exe already have PGO, you could just use those...

Yeah, don't expect pgo to speed up your casual games (especially ffx).

It helps on many other areas of emulation, but not so much with games fps.

Optimizations are always a good thing no matter how small they are. Today's slew of updates makes me very happy.

With rama's advice, I did a PGO build of Gsdx and PCSX2 on BOF V. After an agonizing profile session, the speedup was well worth it.

Good job.

Don't work too hard.

I found only one noticeable improvement in FFX after building PGO build: When you're on a savestate selection screen, moving between save states and some other menu items is much more responsive...

To krakatos: What do you mean saying "all our betas of the pcsx2 exe already have PGO"?.. I thought PGO is game specific somehow...

whats PGO?

playground?

PGO Profile Guided Optimization

http://forums.pcsx2.net/thread-5461.html

eliofur, that's not exactly correct. Not for a program as complex as pcsx2. Well, you can do that but it's not really worth it. What IS worth is doing PGO on a good pool of "cases"

Read here for a more detailed explanation

http://forums.pcsx2.net/thread-5503-post-36430.html#pid36430

Revision 886

T/D flag interrupting was missing on the VUs.

Nneeve implemented it :)

Revision 887

GSdx: the BoF5 speed fix

Thanks a lot :)

*eagerly awaits GT4 fix*

Gabest,it's a fix for god of war 2

Now there is no green background, there was a sphere of visibility and the condensed fog

Can to you it will be possible to continue idea

Author - ZEROx

http://www.emu-land.net/forum/index.php?action=pm;sa=send;u=14400

http://www.emu-land.net/forum/index.php?action=dlattach;topic=3834.0;attach=15719

Как смог так и перевел,не обессудьте)

cannot download it, I'm not registered there

CadeFost...

thank you gabest.works fine!

do you happen to know what causes the Tales of Legendia slowness (i think it's gsdx hardware mode based as software mode works much quicker (but not playable)))Thank you (sorry that i ask you this question via comments)

Sorry

mirrorh-http://www.rapidshare.ru/993802

X-pad doesn't want to builds:

Error 7 error C3861: 'XInputEnable': identifier not found d:\Dev\Emu\PCSX2\plugins\xpad\xpad.cpp 666

Error 8 error C3861: 'XInputEnable': identifier not found d:\Dev\Emu\PCSX2\plugins\xpad\xpad.cpp 694

Xander.S...

--------------

To zantezuken:

--------------

Apparently VS2008 installs part of the windows platform sdk v6.0A. The bad thing about this is that it includes a XInput version from september 2007, which doesn't include some features. And even if you add the DX SDK lib and include directories, VS2008 still prefers the files in the windows SDK for some reason.

SO, long story short; you need to install the latest windows platform SDK. Here it is, in .exe or web install form: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc

Revision 888

Oh well, a problem with the T/D flag code made the bios screw up.

Since it can't be fixed without further code in superVU, full revert for now :/

Revision 889

Fixed a bug from an earlier vtlb commit that caused some slowdown when INTC_HACK

was disabled. Turns out games spinning on INTC_STAT don't do it in a way that

allows the recompiler to propagate consts.

Btw, 32 bit resolution is also unneeded option -- it appeat in sources, but really does not do anything.

Oops. Sorry, miss a revision to comment :-(.

Revision 890

wxGui branch: Fixed Release build errors, removed WinMain.cpp and Remote

Debugger stuff from the build project (slowly but surely eliminating

dependencies on old code!!), and added AboutBoxDialog files, which I plan to

work on next. (gotta have an about box!)

Revision 891

Fiddle with ProcessFKeys a bit, and hack in a key to turn logging on and

off(F10).

Dev note: The extra modifier keys I put in that new struct should work, but haven't been tested much.

Also, some function keys are used with modifiers by the system. alt or control with F9-F12 have conflicts in Linux, at least under XFCE, for example.

Release Build Compile Error.

..\..\SourceLog.cpp : error C2065: 'enableLogging'

Yeah, only checked the dev build, mainly because I was testing both Windows and Linux, and it slipped through the cracks. Easily fixed.

Revision 892

Patch r891 so the release build builds.

Revision 893

Multitap should now work in BIOS (Oops).

Revision 894

wxGui branch: Finished the About Box!

oops, this is a partial commit which does NOT compile.

I'll have a compiling commit soon.

Revision 895

VU:

fixed 1-cycle branch delays

fixed an issue with FDIV instructions whose operands are vf00

EE:

fixed recompilation of SRA and SRL when shift amount is 0

fixed conditional recompilation #defines a bit

(as an aside, this fixes a crash in Ratchet and Clank, but the game has other

issues)

I glad that now you're officially in the team :P

I doubt PCSX2's ever had this many active coders, even after all these years it's still going stronger than ever. That's really nice to see.

Sweeet! One more talented developer.

alfre...

Welcome Nneeve!

Welcome!

Thanks for your good work.

Finally, you are here!

Revision 896

Fixed devel building again, assumably as jake turned the optimizations back on

that he didnt want them off.

Devel builds *should* work fine with debug information format 1 (which is a program database without edit and continue). I did a clean rebuild of devel and ran into no errors. What errors are you getting?

it was saying /Ox and /ZI are incompatible and refused to build with them on, so i turned /ZI off completely, then moaned it needed /Zi or /ZI for minimal rebuild, but the updated one puts /Zi on, its happy with that :p

Revision 897

went a bit mental lol :P

Yeah I assume a full rebuild fixed the problem on your end. :)

Whenever core target settings change it's a good idea to full rebuild (debug formats, rebuild types, linking types, etc). Usually not needed for basic project changes tho, like adding/removing files (although sometimes with incremental link enabled, removal of files from a project also requires a clean rebuild).

well VC was whining about the options :P initially it wouldnt build, so i removed the option it was complaining about, but it wanted it for minimal rebuild, just at a lower setting lol

Revision 898

Further fix for crash n burn (videos were invisible) hopefully fixes ATV too,

but i dont have it to test.

Revision 899

wxGui branch: Added the About box, and embedded images/icons into the exe.

Since images are embedded now, I moved them from the /bin folder to the

/pcsx2/resources folder.

Revision 900

Reworked the unpacking code in Vif.cpp.

I get a few warnings here:

1>..\..\Vif.cpp(435) : warning C4390: ';' : empty controlled statement found; is this the intent?

1>..\..\Vif.cpp(436) : warning C4390: ';' : empty controlled statement found; is this the intent?

I see it. That's the trouble with lots of copying and pasting. Fixed in r902.

Happy 900th commit in either case :)

That was definately needed, however the code is rarely used due to the SSE version being forced on. Can sometimes be good for debugging tho :P

This commit breaks Ape Escape 3.

SuperVUGetProgram is called with a startpc of 0xffff9e60

You tried revision 902, right? I missed two size--; in this revision that I put in there.

Yes, forgot to mention, game is still broken in r911.

Well, noticed one issue so far.

Several of the unpack functions move the data into a function of a different type before passing it to UNPACK_PART_, which assumes it's a u32.

I just changed that function to a template. Still getting the same issue, but I may be closer...

OTOH, it's passing to a function that looks for a u32 anyways, so that may not be the issue...

Looks like it's due to the change in where size is decreased. Makes very little sense to me, since as far as I can tell, the only operation being done after it is _vifRegs->offset++; , but who knows with these things.

I'd made enough changes by the point I spotted that one that it immediately went to the start screen, with no one running towards the screen, so I have to figure out what behavior I changed while doing that...

Fixed the friggin' thing by changing two pieces of preexisting code that looked wrong (That I hadn't modified in this revision). I have no idea why this worked previous to this revision.

I'm going to do a few tests before committing, and clean up the changes I've made.

See r912.

Interesting: r900 to r911 (inclusive) had the loading screen of outlaw tennis fixed, before r900 and in r912 and up - the screen has one of the loading box's corners in a different place.

Revision 901

wxGui branch: Removed some win32 platform-specific code in main.cpp.

The default paths thing is confusing. I know it's doing what I want it to for Win32, but it's unclear to me what the expected behavior for linux should be, and if it would be achieved with something #ifdef-free. Maybe GetDocumentsDir()/GetAppName() is ok on linux also?

Well, GetDocumentsDir looks like it returns the home directory, so that would probably work. I was going to suggest using GetAppDocumentsDir instead, but the fact that it returns GetDocumentsDir if the app directory doesn't exist could cause issues...

GetAppDocumentsDir returns a location on Win32 which is hidden and mostly unreachable without jumping through a lot of hoops, so it doesn't "fly" too well for things like savestates, screenshots, or memcards (but could be passable for ini files, except at the point we have everything else saved in the User Documents, might as well save the inis there also). So GetDocumentsDir is a must on Win32.

Ideally I'd like to have it optionable to use either the user documents folder (GetDocumentsDir), or act as currently and use the pcsx2 working directory -- since that's potentially convenient for testing purposes. Although really the only thing that needs to vary from sandbox to sandbox is the ini file portion (which in turn can direct pcsx2 to different memcards, plugins dirs, etc). So the question then is when to decide to load/save ini's to the pcsx2 working dir, or load/save them from the user documents dir. (perhaps that could be a function of Release vs. Devel/Debug builds? Dunno)

Also, for the record, wxWidgets places the "global" ini file in c:\windows\, which is total fail as far as I'm concerned. I'm not interested in having local and global ini settings anyway. Local only is all we need.

I'd like to have that option, too, especially since I've had requests for it on the Linux side.

I think it'd be better to have it be switchable in the program. The only trouble is figuring out how to have the program remember which setting to use. (Can't put it in the ini file, after all.)

Hmm, that might be doable actually.

The trouble with Win32 side is that the /program files folder is write-protected on Vista nowdays, so Pcsx2 needs admin access to run, and then it runs through some virtualized filesystem that grants write access to that one program only. So in order to save .ini files into /program files Pcsx2 has to be run as admin.

However, if Pcsx2 is run from outside /program files, then presumably it works, and an advanced user could then enable the alternative ini file option (which would save the ini to the program;'s working folder).

As for loading, Pcsx2 would attempt to open the .ini file in it's working folder first, and if missing or empty, fall back on the one in the Documents folder. That way, when you enable the 'working dir ini' option, it creates the ini in the working dir, and will then opt to use it from then on. :)

To clarify my incoherence: the virtualized filesystem in Vista is slow, which is why it's nice to avoid it, even if granting admin access to Pcsx2 is otherwise fairly easy. That's the primary motive for the new wxWidgets branch using /My Documents as the home folder.

(and granted it *does* make more sense from a sysadmin standpoint, since program installations and data files are always safer having a degree of separation -- makes running backups and reinstalling apps easier and safer, etc).

That and it also means that different users can have different preferences, which is a bonus.

I like doing it as a fallback, though. And the preference takes care of the remaining issue of people not knowing where their preferences went to an extent.

Other things on the new gui:

a) Should the frame limit settings actually be in the Cpu dialog, should we reshuffle things?

b) What do you think about managing the savestates through a dialog box instead of the current menus? Seems to me that we could get a bit more flexability that way...

On a), that should be "*or* should we reshuffle things?". Like having one central preferences dialog, moving it to adavanced, giving it it's own dialog box, etc...

On a) I've already alloted a menu option under "Video" for it. The Video menu will have a section of Pcsx2-side options (MTGS / Frameskip) and then whatever the GS plugin programs into it through the future plugin API for adding menu items to the gui. :)

On b) I'm kind of impartial since I don't really use the menu option much. Although a dialog does sound nicer, since it could, for example, sort the savestates by timestamp for the user (which would be useful indeed).

Well, as plugin api changes, remember, the future is now. Feel free to make whatever changes you want to the new api files in common (common/include/Pcsx2*.h, PluginCallbacks.h, and the api folder). ChickenLiver's already made a bunch of changes to the plugin api.

Reminds me; if we're going to do anything with Pcsx2 sending iso file names to the cdrom plugin to load, we should put the hooks in now...

As far as the dialog goes, I was thinking ability to delete saveslots, copy them to other slots, import them from external files, export them, and assign labels to the save slots.

Timestamps is a good idea. And if we were feeling really ambitious, send a snapshot message to the GS plugin if saved from the keyboard, and give thumbnail images of the screen.

Revision 902

Fix typo in r900.

Revision 903

pcsx2:

- removed some obsolete 'iCWstate' code.

microVU:

- implemented more rec first pass stuff for the lower instructions.

this change log is so simple.....

Cottonvibes commit legacy grows! He has uncovered the profoundness of simplicity in his latest commit log!

If you ask me, the last two comments were way too simple. If you're going to make completely pointless comments, at least use complex sentences!

Revision 904

Assorted cleanup. A few compilation errors went away, a few useless variables

are gone, a few if statements are now case statements. Added comments on a few

potential problem areas.

Well this is going to be a fun one to merge with the wxGui branch. ;)

(the swath-like changes to misc.cpp will conflict heavily with the wxString modifications I had to make on the wxGui side -- so likely some of the formatting changes will be lost when I do the merge)

With Main.cpp, it's mainly that I copied back in ProcessFKeys from r891, and changed it just enough to have the changes in r891 work, losing the formatting changes I had made (as well as a bug that had crept in somewhere).

Misc.cpp, I mean.

I'm doing my merge now, and I just realized that Misc.cpp is completely butchered. :/ All the tabs were removed and replaced with spaces, and it was expanded to 8-character tabs. So nothing lines up at all anymore. :(

Also, look at vssprintf.cpp -- A single line change where it added a space to the while loop semicolon (yay?), and then removed the tab and replaced it with spaces. (sigh)

I assume this is that util you mentioned doing these oddball things. In any case I think I'm going to revert Misc.cpp. It's totally fuxored in its current state. :(

Actually, didn't use that utility at all this commit.

The space was just me getting rid of a silly compiler warning. No idea how the tab turned into spaces, though. I normally do the reverse.

With Misc.cpp, the problem is probably that I copied it straight from browsing r891 on the google code website.

Revision 905

wxGui branch: Did some heavy work on the configuration/ini stuff.

Just to check, is wxgui compilable on Windows right now?

Or does it give you lots and lots of errors about wxStrings?

Just curious whether it's just Linux that's broken at the moment...

It works fine here. I removed several files from the Win32 build, though. WinMain.cpp, for example (I moved the Languages part at the bottom to another file temporarily since I still had dependencies on that code). I'll be removing a lot more shortly.

All right.

Just wondering, because on my side, the exception code is refusing to compile unless I wrap every string even remotely related to it in wxT, change c_str()'s to mb_str()'s, and format_string to wxString::Format.

And at that, I still haven't gotten it to compile.

ugh. That doesn't sound too promising.

There are platform inconsistencies in how wxString converts to and from std::string, and we're going to have to resolve the precise behavior in order to come up with a neat solution that satisfies both Windows and Linux/GCC. Clearly on Windows, the conversions are working pretty well (at least to now -- I'm still not to the point where I can enable unicode here). Maybe once I get to that point, the code will compile more consistently.

You know, it occurs to me; I'm using the unicode version. I bet that that's why it's still compiling properly on your side...

Revision 906

Fixed a simple bug from one of arcum42's cleanups.

Cleaned up multitap code a little in both PCSX2 and LilyPad.

Some extra safety checks in LilyPad when loading state.

BaseblockEx.h was checking if id was -1 and then using it directly as an index in a vector. Returned -1 regardless of how things turned out, but still...just not a good idea.

Just to be clear, not meant as a criticism of arcum or his cleanups. Looks like the code could really use it. (And that should be idx, not id).

Yeah, if I'd noticed that the -1 matched the index, I'd have done the parenthesis differently. I wasn't absolutely sure at the time; that's why I left the comment there.

Everything was running properly in the games I checked, but I'm always amazed how much you can break in pcsx2 and still run things.

And no offense taken. Part of why I committed when I did was that I felt that if I kept going with the cleanup, I was sure to break something, and I didn't want to start from scratch when it did. (Which has happened in the past)

And, yeah, cleaning up the code's been an ongoing mission for quite some time of mine, though the Linux port takes priority. I remember doing several cleaning passes back in playground, too, mainly based on compiler warnings...

Revision 907

wxGui branch: Removed several unneeded files from the Win32 builds (removing

them since I can reference them from trunk, and if they're deleted I won't have

to spend time merging possible changes and stuff later).

Revision 908

wxGui branch: Merged with trunk up to r903, and resolved some Win32

compilation/link errors.

Revision 909

wxGui branch: Finished merge, and added a new wxConfig28 project file that

allows the wxCore and wxBase libraries to compile in parallel on multi-core

CPUs.

There always been some annoying glitch on the main window... Some kind of border around logo (image) containing last state of the screen... It doesn't refresh correctly... I didn't tried it on Vista, but on XP it was always there...

Revision 910

Found a small typo in IPU, don't know what videos it will effect, but it could

have potentially stopped them working :P

It was first appeared in r601. No, I seen no troubles around r601.

Using 64 bit accesses for the command bits of most hardware registers is technically invalid (I think there's a couple GS exceptions, and the 128-bit FIFO of course). So chances are the 64 bit IPU writes are never used, or used once by something but in a non-important manner the the PS2 itself might in fact ignore.

That is, that would be an explanation why it didn't appear to break anything. :)

probably the case, but id rather not have the bug there just in case xD

Revision 911

Revered Misc.cpp and vssprintf.cpp from r904. See r904 comments for details.

Also, I removed some options from the .vcproj, but these should have *no effect* -- they were just duplicating defaults assigned by the IncrementalLinking property sheet. I'm trying to keep the projects as dependent on property sheets as possible, since it ensures pcsx2 and most plugins have consistent settings across build targets.

Revision 912

Fix the breakage on Ape Escape 3 from r900. Clean up the unpacking code some

more while I'm at it.

In UNPACK_V2_32, it was passing 0 instead of data for W. I have no idea why, and removing that, and a const that probably shouldn't have been a const did it.

Hopefully this didn't break anything else, but if it did, I'll hunt around in this code again.

I probebly will mess with this code again. After all, if I templated UNPACK_V1 - UNPACK_V5, all those other functions are mostly extraneous...

Sent you code explaining why it did that.

Thanks.

Wonder how accurate it is right now. I was tempted just to revert it back, but I really didn't like leaving those defines there...

For the record, neither not writing a 0(the code in this revision) nor writing a 0 in that function(the code before I reworked it) were correct. It only writes a 0 there at certain times (at the end of a 64 bit block). That's what r916 was about...

Revision 913

Implemented another block lookup method.

Fixed an unused instruction in the emitter.

Yay my awesome emitter contribution! Woe is my copy/paste jobbing!

Revision 914

LilyPad: Fixed "Swap with Pad 1"

Vibrations are not present now

Nothing in this change should affect force feedback. When I added multitap support, did make a change that would destroy old force feedback vibrations, but that was well over a week ago...

Vibration bindings, that is.

Revision 915

microVU: more recompiler first-pass implementation stuff...

Kudos for making consistent updates to this. When do you suppose this will finally go live?

it won't "go live" till krakatos and the rest of the beta testers thoroughly test it and its more compatible than the current vu recs.

but if you're asking when its going to be 'usable', probably in 1~2 months.

it would be sooner if i didn't have school+work+boredom dragging me down :(

also every time i think i'm almost done with it, i realize there's some complex problems that have to be solved/implemented.

its pretty annoying TBH, i'm past the 'fun' part of coding this thing, and its more the 'annoying and hard' part right now...

anyways, i don't want all my work to be in-vain, so that's my motivation for finishing this thing xD

I look forward to testing the finished code :)

xat...

If you don't mind my asking, what is the idea behind microVU?

"more compatible than the current vu recs"

I like the explain rather than the change log :P

more compatible and multi thread aware i think

lutfime2...

see this...

http://cottonvibes.blogspot.com/2009/03/what-is-microvu.html#comments

keb...

nice reading, at least now i understand more of the crazy talk in the changelogs

Revision 916

Did some testing on the V3_# unpacks, they do some strange stuff for what goes

in the W vector every 6qw of original data. Also fixed the use of the size

variable so Xmen works again.

Note: Nobody will notice this as SSE unpacks are forced on (for now)

wisestud...

GRADIUS 5 and some other game is broken since rev 912。Anyone can fix it?

i haven't looked at the code in detail, but in this function:

static void _UNPACKpart(u32 offnum, u32 &x, T y, int size)

you removed the ampersand in "int &size"

but later on it does:

size--;

so either the 'int &size' was correct before, or the 'size--;' should be omitted (since the variable isn't used again)

Well, I know before what it was doing was checking if size was less then 0 each time, and decreasing it, so that if it ran out of data to unpack, it wouldn't keep unpacking. (though I'm not sure that's actually needed.).

Though that probably should have been <= 0, thinking about it. But that's why it was a reference before. I was basically carrying over what it was doing with size before the rewrite, trying to keep the code as close as possible to the way the defines used to be set up.

So unless that isn't needed, it should be a reference. For that matter, we probably need to set up the SSE Unpacking functions to handle W properly on V3 now, too...

the problem was, because it was a pointer to the size variable (rather than passing it), once size was zero i was doing the check and Ape Escape would crash again, some games only have say half the packet left over so it might do 1 or 2 vectors, so it would do that once or twice, size would become 0, then try and do it again and crash because "size" doesnt exist (VS quirk? maybe) but this also effected XMen as it has 2 vectors to write at the end of each packet, so without the size check it would write 2 vectors of crap then start in the wrong place with the new packet.

wisestudiodev: Ill have a look at that tonight, i think i have a Gradius V dump, if not ill hunt one down ;p

wisestud...

Thx refraction;)

Revision 917

Emitter renovations of a large scale sort (only up to phase 1). Intel's 'group

1' instructions now use a completely new ModRM/SIB encoder, along with a nicely

object-oriented interface. I created some macros to retain backward compat for

now, and will continue implementing the rest of the instructions later as I have

time.

Also: Removed x86/64 instructions from the emitter.

Sorry, where WriteRmOffset defined? It used in ix86.cpp:442, and I see you remove this function from header.

And gcc disallow to wrote (ix86.cpp:45):

const x86IndexerType ptr;

without initialization. I comment this line, and it's compile and run.But maybe you want to made initialization?

WriteRmOffset used in ix86.inl, not in cpp.

hm, but why not just use xbyak? :P

Revision 918

Linux compiles again. Added back in potentially obsolete code, since it's still

called.

Where were you getting the const error?

The const should be added to a function (or more), and not removed from the variable, preferrably.

This is a problem with how MSVC and GCC differ in template code handling. Msvc doesn't parse templated code unless it's referenced. GCC does. So GCC picks up errors that don't exist on msvc for unfinished code (annoying).

ok, I checked and I can find no reason that value shouldn't be const. Can you poaste her the errors you get when it's const, so I can figure out why GCC's being annoying again?

This value could be const -- it could not be uninitialized.

Right; the error is because you didn't set it to equal anything in ix86.cpp. A const, by definition, can only be initialized once, when you create it, and if it's not initialized, it's value is undefined for the rest of the program. And gcc is not willing to let you get away with this.

It's *supposed* to run the default contructor. I'll just add an explicit constructor, even though it's not supposed to be necessary. Whatever. >_<

I've uploaded a patch into Issue 139 for trial. Check the description for details.

Revision 919

Switched the emitter over to using Thread-Local storage (TLS), which removes all

the templates and brings us back to a more traditional-looking, macro-free, and

intellisense-friendly implementation. Plus it's a lot less prone to errors and

will make debugging easier down the road. (next commit will rename the files

back to .cpp and get them out of the header includes)

Revision 920

couple of changes, very minor speedup

Revision 921

Reverted the emitter back to a c/cpp form from inl files (probably wasn't

necessary, but I don't like having code in header/inl files when I can help it).

Also:

* Fixed a couple potential bugs in some Rm forms of MMX instructions.

* Improved compilation times by isolating BaseBlockEx.h to the files the needed

it (it uses STL junks).

* Removed some dead code form emitters and BaseBlockEx.

Revision 922

Implemented the 16 bit forms of Group 1 instructions into the new emitter.

Revision 923

More updates to the new emitter: switched over some Push/Pop instructions, did a

fully compliant implementation of LEa (both 16 and 32!), and fixed a couple

small bugs in the ModRM/Sib encoder regarding EBP as an [index*scale] formation.

Revision 924

microVU:

-fixed rm instructions to work with Jake's emitter changes

-implemented the case where upper and lower instructions write to same reg at

once (the lower instruction's result is discarded)

-implemented more first pass analyzing stuff

-fixed various bugs...

Hope you will make it alive some day...

BTW... What I have to do to enable that "buggy, laggy, incomplete and all that stuff" microVU recompiler instead of zero's?.. I've uncommented that define in pcsx2config.h, but I can't see any difference in speed or compatability in games I have... The only thing that changes is executable's size... What I did wrong?.. I expected bugs and crashes... :-)

PC: Nice graph here: http://pics.livejournal.com/eliot_cougar/pic/000bh99y

uh, it's still not working at all...

eliotfur:

if you were to enable microVU recs fully now you'd just get a crash or something as soon as you try to run the game.

its incomplete so nothing works ;p

its like trying to drive a car with no engine xD

Ah!.. I found your ifndef PCSX2_MICROVU_ stuff (with underscore) in two files...

I've got the crash now, and I'm satisfied... =^.^=

Good luck and a lot of patience to you in your challenge...

Revision 925

Fix Linux again (and again and again and again...)

Revision 926

backing up some changes

Revision 927

Disabled a VU recompiler option that caused some SPS in Ratchet and Clank and

didn't actually affect speed.

Modified VU stalling logic of MR32 and MTIR instructions and modified FDIV

stalling.

Actually it brings slow downs in MGS3 for example, is there anyway to fix it with rec enabled

Sorry it was my fault

Revision 928

Fixed Gradius V, had to destroy the templates arcum did a bit to get it to work

without ape escape crashing (sorry mate lol. Took out my V3_# discovery, ape

escape is getting spikey now, so ill just remove it. Also altered V2_# to work

slightly different incase the packet starts on the Y vector, it now wont suffer

underrunning (possible bad data)

That's all right, I know how delicate that area of code is. If you send me a dump of Gradius V, I'll see if I can clean it up without breaking Gradius V during the weekend...

Something to note :

r900 to r911 (inclusive) had the loading screen of outlaw tennis fixed, before r900 and in r912 and up (this revision inclusive) - the screen has one of the loading box's corners in a different place.

Can you put a dump up somewhere for me Nneeve? either post me a link on the forum or put it on here, either way :)

And if you could pass that along to me as well, that'd be great. I'm starting a collection. :)

Dump: http://senduit.com/54aaec

fixed it, dont know HOW r900 to r911 fixed it, wasnt even in that file! lol

anyhow ill update in a bit

Revision 929

LilyPad: Small/large motor defaults should work for most devices, when creating

new effect bindings.

Keyboard queue fixed up a bit, mainly to favor escape down when PCSX2 is dying.

Fix for ignore bindings being swapped with the swap pad bindings buttons.

Updated version number, thinking of releasing soon. No known bugs, not that

much more to do.

Revision 930

LilyPad: Debug line removed.

No, the last updated did not magically give anyone an invisible XBox 360 controller, contrary to what the device list showed.

xD

Revision 931

More Vif Unpacking cleanup. (And probably not the last of it.)

Revision 932

[No log message]

Gota love how the log message got lost in the way eh ?

------------------------------------------------------

branched for vtlb-rewrite code merge.This is not a rewrite of vtlb, its support for vtlb to rewrite the code on the fly.

Interesting feature, but I could not imagine where could it be used. Maybe you've got an example?

This will be only for windows ...

Revision 933

Fixed Outlaw Tennis error on the loading bar, as a strange side effect, this

fixes the missing textures in Crash N Burn too. What is more annoying is this

code use to be in the emulator ages ago (before processing skipping) and it was

removed as we didn't think it actually had a use! :D

I hoped this commit fixed missing textures in "Crash: Mind Over Mutant" too... Seems that it's not... (r942)

Revision 934

--This breaks linux.

--Basic vtlb code rewrite for full mapping using exceptions

--This is buggy & leaks ram for now

Also, P will reset the dynarec cache.

It has been reported it randomly generates cookies, but i'm not too sure about that

nice

It seems like EVERY more or less important part of a code will be rewritten from scratch. wxgui, VU, the interpreter, vtlb, EERec...

Playground merging was best event in project history!

Revision 935

The last changes to clean up Vif wouldn't have worked in some situations, tried

to rearrange it and space things out and skipping unnecessary checks

Fixes Tekken5 and seems to be a good bit faster, too ;)

Yep. Nice work optimising things. I was going to work on that after my last commit, but was too tired...

make sure you get r937, i missed some rather important code.. lol

Revision 936

--No longer uses 2 hacks/buffers, it just stores the info needed to generate the

memops directly on the code

Good work!

Revision 937

Slap my wrists for the silliest error ever :p only thing that gave it away was

the sirens on top of the heads in Ape Escape 3 had no light lol

Yeah, that would make a difference... :)

so will the next commit lol

Revision 938

last silly mistake, promise :P

As long as I get equal chances to break Vif in silly ways... :)

of course :p

Revision 939

Yes, more Vif work. writeX, writeY, writeZ, and writeW are all merged into one

function.

GJ, might be worth setting the rowreg back only when its added to tho, no point in it setting it every time :)

Good point. My original design for the function turned r0-r3 & c0-c3 into arrays, and after deciding that wasn't going to work, I had to improvise a bit...

Revision 940

More unpack changes, tried to simplify a few sums a bit when processing skipping

and a few other misc bits

Looks good. Shame 0xC does something different in that first case statement. Otherwise, I'd pull

vif->tag.addr += (size / unpack->gsize) * 16;

out of it, and make the case statement only happen in the developer build...

well i was going to make them all do that, as C will come out with the same result if i use the complex equasion or the simple one, but i chose speed over cleanness

Understandable...

Revision 941

A few tweaks to the unpacking code. _UNPACKPart isn't really neccessary anymore,

and optimised writeXYZW a little.

These last unpack changes are starting to make a real difference in speed.

Keep doing these ;)

But please check Tekken5 from time to time, too!

This is the second time it breaks due to vif unpack changes :p

http://img3.imagebanana.com/view/rzerym0v/Unbenannt.jpg

Not sure how many more optimisations there are to be made here, but we'll see. :)

As far as Tekken 5, do you have a dump with the issue?

Nope, sorry.

Tekken5 dumps are hard to make, since the opponents are random.

Refraction has this game though, and since you're both coding on this part of the emu atm, maybe he can fix it?

We'll see i guess :p

Yeah, he fixed the last one, so he'll probably be able to fix this one too.

And my collection of games is heavily RPG-oriented, so I don't have Tekken around...

Looks like Vif.cpp now has about 200 less lines then when I started the unpacking cleanups, too, which is always nice.

BTW, did Tekken 5 break on this revision, or one of the earlier ones?

This one, I'm fairly sure.

Didn't do a full test, but it's either this or the const one (rev942).

Heavy SPS and stuff make me think it's this here ;)

Probably. You might try changing:

dest = setVifRowRegs(offnum, vifRowReg + data);

to:

vifRowReg += data;

dest = vifRowReg;

setVifRowRegs(offnum, vifRowReg);

or:

dest = getVifColRegs((_vif->cl > 2) ? 3 : _vif->cl);

to

if (_vif->cl > 2)

dest = getVifColRegs(3);

else

dest = getVifColRegs(_vif->cl);

The other changes would be harder to check...

This causes SPS in Tekken5

Read the conversation right above your comment.

Revision 942

Take care of Issue 139 .

Revision 943

GSdx: this should probably fix taking snapshots with dx9, also upped the version

to .15, since the revision number has passed what the last release still had

from the old repository.

CComPtr<IDirect3DResource9> res = m_surface;

if(CComQIPtr<IDirect3DSurface9> surface = res)

{

...

}

operator = calls QueryInterface (for IDirect3DSurface9) on res, but that returns NULL...

D3D objects were always a bit broken, COM-wise.

BrunOzMendes

broke tekken 5

Nope, Tekken5 broke earlier. Please test a bit better before reporting breakage.

You guys make us work uselessly with these false reports!

[email protected]

And anything that on old gsdx the problem remains? Think at a leisure

2gabest11

Where a fix for gow2?

[email protected] T5 is not caused by gsdx

Gabest, i'm just interesting i've uplosded GoW2 without green, is it helpfull to solve the problem?

can't fix gow2, not just the green overlay is the problem, much earlier at the beginning of the frame it clears the z buffer by setting it as the render target and painting it black, that will never work in d3d.

benc...

Fix for GOW2.

Index: plugins/GSdx/GSState.cpp

===================================================================

--- plugins/GSdx/GSState.cpp

if(GSUtil::HasSharedBits(fi.FBP, fi.FPSM, fi.TBP0, fi.TPSM))

{

//skip = 1;

skip = 3;

}

but what about half of the missing geometry because of the uncleared z buffer?

http://guliverkli.sf.net/gow2sw.jpg

http://guliverkli.sf.net/gow2hw.jpg

Wasn't GoW1 suffered same problem before it was fixed or it was just green?

Anyway if change second part of GoWfix code

else if(fi.FBP ==0x0000 && fi.FPSM ==smth && fi.TBP0 ==0x0000 && fi.TPSM ==smth)

{

skip = 1;

}

to

else if(GSUtil::HasSharedBits(fi.FBP, fi.FPSM, fi.TBP0, fi.TPSM))

{

skip = 3;

}

background textures this srange wall sometimes will go out it makes other bugs but it much more chances to complete game in HW now *i almost complete game with this code*

smth = just don't remember what was writeh there

Revision 944

Fix for one small bug, doesnt fix tekken 5 tho :(

Now that's interesting.

This mistake dates back to the last commit that you fixed Tekken 5 on. :)

yeh, i fixed it, then you missed it again when you did your changes, so i put it in again :P

Revision 945

Why this broke Tekken 5 i don't know! (answers on a postcard) anyhow, fixed :)

The only explination i have is the double break caused by jNODEFAULT was causing some of the while loops (like on UNPACK_V4) to break before they had actually written any data. Tekken tends to mask everything but say Y, so it'll go to write X, break (because its masked) not write anything else.

Other than that, im baffled

Well, that's the last thing I would have expected to break it.

Wonder what the value of n is in Tekken?

back to normall again)

Or I suppose it could be the double breaks. That's bizzarre, though.

I think the problem is the double breaks, some how it confused the compiler with the while loops we've used while it "optimized" the code.

You're probably right. If it was an issue with n, it should have asserted, not just looked bad...

Revision 946

Fixed recently discovered bug from VIF which could have potentially happened

anywhere jNODEFAULT is used (nobody noticed lol)

Probably a good idea, since break seems to be used before jNO_DEFAULT in 90% on the code...

Tekken 5 back to normal, thanx :)

Revision 947

Fixed alignment problems noticed in Digital Devil Saga

OMG, no more ghosting! Thanks a lot Ref. ;)

Revision 948

microVU:

- added microVU_Execution.inl

- dispatcher stuff is now recompiled with pcsx2's emitter instead of using

inline asm, its cleaner than inline asm and its more portable since the asm

won't have to be ported to GCC.

- lots of first-pass implementation for lower opcodes

- implemented documented branch behavior (first pass stuff only)

Note: theres some undocumented stuff branches do according to Nneeve's tests,

but i won't implement those for now since 99% of games shouldn't need it, and

according to the tests, the behavior seems kind-of random/erratic.

Revision 949

forgot to add microVU_Execution.inl in the last commit xD

This commit made a new linux issue, and the strange one, Drakan the Ancient gates start to freeze at random points. I was unable to obtain this issue on windows, and no other game was touched yet, so I still searching the correct testcase.

This was a microVU commit: no active code currently. Last commit that could have affected things would have been 947...

Revision 950

GSdx: GoW2 fix, 16 bit drawing that caused the green overlay is skipped

(character shadow)

As always, since it's based on one single .gs, there might be other parts of the game that still have errors.

Thanks a lot Gabest.

I wish I knew how to program this.

Thanks Gabest, i think issue 30 can be closed now

Nopes, it's a CRC fix again ;( Only NTSC games affected ;(

Yea, the Green screen it's there in Pal version.

MadRabbi...

SCES_54206 CRC=44A8A22A include, but not working.

Revision 951

--BTS r/m+r added for emitter

--Uses BTS + bit arrays for manual block tracking, instead of full

invalidation.It makes some games much much faster and doesn't seem to affect he

rest (still, testing is needed).Okami that uses some sort of SMC works .. but

i'm sure there are some bugs left in it

Speeds up FFX from 300 to 400fps, dragon quest 8 menus are 10% faster.

Seems to slow down all the other games a bit though :p

How much slow ?

Scratch the getting slower part. I forgot that 912 is quite slow to begin with :p

Also: Kingdom Hearts 2 and Odin Sphere got a good bit faster (20% for odin sphere!)

Finding more games that speed up :)

One game got slower though, and thats suikoden5.

It was the worst case example for the old tlb build, vm beeing 100% faster in menus.

The game used to hammer the exception filter. I bet it still does that..

nice work and good news

rama, I think you only have one game: tekken 5 :P

ny11...

I was excited to test this,but it broke Virtua Fighter 4 Evolution.

this is my 1st comment btw

=)

GREGORIO...

There are some sps in Resident evil 4 Pal in latest build,i think it's because of this changes

xat...

Odin Sphere's faster though there's still a massive slowdown during blended particles (i.e. very end of the intro). Probably gsdx related though?

Gregorio: These changes arent even part of the main branch.

hrydg...

BTS? Isn't that one of those old clunky instructions that run on microcode, far outside the fast path of modern CPUs?

hrydg...

scratch that comment. it's fast in its reg to reg form, on Core2 at least.

Revision 952

GSdx: GoW2 fix #2, pal version this time

Hah ! You're the man ! You're the man ! Thanks a bunch ! :D

darrenk...

Outstanding, Gabest! Any chance you could take a look at issue 23 so we could actually finish GOW1? ;-)

Is that a gsdx issue? How could I repro it without actually playing it through? At what point of the game does it happen?

darrenk...

Not sure, but if the posts in issue 23 are any indication it definitely sounds like it's related to gsdx. See details in issue 23 . Someone posted a block dump there if it helps.

It happens immediately prior to the final battle with Aries and makes completing it impossible. Shame too, since everything right up to that point works just fine.

Revision 953

more microVU stuff...

Revision 954

Fixed bug from Issue 144 .

all your commits is one same file :P

thats because im workign on the same file and this gives good bug tracability

Good job, as usual :) Thumbs up! I hope that VP2 will be playable soon :P

Revision 955

Optimized and split up the unpack call a bit so less checks are being run,

should bring an overall speed increase. Also got rid of some duplicate pointer

rubbish which was all over the place.

You missed a _vifCol[1], and it's not affecting things. In fact, searching, I don't see anywhere vifCol is being used. :)

Except aVif.asm, anyways, and since none of the variables were changed there, I'm assuming that code is dead.

[1] Vif.h, line 87.

dont know if its used or not, youre rigth tho i did miss it :P but it was never allocated to in vif anywhere, so i presumed it was done elsewhere if it is used

second thoughts, some how much find and replace in entire solution just missed it :O

Well, I just deleted where vifCol is defined and the extern, and the compiler didn't complain at all and everything ran. I'd presume it's unused, and can be gotten rid of. I sertainly didn't see any uses when I did a search on the whole project...

possibly none then :P

Revision 956

Look over there! A THREE HEADED MONKEY!

regi...

Guybrush Threepwood :D

Oo this is the second biggest monkey head i've ever seen XD

Haha :) Cool

ny11...

A bit faster and virtua fighter 4 evo works again.

=D

Thanks

Haven't you used that commit comment before?

Not that I'll ever object to Monkey Island. I'm probably one of the only people that's downloaded the ScummVm ps2 port, and tried running it on pcsx2... :)

hey it worked the first time, didnt think itd hurt trying the same comment twice :p

Yeah, that's true...

Wow, it's again! :P

Oh you commit code like a dairy farmer.

Three headed even lol

gabest11: how appropriate, you code like a cow!

I'm shaking, I'm shaking

I'm rubber, you're glue!

Wow, you're good enough to fight the Sourcemaster!

Have i passed the three compilers?

Let's see... Visual C++, GCC, and ICC.

I know this commit passes the first two; not sure on the third. :)

oh bum :(

Revision 957

--updated to r956

--uses test8 instead of test32 when possible

--exception handling checks are a bit more strict

Revision 958

resolves Issue 143 Altered Beast

don't you need rest ??

rest is for the weak :p

luizhgar...

refraction is not human, that's why "it" doesn't rest. Just kidding, awesome job!

Hey Refraction, since you are on a rampage, take a look at issue 152 . See if you can do anything about it man. :) Thanks my man. Keep up drinking the energetics :D

dhalaila: Not with that amount of information no :P when did it break, did it ever work, what revision did it break on (if known) and a blockdump, all this info would be useful

Revision 959

microVU: fried my brain with some very-complex VU flag-handling logic/algorithms

(hopefully they work as expected)

hmm, seems they still need some work...

Revision 960

microVU: more flag stuff (div/sqrt/rsqrt flags set at proper time)

forgot to report that 956 broke Castlevania: Curse of Darkness at the save points. Is that fixed here?

cottonvibes' changes will never fix anygame unless he ( or she :P ) release microVU

He.

He is HE :)

http://www.blogger.com/profile/15542648017139504620

Revision 961

Fix for MGS3 corruption from r955, i don't know why but where vifRegs was set

previously, it was completely ignored, regardless of the fact the code has run

through there before doing anything else O_o

Wow that was fast i just want to report and you already fixed it, thanks

Damn you're unstopeable :D. Hey Ref, I posted the block dump you asked for issue 152 .

Have you tried Castlevania Curse Of Darknes break at the save points? Just wondering :)

amazing work !

Revision 962

GSdx: GoW2, try #3

Junrgao, are you the Positive man ? Heheh.. Huh... What this revision does for GOW2 ??

you try delete the gsdx directory and re-download the code, maybe the revision number is correct. I don't care the revision number and only pay attention to the changes :P

He changed skip from 30 to 29, I really don't know why he did it, but it should fix something

http://forums.pcsx2.net/thread-3031-post-39743.html#pid39743

This fix works for my NTSC version but someone told me that PAL still requires 30

Pal's fine now

Revision 963

SPU2-X:

Worked on savestate support a bit. It now remembers an update timing variable

more (could fix a few crashes).

This increases the savestate version though, so make sure you have a memory card

save ready before upgrading!

Also implemented a way of delaying audio output after loading states. This masks

the ugly noise that some games produce directly after loading, keeping your

valuable speakers intact :p

Btw, if for some reason you want to keep using your older savestates...

static const u32 SAVE_VERSION = 0x0005; << change it back to 0x0004.

It will most likely work still :p

Revision 964

Added a check to to clear QWC register if the upper 16bits are set. This fixes

most of the broken backgrounds in movies.

Grande pibe!!! Igual el commit groso es el otro :P

Revision 965

Added a check to to clear QWC register if the upper 16bits are set. This fixes

most of the broken backgrounds in movies.

Hmmm nice... Does that means it fixes movies like this one?

http://img25.imageshack.us/img25/56/dq8001.jpg

pcsx2gu...

Fixed Star Ocean 3 videos :)

Awesome ;)

Yep, Tri-Ace games fmv got fixed. GUST games split backgrounds as well.

Great stuff :)

You really see movie? I saw only first several frames of staring video of SO3, and then it seems FMV's freeze (but start button is working).

Beautiful. I had Windows up for something else, and probably won't have time to reboot and look at it in Linux tonight (I just got home, and I'm getting ready for bed), but the opening movie in Star Ocean looks shaky but is there (past a few frames), and spots that I know had split screens in Atelier Iris 1 & 3 & Mana Khemia all look normal. ( The Atelier Iris 1 tutorial, for example, or Mana Khemia's opening screen)

Looked a little odd to me, actually, because I've gotten so used to how it looks broken. :)

I even tried Star Ocean in the Windows version of ZZ OGL, with no issues....

On the FMV, at least.

Yep, tri-ace fmv all work now.

I've had them working to some extend with a hack, but that one would freeze somewhere around half of the intro fmv.

At this spot this version here continues, but it has a fraction of garbage.

Revision 966

microVU: changed flag handling algorithms some more...

Revision 967

microVU: minor changes...

:) BTW the graphical bug in VF4 evo in their life bars is gone under DX10 :) Great stuff...!

pcsx2gu...

You do realize that microVU is not used yet so these changes you are reporting are not due to these microVU commits right? :P

Exactly. ^

Revision 968

SPU2-X:

Small cleanup and made it a bit faster.

Revision 969

fixed a minor bug from saqib's earlier commit

Revision 970

microVU: bug fixes on some flag handling stuff.

Revision 971

Many Emitter updates:

* added implementations for MOV and Shift instructions (SHL, SHR, ROL, ROR,

etc).

* Improved compilation optimization considerably, by improving inlining

selection in cases where constant propagation can be resolved reliably.

* Moved lots of code around, so that the new emitter and the legacy emitter are

more clearly separated; and renamed some vars.

* Changed recompilers to initialize the recBlocks array to 0xcc instead of 0xcd

(fills the blocks with the single-byte instruction INT3, which fixes the

misalignment mess that would sometimes happen when using disasm views on the

RecBlocks contents).

* Switched back to /O2 (Optimize for Speed) instead of /Ox, since MSVC (for me)

generally fails to optimize Thread-Local storage in /Ox mode.

xat...

What are the emitters for in terms of their placement in ps2 emulation?

xatnys: https://code.google.com/p/pcsx2/wiki/RevisionReviewEtiquette

I dont see what was wrong with his question. He was asking where on an actual ps2 those emitters were used (or thats how I interpreted his question anyway). Which isn`t a insulting question, but one of curiosity.

pcsx2 'recompiles' the ps2's code into x86 code your PC can read.

the emitter is a bunch of functions that are used to write the x86 code that your PC will read.

so basically, the nicer the emitter is, the nicer it is to write new rec-code.

there are also some optimizations you can do at the emitter-level to speed stuff up, but mostly the change will just be for cleaner/nicer code.

Maybe it would be better to drop Linux build? Because this update got all bunch of c++ stuff, that gcc does not like: uninitialized constants, extern declaration of variables after usage, well, if it compilled under VS, that I am an elephant.

hockl: It's irrelevant, idle curiousity that serves no real purpose here. As the page says, this is not a forum. Intended for useful comments on individual revisions for the devs, not idle questions of end users.

Arcum42: If you have some complex errors, please post them to a new issue. I'll help resolve them from there. I had to do some code juggling to get MSVC to optimize things in an intelligent manner, and I'd like to retain that if possible, which means moving code around to fix GCC needs to be done with some measure of forethought.

Maybe this would be a good time for me to try that ubuntu-under-windows thing so I can do some GCC compilations.

Haven't had a chance to test it yet, and I've got to fix up my copy of X Windows a bit before compiling, because I messed up a few config files during an update. Think I just need to tell it what windows manager to use again, though.

And it looks like Zeydlitz already has the neccessary changes in issue 156 , so I'd look at that, and we'll use that issue for the moment...

Got X Windows working. Since I updated the nvidia drivers doing that, I'm getting my 32 bit chroot in sync before looking at compilating issues, though.

Revision 972

microVU: more flag "stuff" xD

<JakeStine>cotton: your commits always contain "stuff"

<JakeStine>I think you should rename one of your files to "microVU_stuff"

<Dwarg>And maybe others called "microVU_junk" and "microVU_crap"

<Dwarg>Then you could be much clearer

<Dwarg>"Fixed some junk, broke some crap, added some stuff...."

<JakeStine>lol

<cotton>lol

lol :)

Ha ha ha ha!!!

hahaha :D

if the prophet doesn't want to come to the mountain....

kabooz: what does that mean? :p

cotton: there is a saying "if the prophet doesn't come to the mountain, the mountain has to come to the prophet"

meaning if you have not the enviroment to play minigolf for example, then just create it yourself XD

basically what jake and chickenliver proposed XD

ah and the saying is based on moses climbing the mountain sinai

i see, i hadn't heard that saying before ;p

Revision 973

got the okay from Saqib to delete the obsolete pcsx2v2 branch (old attempt to

convert pcsx2 to c++)

Revision 974

Fixed a bug in the Emitter the caused the VU1 to screw up a bit (bad gfx and

freezeups and stuff). Also: Resolved some GCC/C++ troubles.

I'm wondering, all these emitter updates as of late, are they for improving the quality of the emitter's code, improving the quality of the code it generates, or both?

Revision 975

LilyPad: Changed how device updates are handled to be more multithreaded

friendly. Mutexes when "read input in GS thread" is disabled removed, as they

should (hopefully) no longer be needed. May just ditch the option entirely in

the future, since enabling it doesn't seem to make much difference, and slows

things down for some people.

Revision 976

Linux: Fix the Makefile.

Is linux compiling ok now?

It does for me...

Revision 977

Port 2 Multitap should be fixed (PCSX2 bug).

Revision 978

Cleaned a few things up, and moved a few things around.

As a dev note, most of the spr0->qwc = 0; and spr1->qwc = 0; lines that were removed were removed because the variable in question would already be 0 at that point...

Revision 979

Some work on Vif & Hw.

By the way, all of those labels you changed from numbers to constants is #ifdef'd out (more unused reference code). Although the 'bad' news is that this particular case of old code is, in fact, no longer useful. I left it in originally in case the new vtlb versions of hardware (in hwRead.cpp / hwWrite.cpp) were buggy. Seems they're not -- it's been months without problems now, so the old reference code can be removed.

The old VM code in LoadStore is still useful because we haven't converted *all* load/store functions to recompiled asm, and the VM code is a nice guide for when we want to do that. :)

Ah. Noticed the one #ifdef 0, but didn't notice the other. Mainly because I started from the bottom and went up.

Oh well, suppose I should remove that code before anyone else works on it... :)

You know, the one problem with having that much reference code in LoadStore, is there's more reference material then code there. It might be easier to work with if it was pulled out of LoadShare into a separate file, so you could see them side by side...

Revision 980

Fix compiler warning.

Not that anything uses the return value of this function anyways, but it gives a warning in Windows, and people tend to bug me if I leave compiler warnings that show up in Windows in...

I like this crazy commits, where is the iron man Jake and refraction? :P

Revision 981

zeroRecs:

-minor change

microVU:

-fixed a lot of various errors

-partially implemented some clip flag stuff

-partially implemented some branch/jump stuff

haobiao...

And here comes more "stuff"

> zeroRecs:

> -minor change

You better spend this time to microVU! ;)

Revision 982

Implemented Jmp/Jcc and MOVSX/ZX instructions, and added 'i' prefix to most

things (will add 'i' to a few more soon -- I think iRegister will be nicer than

'x86Register').

It will be like iPod, iPhone, iTunes, and so on...

Apple's marketing make us think that "i" prefix is nice...

I've used "i" prefixes since long long ago actually. Coders I worked with used to prefix things with i and m to denote intel/x86 vs. motorola/mac specific code back in the 'old' days (1994-1998). That's kind of ironic when you think about it .. the Mac using an 'i' when to us coders that made it look like an intel.

But yea it's easy on the eyes. We tried about every letter in the alphabet, and it came down to either 'x' or 'i' -- and 'i' made more sense. :)

Dropping a negative on this commit as a marker that it's causing a regression in Dragon Quest 8 (missing geometry). I'm pretty sure it has something to do with the LEA instruction optimizations. I must have goofed the logic up somehow.

Revision 983

Add an include so things compile.

The include is due to using Console in ix86_inlines.inl...

More of that gcc template parsing weirdness. That's highly annoying honestly, since C++ isn't really set up to have code in header files (in that it ends up running to interdependency issues because names need to be resolvable on the first pass of compilation), but templates require the code to be in headers. When GCC demands that things parse sanely, it means I have to spend lots of time including lots of crap headers, and including lots of crap forward declarations, even if they're never actually needed or used. :(

Well, I don't understand how VS allow you to compile code that have some sort of symbols that was never declared. It's some strange style of programming, really.

>> It's some strange style of programming, really.

Yes, it's template style programming. It's by nature evil hackery, and little more than a slightly more type-safe and backslash free method of using #defines. That's what templates are, and like #defines, they shouldn't generate syntax errors or external reference errors until you actually try to *use* them.

Revision 984

New speed hack mainly targeting 3D geometry.

darkvalen21

Works Great with MGS3 and GOW2. Nearly 100%+ speed in some zones

Awesome speedup. Works very well on FFXII, FFX, Valkyira Profile 2 is playable at fullspeed, Star Ocean 3, and so on.

Really, Really awesome.

Keep the good work up.

sofunnyc...

GREAT !

Works very good with Tales Of The Abyss.

Well, I only had issues with Tales of the Abyss. Same with Grandia III, too.

hilarych...

Works very good with Captain Tsubasa, Without this options, sometimes framerate will drop to 1xfps... now, mosts of times are around +5x fps :D wow

I don't know which svn exactly has caused it but Resident Evil 4 suffers from some light SPS now.

Ami.Mizuno:

Find out which revision RE4 broke, and a fix for it may come sooner ;)

GD.MK...

DQ8 has been broken since r982.

Confirmed that DQ8 is broken by r982. I'm looking into it.

rodiablo...

I tested with a few games I have. My setup: E2180 @ 2.8GHz + 9600GT.

It didn't worked with Xenosaga,breaks it completely, unfortunately.

But for my pleasure, Shadow of the Colossus is running at fullspeed All THE TIME with this speed hack ON(sometimes at 100fps or more) on my poor 2.8GHz C2D. I was amazed. The same for God of War.

Thanks very much for this, sudonim1 and all the PCSX2 team :)

ali.bou...

Won 10+ FPS on Dragon Quest 8, thanks a lot !

Game Tested: dot hack//gu vol.2

I think it gives a minor speedup but i have noticed that the fps counter rises but the game is running alot slower except for the music

noticable speedup in MGS3, however putting EE 2x speed and using this vu speed hack makes 60FPS but the game speed itself is slow.

In GOW, this speed hack makes everything smooth and playable, the only noticable side effect is Kratos keeps flickering (disappears and reappear quickly).

haobiao...

Great speedup in GoW2, magnificent!

cpuRegs.cycle += s_TotalVUCycles * Config.VUCycleHack

only this small change? what's the difference between it and vu skip?

maybe cov can explain it. :P

kimoki...

No speed up at all, only FPS counter speed up... but games are even slower.

turn off your frame limit cap, you should see much faster frames than without the speed hack on. Play around with it.

Speed is the same but but shows higher fps

another cycle hack.. this one looks very simple.

Any compatiblity issues with it?

i'll check it out when i come home.

There is no speed but it seems allow to upscale some very though games like MGS3 and SotC

That's amazing!!!

It seems that I can play most of my games even on my laptop now... Awesome... Tested on ECCO the Dolphin... I'll try other games this evening...

If only FFX will be playable(on my laptop), I will disappear for several weeks...

GREGORIO...

It works very well. If the speed hack skips the frame set it to medium

Yes, I noticed that on "high" it skips frames and sound gets desynced... On medium I can't see speed improvements in FFXII for example...

PS: I think PCSX2 needs benchmark already... Something as simple and basic as writing average FPS in .csv file every 1-5 seconds for example...

>> PS: I think PCSX2 needs benchmark already... Something as simple and basic as writing average FPS in .csv file every 1-5 seconds for example...

That's still a questionable feature, since many games increase in fps with speedhacks, but otherwise run slow or choppy due to emulation errors induced by the hack. For sure, adding benchmarking for speedhacks isn't ideal.

But I will improve some of our code profiling tools soon (when done with emitter and wxGui and stuff), unless someone else beats me to it. :) That won't add any fps features tho... it'll just be a per-block profiler for the recs (which will be pretty handy for performance tuning).

Nevertheless, it will be possible to compare different builds or different plugin options using the same speedhack options (or no speedhacks at all)...

But yes, it's a questionable feature...

Isn't a "per-block profiler" a debug-build-only feature?..

s_TotalVUCycles counts how many emulated vu cycles we've spent in the vu recompiled code.

What we're doing is "stealing" these cycles from the EE, quite simelar to what the sync hacks do.

This was meant to enhance the sync between ee and vu, but that didn't turn out so well.

We noticed it's nice as a speedhack though, so here you are, one more cycle hack :p

fajar.nu...

I get to 100FPS from my original 40FPS on God of War using this speedhack. No speed improvement on FF12 though the FPS read got higher.

this hack increases speed ONLY if GS part have enough resources. When GSdx set to 2048^2 hack makes everything slower. With 1024^2 - faster. Speedup usually somewere around 20%. Tested with Warriors Orochi 2, Virtua Fighter 4 Evo, Soul Calibur II/III, Tekken 4, Hand of God, SW: The Force unleashed and some other games - everywhere same results.

So, if you playing with GSdx on 2048^2 (just like me), you'll get no impact.

BTW, EE sync hack works just the same. No impact if there is not enough resources for GS. Yet no slowdouns usually...

sudonim1

I've been playing far too much star ocean since adding this, it's a barrier to development.

OMMMMMMMMMMGGGGGGGGGGGGZZZZZZZZZZZZZZZ I'M NUMBER 40!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

upfloor, you are 41 :P

cotton will make r1000 - MicroVU's working, +250% speedup on most games.

:P

Or it could be: "Fixed minor typo". :)

good of war is indeed faster, but the characters are flickering.

GT4 has SPS in the distance and got not speedup,

very strange in FFX: graphics are slower, even at fullspeed and the music still plays at normal speed.

KH1: no difference.

This speed hack is fantastic!

On personal test, It work better when your not ussing the VU-SKIP (less onscreen error)

chaoski...

That's great!

Thanks a lot

natso...

uhhmm, im new here, how should i use these codes on pcsx2 emulator?

read the source very loud and imagine you're playing the game... ^_^

Seriously, try to get Visual Studio 2008 and TortoiseSVN, get the latest source, open it and compile it...

Maybe it'll be easier to get latest installer, latest SVN binaries of the emulator and plugins, copy one over another and be happy...

Try to google something like "how to compile things in VS2008"...

natso...

thanks eliotfur!!

Revision 985

Added CMOV to the emitter, renamed x86Struct stuff to iStruct, renamed XMMREGS /

X86REGS / MMXREGS defines to iRegCnt_XMM / iRegCnt_GPR / iRegCnt_MMX, and undid

a couple u32 optimizations which could have caused unexpected behavior in the

future, if we ever decided to employ some particularly obscure case of self-

modifying code.

Hmmm...

ix86_legacy.cpp:125:1: error: pasting "iMOVSX" and "(" does not give a valid preprocessing token

...

ix86_legacy.cpp:131:1: error: pasting "iMOVZX" and "(" does not give a valid preprocessing token

I hate trying to decypher defines that create functions. ..

Will fix in my next commit.

I don't like those defines either, but they're just there to patch the legacy emitter in to the new one. Eventually we can delete them, when the legacy emitter is dead (someday...).

... for the record, it's just some extra ## in front of the '(' -- but I'm still busy adding iMUL stuff. Will commit soon. :)

All right, cool. I've just been in and out of my apartment, and fiddling with other things, so haven't really had time to look at it beyond getting the error message.

For example, I thought I'd be a good idea to install Wubi on my Windows 7 partition, and see what's necessary to get pcsx2 running on it. I like installing oses in virtualbox and vmware as a bit of a hobby, anyways,so this is just a bit of an extension of that...

Revision 986

Emitter:

* Added MUL/DIV/IMUL/IDIV to the emitter, renamed as UMUL/SMUL respectively (to

remove ambiguity of the instruction behaviors).

* Fixed a bug in the shift instruction emitter that would have caused it to

emit the wrong instruction type (like a SHR instead of a SHL, for example).

* Added type strictness to the shift instructions that take the CL register as

a parameter. Passing anything other than CL will generate compile time errors

now.

* Fixed a syntax error in one of the legacy defines.

The Shift instruction bug may have been what caused missing geometry on DQ8 (although unlikely). Someone let me know if the DQ8 missing geometry problem persists, and if so we'll create an issue and troubleshoot it further from there.

Ooops! I forgot to add a file! Blast it. >_<

GD.MK...

DQ8 still broken by r987。

Revision 987

Forgot to add a new file from the last commit... >_< [ix86_impl_dwshift.h]

Just because it can be rare occassionally, just thought I'd let you know; Linux currently compiles ...

Revision 988

Emitter: fixed a bug in MOVSX/ZX's reg->reg form [resolves Issue 159 - missing

geometry in DQ8], and moved some files around.

Thanks for the fast fix.

Revision 989

Minor bugfix for unpack mode 2

Fixed split videos in Gradius V

Fixed Spyro hanging problem in Issue 112

Put in a hacky fix for FFX videos into IPU to compensate the spyro fix (which is

actually correct).

Implementing unpack overflow protection (Guitar Hero 3 & Toni Hawks Project 8)

Writing XGKick to a temp buffer before sending to the GS (part of the GH3 / THP8

fix)

Note! THP8 and GH3 will STILL crash with any VUrecs on and MTGS on, these must

all be OFF. Also use GSDX in software mode with the NLoop hack on for now. Slow

i know, but it works :P hopefully we can fix the rec side of it soon.

Just as a note:

#define gif ((DMACh*)&PS2MEM_HW[0xA000])

in IPU.cpp shouldn't be necessary. A few revisions back, I moved that definition to Memory.h, along with several other definitions involving PS2MEM_HW, mainly because the same definitions were being used in multiple places.

And Memory.h is in Common.h, so it'd be included in IPU.cpp...

yeh but i started on these changes before you did all that messing n didnt realise :P

you're free to remove it in future commits if you get there before i do

Figured it was something like that.

If you haven't removed it when I have a chance to commit, I'll remove it (If I remember at that point).

Right now, I'm still wrestling with Jakes changes...

Note for Tony Hawks Project 8 & Guitar Hero: The Nloop hack tick box must be black! this feature has to be on, else it looks quite bad lol

hi,refraction. this revision breaks DQ8's word display.

yeh ill look at it

Issue with DQ8 only effects GSDX, looks fine in ZeroGS

Revision 990

Emitter: Implemented INC/DEC/NEG/NOT instructions. Plus: many code cleanups

using a better form of template parameter inference.

We tested the template inference thing on gcc before I used it here, so *hopefully* everything compiles ok on gcc.

Actually, I'm getting:

ix86.cpp: At global scope:

ix86.cpp:243: error: uninitialized const 'x86Emitter::iMOV'

ix86.cpp:262: error: uninitialized const 'x86Emitter::iNOT'

ix86.cpp:263: error: uninitialized const 'x86Emitter::iNEG'

ix86.cpp:264: error: uninitialized const 'x86Emitter::iUMUL'

ix86.cpp:265: error: uninitialized const 'x86Emitter::iUDIV'

ix86.cpp:266: error: uninitialized const 'x86Emitter::iSDIV'

Just looking at that right now...

Just noticed that in the maze of compiler warnings before that, the following two errors were in there as well. Not sure if they are from this one, or 988:

implement/movs.h: In static member function 'static bool x86Emitter::Internal::CMovImpl<ImmType>::Is8BitOperand()':

implement/movs.h:184: error: 'OperandSize' was not declared in this scope

implement/movs.h: In static member function 'static void x86Emitter::Internal::CMovImpl<ImmType>::prefix16()':

implement/movs.h:185: error: 'OperandSize' was not declared in this scope

Note: these may be easy to fix; I've just barely started looking at them...

I'm down to the latter error, about OperandSize, incidentally.

Ok, r993 takes care of the compilation issues. Though I get a million warnings when compiling now. Most of which would be errors if I hadn't added -fpermissive to the flags a long time ago.

(Yes, most of the issues we've been running into are when it's in permissive mode, and giving you some slack. Linux wouldn't have survived the C to C++ transition otherwise.)

The compiler warnings are along this line, in case you're curious:

./x86/ix86/implement/group2.h:49: warning: there are no arguments to 'prefix16' that depend on a template parameter, so a declaration of 'prefix16' must be available

Is it your ClassDiagram1.cd link in the project file, Jake?.. :-)

Revision 991

Fixed Issue 157

removed redundant code arcum pointed out I'd committed

Revision 992

Look out, the monkey is back

regi...

Holy monkey bladers it's Monkey Island!

http://www.cs.washington.edu/homes/cmprince/games/monkey_island/chars/monkey.gif

Always love it when we know whats going on

Revision 993

Here we go again.

Typo fixes too, excellent sir :)

Yeah, I like to fix those if I notice them. Unless they are sufficiantly entertaining, anyways... :)

Revision 994

Reduce compiler warnings to a more reasonable level in Linux.

An alternative would have been to make all these functions non-static, and use this-> instead of ImplementationHelper<ImmType>:: , incidentally.

Jesus. It's like anything that's designed to be useful becomes useless once the full on suckage of the C++ standard is adhered too.

Yeah. Didn't like this commit, really, but the noise from these warnings was drowning out any real warnings. I thought about making them no longer be static, and using this->, instead, because it'd look better, but I figured I'd let you make that decision.

What's irritating is that given a choice between adhering to the letter of the standards, and acting like most other compilers do, it seems like gcc's developers will adhere to the standards every time...

Yes, GCC plays by "principle" over "practical."

The problem is that the C++ standard is developed by monkeys with no real-world experience in programming. They've proven time and time again that they really have no idea what a programming language should be like. And so even when they do finally come up with a good idea, they mess it all up by imposing idiotic standards that both complicate the compiler's job and the programmer's job, for no benefit.

Revision 995

Added a check to make sure the unpack REALLY overflows, sometimes it can be dead

on the limit or count the skip, so it doesn't need to break to slower code.

Revision 996

Bring the new speed hack to Linux. (I just quickly hacked it in, so I may make

it look nicer later.)

Revision 997

GSdx: reworked the gs transfer function a bit, and removed the nloop hack, which

does not seem to be necessary anymore.

Wasn`t nloop needed for GH3 to work?

guhun...

Because now it's always enabled.

Now the NLOOP is enabled by default :)

finally, the nloop hack has confused a lot of people.

Yes, finally... I don't understand what NLOOP stands for, anyway... I thought it's SQUAREENIX-FIX...

Gabest, don't you think that "Logarithmic Z" should be enabled by default... All my games have better appearance with that enabled...

shagkon

It shouldn't. It breaks Rumble Roses shadows for example.

So? make Logarithmic Z the default and have a tick box for the other option, sounds more plausable to me

Gabest, Great work. this revision doubled the speed for FF12 on the first teach scene for my old N6600 video card (from 16 to 33, still slow :P). and FF12 other scene increased about 5fps too.

But DQ8 seems has some issue at save/load frame, lost the word.

the DQ8's issue is caused by 989 and refraction :P

if it is what i think it is, then ive passed it on to gabest to look at cos the reason that happens baffles me as well :P

DQ8 issue only effects GSDX, use zerogs if you need to see it

This rev. makes the INTC Sync Hack useless.

On r962 with INTC on Ar Tonelico 3 I get ~150fps,without it 50fps

On r997 with/without INTC I get 50fps on the same game,same place.

wow really? considering it has NOTHING to do with it, i cant see how. try turning vsync off?

On r962 and INTC disabled I get the same speed as on r997 with or without INTC.

On r962 with INTC I get ~150fps and without it is 50fps.

I've never EVER used the vsync option(it's disabled)

I've writed about this in the GSdx thread and sorry if I'm double posting with this post but I don't know if its possible to edit my post here.

FFXII in the begining of the game i had 37fps is now 60fps, there were much slow down before and after the fight with spaceship, now it only slowdown when spaceship is coming down to atack, Tekken 4 that had slowdown is the last fight, now it only slowdown 1 second on fireworks.

Grandia 3 got some boost but not that much, in the begining increase between 1-6fps, it still gets as low as 22fps with 3.0Ghz SSSE3 and ati 2600.

It's still awesome improvement between this one and 0.1.14, on FFXII and Tekken 4 maybe for grandia 3 i really need a better gpu to get better fps.

INTC stat hack is still working as expected, tested with AR Tonelico.

Still getting 450fps ingame, which should be enough ;)

I can also confirm that FF12 got faster with this in 3d, I'd say about 15% plus. Nice work :)

Check the GSdx thread,I posted screenshots on Atelier Iris 1,2,3 and Ar Tonelico 1 and 2.

http://forums.pcsx2.net/thread-3031-post-42136.html#pid42136

On all of them expect Ar Tonelico 2,the speed differences between r962 and r997 is really huge.

expect=>except

misspell

It works now???

I didn't change anything from the configuration?

I restarted my PC and the problem is here again :(

Revision 998

Extremely insignificant optimization applied to recADD/ADDI instructions (omg it

might save a cpu cycle per minutes or something!)

Also: Reverted the addition of the ImplementationHelper<> class, since it failed

miserably under GCC. -_-

That'll work...

yeah, it's more readable this way. And same amount of copy/paste in either case.

who will be the 1000th commit :P

~> it might save a cpu cycle per minutes or something!

It'll be alot if we play game for many hours, lol

Yeah, 1000 is coming. Or it will be PCSX2 0.9.7

I guess after cov complete the micro VU stuff, and Jake complete the new GUI and IPU stuff, 0.9.7 will be released :P

i think 0.9.7 will come when the microVU's are finished and lot of beta tests has been made.

I see a lot of work coming for us.

Let me KINDLY remind you that comments on svn should be more or less useful, unless done by project members. Yeah tough luck, the world is unjust like that.

KINDLY. For now.

Revision 999

-Scaled back the EE load/store cycle count to the theoretical minimum of 1

cycle. (Fixes Digital Devil Saga PAL fmv)

-Added a safety to the VU cycle stealing hack, so it doesn't go berserk :p

Note:

Due to the changed cycle count a lot of games will get "slower".

Especially FMV will be affected.

This is unfortunate, but correct emulation comes first.

You can however enable the ee sync speedhacks, as they're more stable now as

well.

This can bring back the lost speed.

ee cycle *2 works for Fatal Frame now :P

malo.sa...

can't you add this modification as an optional gamefix ?

>> can't you add this modification as an optional gamefix ?

Yes, it's optional. Enable the X1.5 speed hack, and it'll behave roughly like the old cycle rates. Problem solved.

The problem is that the EE's average load instruction is pretty much 1 or 1.2 cycles per (stores may average slightly higher on the EE, but it's very subjective based on code being run). Thus the load store cycle rates up to now were essentially speed hacks of their own.

malo.sa...

>>The problem is that the EE's average load instruction is pretty much 1 or 1.2 cycles per (stores may average slightly higher on the EE, but it's very subjective based on code being run). Thus the load store cycle rates up to now were essentially speed hacks of their own.

Did not yet catch a word :) but I think it is one again the time to thanks you a lot guys for your great and amazing work

A lot slower now maybe make this commit optional like Jake said?

But it surely much more like the real not skipy like previous even with hack

Autor:

Read Jakes comment again, THIS is the correct behaviour.

You have the option to enable hacks and bring back the lost speed however.

After some test i realized it too, Thanks rama, this carries games right way