PCSX2 Documentation/Google Code svn repository comments archive 1000 to 1249

Revision 1000

Commented out my bodge to XGKick on the VU interpreter, Gabest has now solved

this issue in his latest gsdx build. Happy 1000th commit :)

jasperk...

Well done on reaching r1000 :D

Can you remove the lines now that they are not needed anymore?

Autor...

Hooray!!! 1000th rev!!!

song...

Gratz on 1000th rev :D !!!

refraction

im leaving them there for testing purposes

Zeydl...

Sorry, but what was this issue about?

Xeli...

Kudos on the 1000!

refraction

VU memory wrapping on an xgkick. a kick can start at say 0x3fc0 and end at 0x0100, but obviously without decoding the giftag we dont know that, so the gs plugin needs to wrap around

eliotfur

Long live the King... errr... I mean developers...

zfwzelda

Great job on reaching r1000;hope to be perfect in next 1000.

Revision 1001

Emitter: Added BTS/SETcc/TEST instructions.

arcum42

Guess Linux must have been broken since this commit, and I hadn't noticed. Oh well. The section giving me issues is in bittest.h, this code:

static __emitinline void Emit( void* bitbase, const iRegister<ImmType>& bitoffset )

{

prefix16();

iWrite<u8>( 0x0f );

iWrite<u8>( 0xa3 | (InstType << 2) );

iWriteDisp( bitoffset.Id, bitbase.Id );

}

Gives the error:

error: request for member 'Id' in 'bitbase', which is of non-class type 'void*'

I'm assuming because it doesn't know if bitbase has a member named Id or not, due to it being (void *), though I could be misreading it...

Revision 1002

Fixes a mistake that I made in r927. Fixes regression issue 158

Ami.Mizu...

Thanks for this fix, was gonna check which svn causes it but seems another person did so thanks to him too. :p

Revision 1003

microVU: mostly block-linking/execution stuff...

Revision 1004

LilyPad: fixed a crash under remote desktop, GetRawInputDeviceInfo may return

-1, the buffer size it wants is around a megabyte and gets filled with junk,

just ignoring it seems fine.

Revision 1005

GSdx: adapted to ref's changes to the image transfer, it was a bug in GSdx but

not triggered by the old way, also the data overflow is now ignored, no idea

what it may cause, look out for missing or fixed textures.

refraction

nice one :)

Revision 1006

GSdx: Issue 149 (GoW2 crc) and removed the dx9 flag to enable tv-out, which

might have been the cause for limited fps in recent revisions.

junr...

Oh, you commits code like refraction now :P

Hi, Gabest. would you please look at the white dot issue for fatal frame. (it exists for a long long time)

jfre1...

Make an issue thingo for it.

Autor...

Gabest maybe you add one more CRC for ICO in with next commit

CRC=7ACF7E03

Revision 1007

Regression fix for GT4, crashes presumably due to the zero division on this

check

Jake.Stine

Yeah gotta hate those division by zeros on out-of-order conditional checks. I've fallen prey to a few of those myself in the past.

refraction

little bugger arent they :P

Revision 1008

Resolved Issue 165 so the scratchpad syncs with the MFIFO drain (this was the

cause of the Tekken issue). and some other misc tweaks for unpack errors n such

GD.MK...

Tekken 5 got black screen before battle.

refraction

you mean the point between the loading screen and going ingame? wow really? :P

GD.MK...

Yes，after the loading screen can only hear sound and see nothing，you can press X or start going ingame.but everthing appear when you ingame.

archer.mac

Confirming :(

Menus in Tekken 5 give a black screen now, but if you blindly navigate and start a fight it'll work and you can play and see everything.

The "loading Tekken 5 data" , "load complete" and mem card check messages displayed at startup aren't there either,just the colored info boxes without the actual text.Man this game is picky...

refraction

okay ill look in to it

Revision 1009

more microVU "stuff"

<gigaherz>if the commit log has "stuff" in it, it's vu work from cotton

keb...

i'm curious, if you could measure the work needed to make the microVU "stuff", what percentage is already done?

cottonvibes

over 90% is done, but getting it to run games nicely is the hardest part!

(because the bugs can be anywhere, so 1 typo can make 99% of games not work. and it can take days finding that 1 typo)

jasperk...

Keep it up cottenvibes we are all rooting for you :D

Ami.Mizu...

w00t over 90% done. I like how structured and well documented the code is. Hopefully it will offer a decent advantage over the old code in both terms of compability and performance, otherwise... think of all the damn work made for nothing, that thought would drive me crazy lol.

Revision 1010

Tagged current revision of iMMI.cpp, as it's the last one that will have all the

legacy x86/mmx implementations (from when Pcsx2 recompilers didn't require SSE2

as a rule).

(next rev will remove the dead code)

Revision 1011

Emitter: Fixed a small bug in the ModSib emitter logic which caused some forms

of ESP to encode incorrectly. Implemented CALL/BSF/BSR [x86], MOVQ, MOVD, and

MOVSS [mmx/xmm]. Renamed ix86_mmx.cpp and i86_sse.cpp to ix86_legacy_mmx.cpp

and i8x_legacy_sse.cpp.

iMMI.cpp: Removed mucho dead pre-SSE2 code. (old code can be grabbed from a

tagged revision, in case it's useful for future reference).

Jake.Stine

This revision contains a lot of changes, and likely breaks something. So I'd appreciate some extra testing here if possible. Please report if you experience any changes in behavior or regressions.

junr...

FF12 was breaks at begin the game frame if the EE cycle rate *2 (1* 1.5* is ok)

but maybe it is issued by ref :P

Revision 1012

backup

junr...

why no stuff :P

ntcong.it

I'm looking forward to the day microVU will be move onto a branch and we can start testing it

ItsAGraf...

Well, you can test it right now - just ucomment #define PCSX2_MICROVU and #define PCSX2_MICROVU_ in Pcsx2Config.h and compile.

But there is still not enough ...ehmmm... stuff ;) to get it working.

Revision 1013

LilyPad: More minor fixes to failure detection in raw input initialization

code. Gabest already fixed the big one.

Revision 1014

LilyPad: Oops.

Revision 1015

Emitter: Implemented MOVAPS/MOVDQA, and renamed some vars/classes.

Revision 1016

Quick hack to fix Linux compiling. Delete some old code. Minor tweaks that I

hadn't gotten around to committing.

arcum42

Note: the change to bittest.h is just a quick workaround, because nothing appeared to be using that version of Emit currently, and gcc did not like calling a member function of void*, as far as I can tell.

Still looking for a better fix.

And I thought I might as well get deleting that huge chunk of Hw.cpp out of the way.

Jake.Stine

Oh, the workaround is much simpler. I added a .Id by accident. Remove that and GCC will not complain.

arcum42

That explains things a bit, then. I'd seen bitbase.Id in a few other places, so I'd just assumed it was as intended.

I'll remove it and get rid of the ifdef next time I commit, if it hasn't been done by then. Since I'm not planning on any more commits tonight, you'll probably beat me to it, though...

Revision 1017

microVU: fixed various typos

wisestud...

Teeken 5 is Black screen at today's update......

ntcong.it

Try to get the specific rev that it broke, you should start from r1007 or r1008

jfre1...

*Shoots wisestudiodev from a nearby rooftop*

Revision 1018

Change some magic numbers to enums and defines and rearrange things a little...

Revision 1019

Silly bug made each EE branch count as 0 cycles.

Enjoy some "free" speedups :p

Autor...

I saw you move a single line, how much this can speedup games? Just interesting

Jake.Stine

Most of our major speedups have been 1-3 line changes to EE cycle rates.

This is the magic of EE cycle rates. They control the effect Mhz rating of the EE, and less Mhz means less work for the emulator. In this case, we were losing cycles on the branch instructions, and that caused the emulator to run a lot of instructions at "no cost" effectively giving the EE a 400mhz clock instead of a 300mhz one (affects mostly games that spin a lot, like INTC_STAT ones and stuff).

junr...

nice work, from 60 to 73

v...

Yes that fixes the speed drop I get on r999 compared to r998/r1012

Autor...

This really a speed up it seems speedhacks returned to speed that was before 999

Ami.Mizu...

Yea this seem to bring some 8~12% speedup for most games.

Autor...

Anyway this is regression of X2 hack syncronization

rodiablo...

@[email protected],ru

Well, you always have 1.5X hack, so no big deal. ;)

Luke.Her...

Thanks, I'm gonna give it a try! :)

Revision 1020

Emitter: Fixed a GCC compilation error; Implemented MOVNT/MOVLH/MOVHL/PMOVMSKB,

and tied in all old emitter references to MOVAPS/MOVDQA to the new versions.

Revision 1021

Emitter :Implemented Packed logical operations (PAND/POR/ANDxx/ORxx/etc),

ADDxx/SUBxx/MULxx/DIVxx, and iRCPPS/iRCPSS.

malo.sa...

hi what is the emitter ? is it used actually ?

refraction

as you may guess from the comments, this revision breaks charlie and the chocolate factory (just tested it then put the lines back in)

refraction

thinking about it, would be better anding the address from fs with the memory size (well 0x3fff or 0xfff), i know thats basically what hes doing in the original code, but not quite as accurately :P

Jake.Stine

I didn't mean to commit that either. I deleted the code to test and forgot I deleted it. :/

Also, I'm still quite sure that code is just masking some other error in the VUs, by effectively clearing "garbage" out of the upper bits that shouldn't be there anyway. But then I'm not going to spend time trying to fix it properly when there's a newer vurec on the horizon. :)

Jake.Stine

... for that matter, did/can you test using AND instead of CWDE? If Charlie works, I'd say go with that instead.

refraction

ok now its fixed, ill get rid of the negative :p

Revision 1022

The things Visual C++ lets you get away with...

Jake.Stine

Heh yeah that's because msvc doesn't parse templates unless they're actually referenced. So there's a lot of unreferenced code int he new emitter and VC won't bother to generate errors until something actually makes use of it.

arcum42

Trouble with that is that by the time you go and use it, and find out that there are errors in it, you may have forgotten why the code was written like that initially, so it's harder to fix...

Of course, if it really becomes a problem, you could always put the unreferenced code behind ifdefs. Gcc won't touch it then.

Of course, that's why Cache.cpp broke without anyone noticing. (It could probably be fixed. It just uses memLUTR and memLUTW all over the place.)

Jake.Stine

My beef with the pre-parsing that GCC does (which is defined by the standard -_-) is that it's inherently incompatible with the way C++'s parser works in all other language cases -- namely that it's a single pass parser which is *not* meant to have code implementations mixed with the type definitions. When you mandate template ahead-of-time parsing, and then use templates that call other templates, you end up entering a world of pain where you have to fight like hell to make sure inter-dependent code from either template is available to both.

But otherwise, yeah, finding syntax errors is fine. I wouldn't mind if msvc did that too. I just don't want it to resolve function/variable names until I create instances of the template later on, once all my vars have been safely defined. In fact, that would (if it were standard!) been a great boon to improving and simplifying C++ header hell. (cries)

Revision 1023

microVU:

-implemented the ability to run VU's for x amount of cycles, instead of running

till the microprogram is completed (some games can get stuck in infinite loops,

so this is needed)

-fixed some errors...

Jake.Stine

Some games apparently "spin" the VU0 in the background indefinitely, and then expect to stop it and put it to use when needed. But afaik, the VU1 should never be used in such a way.

Revision 1024

Put a different fix for bad J/JALR jumps (Charlie and the Chocolate Factory)

refraction

This also fixes the crashes on Guitar Hero 3 and Tony Hawks games when the recompilers are enabled

Revision 1025

LilyPad: Fixed a potential threading issue when read input in gs thread is

disabled. Odds of the issue being a problem, while perhaps significantly

greater than 1/<number of atoms in the universe>, weren't too high.

Revision 1026

Bugfix for the new emitter: ([xmm/m128],xmm) form of MOVQ was generating the

wrong opcode (introduced in r1011). [other changes are a work in progress for

more instruction additions]

Revision 1027

Fixed Tekken 5 regression causing black screens and missing text

Revision 1028

Resolved Issue 168 with FFXII crashing with DMA error due to cancelling a

scratchpad transfer before it happened, how silly of me :p

Jake.Stine

Yay I can test the emitter instructions on FFXII again! :D

Revision 1029

More work on cycles. FPU is slower than assumed earlier.

Also added COP0 DIE bit handling, that disables the EE's dual issue

capabilities.

Jake.Stine

Yeah DIE is supposed to be for debugging purposes only and, perhaps, for some special kernel level thread-safety or IRQ-safety code.

Revision 1030

Emitter: Changed a lot of 'i's into 'x's, because...

<JakeStine>sudonim says he likes xMOV better than iMOV as an emitter prefix. I'm

wondering if I should go ahead and change it.

<JakeStine>I tend to favor logic, but everyone else just thinks it looks like

iMac and iPod

<JakeStine>I just don't want to have to change it more than once.

<cotton>well 'x' is like the algebraic variable, which can be anything

<cotton>so it does kindoff make sense

<cotton>cuz like

<cotton>you have xSOMETHING, where SOMETHING is all the different emitter

functions

... I'm sold. :p

cottonvibes

lol

ntcong.it

I hope that you will not change it to another prefix, like lolMov :P

mattme...

stuffMOV is the obvious choice.

kaboo...

iMov ... does sound like an apple product XD

refraction

i think plz would be a better prefix, much more polite.

Like:

plzMOV

plzADD

and to clear regs you could have

tyvmClearXMMRegs :p

DantePi...

I know what not your fault, but has decided to write to the knowing person... Can create issue for kingdom hearts some pictures hang up on last (or even all audits), nevertheless on the official version all works (the first time hangs up in the end of a picture with the storm beginning on the island, the second time after a meeting with the first boss... It is possible as further, and hangs up not in skript to the scene and in looked through dialogue)

PS I apologise for my bad English

arcum42

Well, if it's a prefix for an emitter, I'd think the logical choice would be another prefix that been used at Apple, e. (eMOV, eADD, eRegister, etc...)

arcum42

And, at a note, Linux still compiles. Bitches a little about iJccKnownTarget on line 73 of jmpcall.h a dozen times, but everything is still working. Which is good, because I got home late, and don't have time to work on pcsx2 at all tonight...

Jake.Stine

Ok, I think I can fix that with a (uptr) typecase addition.

heatbla...

Tekken Tag works fine now, no more black screens.. but is much slower, especially on the snow stage and in the temple stage.

Revision 1031

Emitter: Implemented SQRT/RSQRT/UCOM and all variations of SSE CVTs (omg those

were a nightmare) [also patched old emitter to use new MOVD implementations --

missed those earlier].

Jake.Stine

Ah, forgot I also did SSE's MIN/MAX implementations in this update as well.

Autor...

BTW, Jake i see you improve emmiter for a much revisions, but what it gives, just don't know what emmiter in PS2

refraction

emmiter isnt in the PS2 thats why :p the emitter is part of the eerec and vurec's

Jake.Stine

The emitter is what generates x86 code. Diagrammed:

Mips Machine code -> Pcsx2 Recompiler -> Emitter -> Recompiled x86 Machine Code -> Execution (yay!)

The current emitter had roughly 15-20% coverage of available x86 instructions and forms (registers and parameters allowed to be passed to those instructions). It also had bugged support of some of that which it did support, in that using certain forms of indirect addressing (ie, [esi+0x30]) would potentially generate bad code. And it was completely non-typesafe, as you could accidentally pass an x86 register into an SSE function, for example (and it would have thus generated bad code).

All these things are fixed with the new emitter.

malo.sa...

is pcsx2 able (I think at the recompiler level) to find some advanced Mips code pattern like IF, WHILE , CASE.....

Jake.Stine

Not currently. We've worked on a dead loop detection system off and on with moderate success but it's not svn-ready yet, and only gives a noticeable speed boost on certain games. [IF/CASE aren't optimizable so much -- remember the MIPS compiler has already optimized them, so what we're doing is recompiling optimized code in most cases].

Still, some games have dumb (or complex) idle loops that spin on various data or hardware registers (or nothing at all), and detecting/optimizing those would be an improving.

Generally speaking we'll find a lot more speed in other areas of the emu, without introducing potential incompatibilities. And Speedhacks can, to some extent, act as reliable WHILE() skippers.

Jake.Stine

... and speedhacks are usually just a couple lines of code, where as detecting while loops correctly is somewhat more complicated, so that's why we tend to favor speedhacks -- they're easy ;)

malo.sa...

thanks for the clarification

jfre1...

For a full 100% coverage of all x86 instructions (I know something like that would be an immense undertaking in itself) would we require current level pc`s, or are they something that all pc`s support?

Mind the noob question but I find all this stuff really fascinating.

And secondly, is the covering of more x86 instructions the overall key to future speed increases / greater compatibility with pcs?

Jake.Stine

It could be beneficial to speed yes. One of the reasons I started the emitter is because I wanted to do some basic optimizations and couldn't because the indirect (memory operand) forms of the SSE instructions I wanted to use did't exist in the emitter. And when I realized that basically *none* of the SSE instructions supported this form in our current emitter, it seemed logical to remedy the situation.

But as important really is the type safety and parameter checking. It speeds up development time and reduces the likeliness of bugs (for example, some of the old SPS problems of the VUs prior to Playground were due to errors in register selection that a smarter emitter would have disallowed).

ItsAGraf...

Hmmm. So it seems to be just like MicroUV in terms of importance and compatibility. But it works right now!

MORE!!! :)

Revision 1032

Emitter: Yay! More instructions! All forms of PADD/PSUB/PSRL/PSLL. I'm

getting closer!

Revision 1033

microVU: added support for logging complete micro programs saved to the files

microVU0.txt/microVU1.txt (in the logs folder)

note: currently the code only lists the opcodes without the operands.

Revision 1034

LilyPad, Sio.cpp both modified to never allow pads in first slot on either port

to be unplugged, as it broke things. Unplugging pads from other slots seems to

work fine, when using multitap (When not, obviously no such pads in the first

place).

Revision 1035

Added PMIN/PMAX/PMUL/PCMP/PSHUF/PUNPCK/UNPCK/PACK instructions to the new

emitter [this basically finishes all MMX instructions -- just some SSE2/SSE3 and

SSE4 mess left!]

andreabo...

with this coding speed next release will be 1.0 or 1.1 directly :)

Autor...

This coding brings speed or compatibility or safety?

jfre1...

See earlier revision posts, he spoke about it in long detail

Revision 1036

Fixed a small bug from my last commit (mostly only affected debug builds), and

implemented PALIGNR/MOVSLDUP/PABS/PSIGN/PEXTR/PINS.

arcum42

Here we go again...

Main errors I'm having issues with:

implement/xmm/arithmetic.h:28: error: declaration of 'unsigned char Modcode'

implement/xmm/arithmetic.h:24: error: shadows template parm 'unsigned char Modcode'

implement/xmm/arithmetic.h:75: warning: ISO C++ forbids declaration of 'ShiftHelper' with no type

implement/xmm/arithmetic.h:75: error: expected ';' before '<' token

So the main issues there are the nested use of Modcode, and it not liking the declaration of Shifthelper in SimdImpl_Shift.

There are a bunch of errors in shufflepack.h where imm should be imm8 (which is easy enough to fix), but lines 259 and 265 also shouldn't be using 'to'. Presumably, they'd use dest, but I ran into issues with that as well...

VNL...

const Woot<0x00> PS

w00t?

arcum42

Ah, well, with any good emitter, you have to have planty of woot on hand to make it work... :)

Jake.Stine

ok, Working on it.

Jake.Stine

Alright think everything should be fixed. Committing in a minute.

(And if you haven't noticed already, 2-3 small errors in templates will spit out like 75-100 errors per file, heh).

arcum42

I've definitely noticed that one compiler warning gets magnified into hundreds. And yeah, it keeps trying to process after an error, and tends to generate a dozen more...

Revision 1037

Linux: Fix some GCC compilation errors. And update the msvc project (somehow

didn't get committed last night, but only change header files so prolly didn't

break anything).

Jake.Stine

I think this should fix both of the Shifthelper errors. The second one was likely because the first one was failing t declare the type properly, so subsequent attempts to use the type generated errors like the type didn't exist.

(but damn, I wish GCC would just say "Type not declared or not declared properly" instead of cryptic damn ISO C++ errors/warnings).

ItsAGraf...

Cannot compile it with ICC:

nontype "x86Emitter::Internal::SimdImpl_ShiftWithoutQ<OpcodeBase1, Modcode>::ShiftHelper [with OpcodeBase1=OpcodeBase1, Modcode=Modcode]" is not a template H:\SVN\PCSX2\PCSX2\pcsx2\x86\ix86/implement/xmm/arithmetic.h 75

malo.sa...

ICC is the intel compiler ? If yes , ever when it compile it crashs a lot during execution.. at least for me with the 11.0 evaluation version

refraction

72 class SimdImpl_Shift : public SimdImpl_ShiftWithoutQ<OpcodeBase1, Modcode>

should probably be changed to

72 class SimdImpl_Shift : public SimdImpl_ShiftWithoutQ<OpcodeBase1>

as well then

Jake.Stine

Nah, I only removed the Modcode from the Shifthelper child class. ICC is known to have inabilities at compiling templates. I'm not going to worry with errors from ICC unless GCC also has an issue with it.

ItsAGraf...

to malo.sasha:

Intel Compiler, of course, v11.0.066.

But previous versions fully compilable AND playable. Latest version I compiled and tested is 1035. Here is the exe:

http://rapidshare.com/files/224037161/pcsx2_ICC.7z

malo.sa...

ho , so maybe i lacked some luck when i tried ; btw do you see any speed up with it

ItsAGraf...

Yes, there is some speedup. Different for various games.

For example, Virtua Fighter 4 Evo:

MSVS2008 - max 37 fps, average 35

ICC - max 42 fps, average 41.

But for Warriors Orochi 2 (fullspeed):

MSVS2008 - average 87% CPU load

ICC - average 80% CPU load

Not so impressive, as for VF4.

Anyway, there IS reason to make PCSX2 compilable with ICC, as you can see...

Oh, BTW. Forgot to mention... This exe compiled for Core2 ONLY (needs SSSE3). Just because I have Core2 e6550. :)

Ragha...

Isn't PCSX2 quite incompatible with SSE2?

Zeydl...

Are you sure that it's fix linux build? For it it's not true:

gcc -DPACKAGE_NAME=\"pcsx2\" -DPACKAGE_TARNAME=\"pcsx2\" -DPACKAGE_VERSION=\"0.9.6\" -DPACKAGE_STRING=\"pcsx2\ 0.9.6\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"pcsx2\" -DVERSION=\"0.9.6\" -DSVN_REV=\"Revision:\ 1037\" -DNDEBUG=1 -DPCSX2_FORCESSE3=1 -DPCSX2_FORCESSE4=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_NLS=1 -I. -I./.. -I./../../ -I./../../../common/include -I./../../../3rdparty -I/implement -I/implement/xmm -pipe -msse -msse2 -O2 -Wno-format -Wno-unused-parameter -Wno-unused-value -Wunused-variable -fno-guess-branch-probability -fno-dse -fno-tree-dse -fpermissive -Xlinker -zmuldefs -MT ix86.o -MD -MP -MF .deps/ix86.Tpo -c -o ix86.o ix86.cpp

In file included from ix86_types.h:702,

from ix86_internal.h:21,

from ix86.cpp:37:

implement/xmm/arithmetic.h:75: warning: ISO C++ forbids declaration of ‘ShiftHelper’ with no type

implement/xmm/arithmetic.h:75: error: expected ‘;’ before ‘<’ token

In file included from ix86_types.h:704,

from ix86_internal.h:21,

from ix86.cpp:37:

implement/xmm/shufflepack.h: In member function ‘void x86Emitter::Internal::SimdImpl_PInsert::ByteDwordForms<Opcode>::operator()(const x86Emitter::xRegisterSSE&, const x86Emitter::xRegister32&, u8) const’:

implement/xmm/shufflepack.h:186: error: ‘imm’ was not declared in this scope

implement/xmm/shufflepack.h: In member function ‘void x86Emitter::Internal::SimdImpl_PInsert::ByteDwordForms<Opcode>::operator()(const x86Emitter::xRegisterSSE&, const void*, u8) const’:

implement/xmm/shufflepack.h:192: error: ‘imm’ was not declared in this scope

implement/xmm/shufflepack.h: In member function ‘void x86Emitter::Internal::SimdImpl_PInsert::ByteDwordForms<Opcode>::operator()(const x86Emitter::xRegisterSSE&, const x86Emitter::ModSibBase&, u8) const’:

implement/xmm/shufflepack.h:198: error: ‘imm’ was not declared in this scope

implement/xmm/shufflepack.h: In member function ‘void x86Emitter::Internal::SimdImpl_PExtract::ByteDwordForms<Opcode>::operator()(void*, const x86Emitter::xRegisterSSE&, u8) const’:

implement/xmm/shufflepack.h:259: error: ‘to’ was not declared in this scope

implement/xmm/shufflepack.h: In member function ‘void x86Emitter::Internal::SimdImpl_PExtract::ByteDwordForms<Opcode>::operator()(const x86Emitter::ModSibBase&, const x86Emitter::xRegisterSSE&, u8) const’:

implement/xmm/shufflepack.h:265: error: ‘to’ was not declared in this scope

In file included from ix86_types.h:713,

from ix86_internal.h:21,

from ix86.cpp:37:

implement/jmpcall.h: In member function ‘void x86Emitter::Internal::JmpCallImplAll<isJmp>::operator()(const T*) const’:

implement/jmpcall.h:73: warning: there are no arguments to ‘iJccKnownTarget’ that depend on a template parameter, so a declaration of ‘iJccKnownTarget’ must be available

arcum42

Keep in mind Jake doesn't have a way of testing it. In this case there were several different issues generating the errors. One of them's been taken care of. The ones remaining were:

1) It doesn't like line 75 of arithmatic.h. I'm assuming it's not inheriting something correctly. That's the main one I was having problems with.

2) 3 imm's in shufflepack.h were missed. (And why do I keep wanting to type 'shufflepuck.h'?)

3) Lines 259 and 265 look like they were copied and pasted without adjusting the variables to account for different parameter names. Trouble is, if I substitute 'dest' for 'to', then it doesn't like the variable types...

Jake.Stine

Me: "Fix some GCC compilation errors."

Zey: "Are you sure that it's fix linux build? For it it's not true:"

I used the word "some", not "all." I did so intentionally, because I am in fact really smart.

arcum42

No argument here. :)

Revision 1038

Added PMADD/HADD/INSERT/EXTRACT instructions, and fixed more cross-compiler

problems.

arcum42

That wiped out the original errors. Now, to deal with the errors it never got to because it halted on the original ones... :)

arcum42

Which I'm taking care of right now. Just a few function parameters that should have been const...

arcum42

And that's committed...

junr...

Hi, Jake

I test some games, all games's graphic has big errors, primary the light

process, for example, the fatal frame is almost daylight. and the DQ8 seems

has HDR effect......

Wagnar...

@Jake.

This commit is the one giving me wierd/corrupt graphic in some games.

Jake.Stine

Ah, doh. Found the problem. I inverted some instances of "from" and "to". My next commit (in a while) should fix it I hope. Thanks.

Autor...

Causes texture lightning bug in GoW Kratos and all characters are white

ItsAGraf...

ICC is OK now!

Revision 1039

Linux: Fix the last of the GCC compilation errors.

arcum42

Got to love the error message this fixed:

ix86_legacy_sse.cpp: In function 'void SSE_MOVMSKPS_XMM_to_R32(x86IntRegType, x86SSERegType)':

ix86_legacy_sse.cpp:271: error: invalid initialization of non-const reference of type 'x86Emitter::xRegisterSSE&' from a temporary of type 'x86Emitter::xRegisterSSE'

I figured it out, but plain english by gcc would have been nice... :)

Jake.Stine

And, as is obvious now, msvc compiles it fine. :p

That was btw the first ever msvc/gcc C++ error I had to resolve, a couple yrs ago on another project -- and it is again another totally asinine imposition by the ISO C++ Standard Committee that has absolutely no sane purpose, except that they arbitrarily decided that having non-const temporaries would be potentially confusing or lead to unintended consequences in the most obscure of situations. Yet they still allow this, even though the compiler is fully capable of resolving it as being retarded:

int& ReturnJunk()

{

int i=5;

return i; // lets return a reference to a stack variable. That's safe!!

}

(the standard has a justification for why this is still allowed, but my brain, in an attempt to maintain its own health and sanity, culled it from my memory banks)

Jake.Stine

For the record, those particular cases should have been const anyway, since the called function performs no modifications. But there are other cases where having non-const temporaries could be very handy:

MyJpeg = LoadJpeg( CreateBinaryStream( SrcFile ) ); // fails because a BinaryStream object is inherently non-const, since it has to maintain read pointers and junk.

arcum42

Yeah, I kind of wish that there was a non-standards compliant fork of gcc. Or that a lot of the more pedantic, we're-breaking-this-to-comply-with-standards stuff would be disabled when you use -fpermissive. (Which we have to have on to get this to compile anyways...)

This is improving my C++ skills, at least. I have a tendency to treat C++ like C, so I end up not being sure of the ins and outs of a lot of the more advanced features.

The way C++ is set up really makes me wish for the flexability and simplicity of Ruby, too. (Not the speed, though...)

Revision 1040

Protect manual pages again after running code in them for a while, should speed

up some games and probably not significantly slow down any.

Related new speed hack, fast-forward a block starting at 0x81FC0 which some

games (FFX) run a lot. This block is also excluded from the previous feature.

Rearrange configuration file and speed hack dialog.

sudonim1

Also: break linux compilation, but that's standard.

sudonim1

Er, and first change was primarily to fix persistent slowness when booting games from the BIOS. Forgetting things in commit messages is another good reason not to make multi-feature commits.

Wagnar...

Impressive Job.

Just 1 note. I got some bad/corrupt graphic in god of war 2 and Bleach blade battlerss 2 and possibly other games. I cant really confirm if this is the problematic commit. THe last working one I've compiled is 1030. And from the look of the others commit, this one is probably the one causing it.

arcum42

The Linux break will be easy enough to take care of, though. It's just that the changes to windows/HacksDlg.cpp & WinSysExec.cpp need to be made to Linux/HacksDlg.cpp & LnxSysExec.cpp as well. And there's a reason why the file names are so similar.

And, of course, I need to alter the dialog box to add the new hack.

I'll take care of that pretty soon.

It's a lot easier to fix then the emitter changes, because templates vary a lot more between platforms.

Jake.Stine

@wagnard: I'd like a confirmation on the gfx regression. Any one of the emitter changes could be causing it, really. Subtle typos in the SSE instructions can result in graphics errors that are specific to certain games and stuff.

Autor...

I see the X3 is gone now

Jake.Stine

X3 is obsolete. It's main purpose for retention was SotC, which gets *much* better results from the VU Cycle Stealer.

Luke.Her...

Final Fantasy XII's graphics got broken with this speed hacks, a huge golden arrow is showed in the airship destination screen xD.

v...

I loose 5-10fps on almost every game because of the missing EEx3 hack

cottonvibes

the EEx3 hack gives false FPS readings.

a game can say its running at 60fps, but its really running at ~50fps for example...

we have too much hacks, so its only natural we start removing the unstable ones.

v...

I mainly make tests on the speed(I don't play games)and I can see if the game is running slower/faster without looking at the fps counter.

Jake.Stine

a) Stop benchmarking opening title screens and menus. kthx.

b) The X3 speed hack even at its best never gave more than 4fps bonus over X2 in-game (it could really speed up menus tho). It's techniclly, theoretically, realistically, logically, and absolutely impossible for it to have ever given more than that for any game that, say, actively renders more than 3 images on screen. And in most of the games that got the max 4fps speedup, the INTC_STAT hack gives much better results anyway, without breaking gfx and stuff. We only left X3 in for SotC which, incidentally, works a lot better with the new VU Cycle Stealer anyway.

c) We've done a public service: Stop using X3, and enjoy games being emulated correctly for once! yay! :D

v...

I'm not talking about menus(Tales of the Abyss for example).The character is moving slight slower without EEx3.And btw the INTC Sync hack makes an infinite loop in KH2 when you're fighting that dragon machine boss(one of the last bosses)

Dhalai.L...

Ok. About the x3 hacks, there were 3 games that x3 really worked nice for me. (Metal Gear Solid 3 and God of War series) The new speed hack indeed give a speed boost together with 2x cycle but it adds some graphic corruption in Metal Gear Solid 3 when the bar is set in the middle.)

kaboo...

Tales of the Abyss hangs with the X3 hack -.-

funny I didn't compile yesterday cause it was getting late but I saw a new speedhack and thought.... maybe the're finally gonna kick the stupid X3 XDDDDD

Jake.Stine

>> Tales of the Abyss hangs with the X3 hack -.-

hehe, yea I was thinking the same thing. It hangs randomly when entering and leaving the world map and battles, iirc. Also, I'm pretty sure the KH2 INTC_STAT lockup was fixed weeks ago. I did fix a bug that caused the hack to hang. Dunno specifically if it resolved the endgame hang on KH2 tho.

Autor...

Well it's great for me that i finally get off X3 hack, +1 for commit

v...

Tales of the Abyss hangs but I don't know from what(I've tried disabling and testing with or without any of the hacks,but it hangs/crash with any of the hacks,if I disable all of them then it's ok but if I enable any of them then it hangs)

And about KH2 and INTC,the state is created with revision that isn't older than r998(I don't remember which rev. exactly I used when I played that game but I'm sure it's not older than r998)

Wagnar...

@Jake

R1038 is the problem.

ny11...

Hi. This rev is a bit faster.

On Tekken 4 you can see some insane corruption.I tried changing EE/VU recs around and it can vary from slight to severe corruption. Virtua Fighter 4 is faster. Also for the 1st time the x2 hack works on all my games it used to slow others while boosting most.

=)

Revision 1041

Linux: Fix compilation, and add in the new hack. I may work on making the dialog

look better in a bit...

Revision 1042

Linux: Clean up the hack dialog in Linux.

Revision 1043

Linux: Minor fix for the hack dialog box.

arcum42

The text wasn't being defaulted properly when you first go in...

Revision 1044

Started consolidating the various Dump routines, most of which are broken, into

one file.

arcum42

This way they are in one place, and it's easier to remember that they need to be fixed...

ramapcsx2

...could be fixed :p

arcum42

It wouldn't be that difficult to fix, really. The main thing is updating the variables, and get it into a nice readable format.

Not particularly high priority, though.

Zeydl...

O'k. So it was you who broke debug build for the first time. iR3000A.cpp should be taken from r1047.

Revision 1045

Fixed a bug from r1038. PMADD and HADD instructions had inverted to/from

fields. >_<

Jake.Stine

I actually spent 8 hors redoing most of the API, only to find out that the mew approach completely broke MSVC's optimizer and linker. Pcsx2 took over 3x as long to compile, and generated totally crap code. But the emitter api was a lot prettier! *cries*

kaboo...

*pet pet* don't cry *smile*

now I can test the new speedhack a little XD

Autor...

Yep, fixed

junr...

Hi,Jake

the fatal frame can't work with zerospu2 (spu2-x works well), no sound and slower. other games have not this issue.

Revision 1046

ZeroGS: Apply Zeydlitz's patch from Issue 174 .

refraction

this needs appling to zerogs dx too i think doesnt it?

arcum42

Yeah, it does, doesn't it? I tend to forget about the non-opengl side of ZeroGS...

ntcong.it

I think Zeydlitz only working on gl part of zerogs...

Anyway, zerogs is Zerofrog's code, so any changes to it must be made by him right ?

arcum42

That code should be the same in both, though.

As far as zerogs goes, while it's zerofrogs code, we had permission to modify it for playground, and all the playground changes to the whole emulator got merged in, including to plugins.

And to keep it in sync with pcsx2, changes are occassionally neccessary. So right now, it's essentially in maintainance mode. I'll make small changes occassionally, to keep everything working and make minor improvements.

But I'm not going to do anything radical to it without his permission...

Revision 1047

Finished the emitter, complete with code cleanups! :) (added last few SSE

instructions, and inserted placebos for some future additions to the x86

portion, regarding xchg/xadd/etc).

heatbla...

Inserted placebos... :") What does that mean?

trigunflame

These revision comments aren't for stupid questions. How many times have various people said that? Look up placebo - it's fairly obvious what he means by it.

arcum42

There were a few minor compilation breaks in gcc on this one, all in moremovs.h. The functions in question seemed to be ones that weren't used yet, so I just ifdeffed them for the moment, with comments as to why gcc didn't like them...

heatbla...

Thanx, arcum42

Revision 1048

Apply r1046 to ZeroGS DX as well. Ifdef a few things from r1047 so Linux

compiles. A few minor changes.

Zeydl...

And there dubug build is brocken too. moremovs.h have additional issue with OpcodeA etc (line 83 and 95).

Revision 1049

Readjusted my Gifsplit nonsense to refix Gradius V videos again, its more the

value i originally wanted it now anyway :P Fixed Issue 176

Nne...

the change in IPU.cpp breaks Star Ocean 3's intro video again.

refraction

yehi know, reopening issue, gonna get someone to revert the ipu change, im quite stupidly mad.

Zeydl...

64? But Gif packets aligned by 128 and it's impossible to get a intersections? Or, maybe you want to adjust something else by such little package?

refraction

thats 128 bits, not quadwords. im just splitting the transfer by a max of 64 quadwords per run. some games (like gradius) start overwriting data as they expect it to have already been transfered, so i cant leave it to the end, but some games check DMA's in strange ways, so i cant just suddenly put all the address pointers and qwc count as if its finished

Revision 1050

Reverted the last GIF/IPU change, as per request.

Timing this stuff is evil :/

refraction

@"$£~"£ just the IPU change! the other was fine!

ramapcsx2

Blame Krakatos :p

Revision 1051

Nothing happened here.

Revision 1052

So.. I got an "unlazy" day, and coded a bit more of my iop dma handler.

It's disabled in the code, so that it wont' affect normal users.

The code isn't working properly yet. Only handlers for cdvd and spu2 are in it:

- the cdvd one doesn't work because of the way pcsx2 handles cdvd currently

- the spu2 one seems to work, but it's not implemented in the plugin interface,

so ATM it's just "faking" it using the old functions.

So really nothing worth testing, just commiting to let people know I'm actually

working on it... with long pauses in between. xD

arcum42

I suppose I should remove the comment I put in by this code asking if it's still being worked on, then... :)

gigaherz

don't worry it's gone ;)

arcum42

Ah, good.

We just have had a lot of dead code in pcsx2, and I'd been trying to establish which dead code should be fixed, like cache.cpp, which is in for reference material, like the virtual memory code, and which code could just be removed.

And with the new dma code, I just wasn't sure how long ago it was started, and if it still was underway...

refraction

cache is a slightly different reason, its our only implementation of the cache, unlike VM where there was already 2 versions of memory management, as its in a seperate file it could probably be left in the repository but unreferenced in the files so it can be removed from the project, at least for now.

arcum42

Yeah, I was planning to leave that in. Things like iPsxMem.cpp, I'd love to take out, but I'm letting Jake take care of it once he thinks we won't need to refer to the VM code.

Come to think of it, we don't need any of those *.asm files any more, do we? Linux uses the *.S files, and Windows just inlines the assmbly. I think those were from the Windows 64 days...

Revision 1053

Moved a few things around. Redid some of the work I did earlier on Hw with the

non-obsolete version of the code. Changed some code not to use defines...

arcum42

Interesting to note that a large portion of the slowdown when disabling the recompilers comes when you disable the shift and branch recompilers...

teamsystemsltd

thats because whenever you branch from the rec, if it branches in interpreter mode it runs the interpreted opcode following it, presumably until the branch test.

arcum42

Makes sense. I'll have to think about that a bit...

Revision 1054

Ok, I lied -- more work on the emitter. I forgot to fix up the Jump/Call api

yesterday and, along the way, did lots of major cleanups. :)

(and broke linux, probably!)

Revision 1055

Save linux from the dastardly deeds of my previous commit, and fix one last

remnant 'i' from the apple-like naming schemes of yesterweek.

Jake.Stine

Yes, I have a working gcc compiler now! unfortunately I can't yet figure out how to make patch work rightly. For really simple patches it was ok, but for the patch of the prev commit it just generated lots of HUNK errors (but no babes *cries*)

So after an hour I gave up and used svn. :p

arcum42

Nice to hear. Though things break between major versions of gcc occassionally, and I know there was a decent amount of breakage between the version I'm on, 4.3, and earlier versions, so depending on your version, I may still have a bit of patching to do.

That's cool, though...

And, yeah, patch is a pain. Usually use a commandline like:

patch -Np1 -i foo.patch

to get it to work. Svn's easier, though. 'svn up' to update, 'svn diff' to see differences, and 'svn ci --message "message"' get me through 90% of my commits.

Jake.Stine

Indeed, the 4.2.4 gcc can't even compile pcsx2 because the -fno-dse option doesn't exist yet. I had to remove it to test, since I can't get my portable_ubuntu to compile most things, and I didn't know if/how I could use apt-get to download a pre-built one.

arcum42

Ah. Must have slipped into assuming 4.3 again. I'll have to put in some logic for that one of these days. I think it wasn't neccessary to turn off that optimization in previous versions, though.

That switch is actually in there specifically to take out an optimization that was causing crashes, as I recall.

Trouble is 4.3 is a little more uptight occassionally then previous versions, though it is generally better, as well.

Oh, and it did actually give me an error in iR5900-32.cpp, oddly. It doesn't like:

xJC( dyna_block_reset );

on line 1647. Which I can understand, as I don't see a xJC function anywhere...

Jake.Stine

It should be defined on Ln 227 of ix86_instructions.h. But it's a template (and admittedly I'm not sure if it has to be, I'm looking into that now), so maybe the template compilation is causing problems on gcc.

ntcong.it

->Indeed, the 4.2.4 gcc can't even compile pcsx2 because the -fno-dse option doesn't exist yet. I had to remove it to test, since I can't get my portable_ubuntu to compile most things, and I didn't know if/how I could use apt-get to download a pre-built one.

Just use sudo apt-get install gcc build-essential :). You will have almost everythings for compile :)

arcum42

Ah, I see it now. My eyes just skimmed over it in the search results.

Error I'm getting is:

ix86-32/iR5900-32.cpp:1648: error: no matching function for call to 'xJC(void (&)(u32, u32))'

And combined with the fact that there was a function named Xcc, that led me to the wrong conclusion... :(

arcum42

Or maybe it's just being fussy. Changed it to:

xJC((void *)dyna_block_reset );

And it seems to be compiling. Lord knows I've had issues with callbacks, void *, and gcc before.

Jake.Stine

Gah. Gcc makes everything so hard. I know that the problem is but it's going to take some fenegalling to fix. I thought the template would be enough, but it's not. >_<

(worst part is I might have to make type unsafe code to circumvent this C++ standard 'feature' ... )

arcum42

Yeah, I remember the fits the Linux plugin callbacks gave me when we converted to C++, for similar reasons.

At least it compiles with that typecast. And I noticed you resolved some compiler warnings that had plaguing the emitter for a while...

Jake.Stine

Ugh, I can't make it so the (void*) isn't required. How lame. Also, on some other things I had to do a paired (void*)(uptr) to get gcc to produce warning free code. Hmm, maybe I'll just make a macro (yuck)... but that'd be more readable than alternatives.

Jake.Stine

Also, I like this when I compile:

-DPACKAGE_BUGREPORT=\"[email protected]\" :p

arcum42

Got it. Change XC to:

template< typename T > __forceinline void xJC(T* func ) { xJcc( Jcc_Carry, (void*)(uptr)func ); }

The const was the problem.

And, yeah, it still has zerofrog's e-mail on it. I never quite felt like putting my e-mail there, and wasn't sure what e-mail to put, so I just left it alone...

arcum42

Make that "change xJC', sorry.

Jake.Stine

removing const fixes it? That makes NO sense :/

arcum42

Yep. Makes very little sense, and if that's what was causing the error, it's silly, but if it works...

Jake.Stine

Yeah.. hopefully won't cause problems later on. I'm not a big fan of leaving off const when it should be implied, since it means later on I could end up being forced to leave const off other pointer vars too, if I end up using them on these functions.

But yeah I seem to vaguely recall reading some inane justification on why functions aren't allowed to have const qualifiers on their pointer type (can't remember if it was a c++ standard doc or a gcc doc tho). It was non-sensical and not based on any reality of programming as we know it (as usual).

arcum42

It's a shame, but that's C++. It seems like it's designed to hinder the programmer more then help them.

Unfortunately, I always find myself wishing for language features from other languages because of it. Wouldn't have minded Ruby's ability to pass code blocks to functions without really thinking about it here...

Jake.Stine

Yeah Java and C# can do the same basic thing. Oh well.

Revision 1056

Remove some consts to appease the gcc 4.3.x gods.

Revision 1057

Linux: A more complete rendition of the GCC compilation fix. Note: GCC requires

non-const qualifiers on function pointers and function pointer-templated

parameters, but not on void* (didn't know they were that different, did you?).

Jake.Stine

I also added some EOLs on some files to get rid of GCC's warning about there not being an EOL at the end of a file. (that's a GCC-specific thing due to the fact that such files are malformed an unreadable on like HP-UX or some other obscure mainframe unix)

arcum42

Probably a good idea. And the warnings are somewhat at a minimum when compiling standardly, btw. If you switch to a debug build, I've set it to show more of the warnings there. (And there were a lot more then there are now when I started; I've gone through and eliminated a bunch of them several times.)

And if you really want to see a nightmare, try taking out the -fpermissive flag sometime. You will *not* be able to compile...

Jake.Stine

Alright, I'll fiddle with it.

MSVC can have a lot of warnings too, but we usually set the warning level to 3. Change the warning level and it spits out a million crazy warnings too, but of course, 99% of them are junk.

arcum42

Basically, the ones showing at debug level are what used to show all the time. One nice thing is that I was able to tell it not to show a number of the more useless ones.

Now the errors you get when you take -fpermissive off are all from code that gcc did not have an issue with then it was in a C file. It's basically code that they *think* you shouldn't be doing in C++, but they'll let you get away with if you define that flag.

Oh, and if you see warnings about unused variables, make absolutely sure they're unused before getting rid of them. There are some variables that come up that way because they are only used in Windows or Devbuilds, or such. I've ran across that one before...

Jake.Stine

Well I failed at getting GCC 4.4.0 to compile. Gave me some stupid error "cannot compute suffix of object" which appears to indicate some missing dependency, but isn't clear on telling me which. >_<

But 4.2.3 seems ok except I'll have to go and remove all those command line options for a dozen files or something, to compile more than the couple subfolders I have set now. Just.. more.. busywork. :p

arcum42

I haven't even tried 4.4.0 myself. It only came out 3 days ago, after all. I've been using the previous version, 4.3.3.

And I would have thought getting it to compile would just be a matter of modifying configure.ac, just commenting out the line right after the one that talks about gcc 4.3.3...

arcum42

Looking, I may have to try out Gcc 4.4.0. From the changelog:

Some of the errors issued by the C++ front end that could be downgraded to warnings in previous releases by using -fpermissive are now warnings by default. They can be converted into errors by using -pedantic-errors.

I'll have to see if -fpermissive is still neccessary on it...

Jake.Stine

I wish I could figure a way to make it compile. I just have no idea what the missing dependency could be... and it has sooooo many. :/

(it gets about 5 mins into compilation before failing .. the fail happens during configuration of libgcc)

arcum42

Don't know; apt-get should have gotten any dependencies for you. It's not in the gentoo repositories yet, so I'm checking to see what overlays I have to get it from...

arcum42

Don't know if this will help, but in the prelease version on Gentoo, this is what they had listed for dependencies, but it was parsed from an e-build, so it's not the easiest to follow. I believe everything in parenthesis is only needed if certain options are enabled. And the package names may be slightly different on Ubuntu.

>=sys-libs/zlib-1.1.4 || ( >=sys-devel/gcc-config-1.3.12-r4 )

virtual/libiconv

>=dev-libs/gmp-4.2.2

>=dev-libs/mpfr-2.3.0 !build? ( gcj? ( gtk? ( x11-libs/libXt x11-libs/libX11 x11-libs/libXtst x11-proto/xproto x11-proto/xextproto >=x11-libs/gtk+-2.2 x11-libs/pango ) >=media-libs/libart_lgpl-2.1 ) >=sys-libs/ncurses-5.2-r2 nls? ( sys-devel/gettext ) )

test? ( >=dev-util/dejagnu-1.4.4 >=sys-devel/autogen-5.5.4 )

>=sys-apps/texinfo-4.8

=sys-devel/automake-1.9*

>=sys-devel/bison-1.28

>=sys-devel/flex-2.5.4

>=sys-devel/binutils-2.18

elibc_glibc? ( >=sys-libs/glibc-2.7-r2 )

sys-devel/gnuconfig

>=sys-apps/sed-4

dev-util/subversion

net-misc/rsync

Jake.Stine

yea well I don't know how to make any of that junk work anymore. Apt-get just tells me nothing is found if I use anything other than major package names (ie I can't specify versions, so getting odd-number devel versions of stuff isn't really possible).

Back in the old days I honestly had an easier time with linux, when everything just required I download the source, ./configure, and make/make install. But dependency chains have grown so complicated that it's unrealistic anymore to do that. -_-

arcum42

I'm not that great at apt-get myself, partially because I've gotten fairly used to the way Gentoo does it, which is a bit different. And 4.4.0 only came out a few days ago, so there isn't much online.

But I've tried Linux from Scratch, so I've done the whole download, configure, and make, make install thing.

I know you said Ubuntu, but I believe you said it was some portable edition. Are you using wubi or what version are you using?

Jake.Stine

http://portableubuntu.demonccc.cloudius.com.ar/

Runs via CoLinux. :)

I'm not expecting to really be able to run pcsx2, but it allows me to run GCC in a true linux environment and get all the warnings and errors first hand. Assuming I can get it to the point where it's happy enough to compile crap.

arcum42

Cool. I'll take a look at it from Windows and see what I can figure out. It's easier to figure out what quirks a system has when you're actually using it.

For that matter, wonder if I can run it from Wine. :)

Jake.Stine

Alright, good news. Looks like I was missing bison and texinfo, and things seem to be compiling now. It'll of course take a long while before it's done tho, so I'm not going to hold my breath.

Jake.Stine

Bah it error'ed out just as I posted that. Same deal. "cannot compute suffix"

Jake.Stine

Ok, more updates. I had mpfr installed but it wasn't finding it, as it turns out. So now I'm *pretty* sure I have the suffix issue nailed. Now to wait a couple hrs or whatever and see if it finished through or comes up with more oddball errors ;)

arcum42

Cool. We'll see what happens. In the meantime, I'll check out the portable edition on my side.

And I can tell you that if you like compiling things from source, Ubuntu's not really the best distribution for you. The one I use, gentoo, when you tell it to install something, downloads, compiles, and installs the source for you...

arcum42

In case you're curious, I downloaded it, started it up, and went into Synaptic, checked all the repositories in the preferences, refreshed, and told it to update everything. Once it's done with the 203 packages or so its updating, I'll see what I can figure out about 4.4.0.

arcum42

After doing that, I actually had to expand the size of my coLinux hard drive file; fortunately, the FAQ tells you how to do that.

Looks like the proper way Ubuntu to install it is to go into software sources -> third party software, add all the Jaunty repositories:

deb http://us.archive.ubuntu.com/ubuntu/ jaunty main restricted universe multiverse

deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe multiverse

Then add the third party repositories with gcc 4.4:

deb http://ppa.launchpad.net/ubuntu-toolchain/ppa/ubuntu jaunty main

deb-src http://ppa.launchpad.net/ubuntu-toolchain/ppa/ubuntu jaunty main

Got those from here, btw:

https://launchpad.net/~ubuntu-toolchain/%2Barchive/ppa

Ignore the complaints about not being signed. I didn't bother to add the keys. But if you hit refresh gcc 4.4 and g++ 4.4 will be in the list, and you can install both.

This is mainly for reference, since you already figured out another way to do it...

Jake.Stine

>> After doing that, I actually had to expand the size of my coLinux hard drive file; fortunately, the FAQ tells you how to do that.

Yeah you need at least 6 gigs just to install/compile GCC. And you need at least 640 megs of total memory also (my install defaulted to 512 -- 256phys/256swap), otherwise the final link stages will fail.  ;)

arcum42

Yeah. I managed to get pcsx2 and all the plugins installed, so my copy of it is about where yours is; the gui launches, all the plugins are there, and ZeroGs dies when you try to start emulation.

It's probably because of the interface between Windows and X11, since it was acting like I didn't have a good enough video card.

Jake.Stine

To make OpenGL work you need to use a fancier commercial x-window server/client like Exceed. Using that I've been told, can actually work half decent (tho maybe not for pcsx2 because it has to do so much dynamic texture uploading).

Not a major concern to me since I can test games to my hearts content with a windows-native exe, and it's (mostly) assured to work the same (notable exception being, ironically, the exception handler) -- but working with the wxWidgets gui and stuff is a different beast.

arcum42

True. It just would have been nice for the occassional bizarre differences between Linux and Windows, like Star Ocean.

It'll be useful for testing compiling, though, and that's all you really need it for...

Revision 1058

Break up very long recompiled blocks.

Perform a branch test before jumping to the next block.

sudonim1

Ahaha, didn't realise this until after, but this actually fixes an uncounted cycles bug and speeds up games a little.

AntiS...

Ground texture flickering bug in Persona 3 also seems to be fixed. Way to go.

cottonvibes

AntiSoul: i believe that was fixed by Gabest a while back.

Revision 1059

microVU:

-fixed problems with branches jumping to incorrect addresses

-finished implementing clip flag instances

-started adding operand info to logging (also logs branch jump-to addresses)

ramapcsx2

Programm dumps are looking very good now. You decode exactly what the code says.

Still renders nothing though, except for some SPS in arc the lad (which is an improvement ;) )

cottonvibes

heh, SPS is indeed better than nothing xD

Revision 1060

Nothing much to see here: Removing obsolete NewBM tag made when we did the

Pg->Official port.

Revision 1061

Branching so i can work on the dmac and commit progressively, given the changes

will make many plugin interfaces incompatible (already the case for spu2).

Revision 1062

Current changes. Spu2 and Sio2 are updated to use the new dmac. currently spu2

seems to be broken.

arcum42

Looks good. Of course, ZeroSpu2 will have to be tweaked to match. Good thing I combined the Dma4 & Dma7 routines in it a while back.

I actually started work on a new interface to the plugins a while back, too; I just never hooked it up. If you look at Pcsx2Api.h, Pcsx2Defs.h, Pcsx2Types.h, and the api folder in common/includes, that's what I'd done so far...

gigaherz

Heh well, IMO, if we have to change the plugin interface "properly" I'd rather stop using many exports, and instead export one function which would return a struct with function pointers, and even started working on it, but at the moment there were so many changes going on that I'd have had to remake all of it again, so I dropped it (at least for now).

arcum42

Not a bad idea. When I committed the new interface, I basically made some changes I wanted to make, then left it with the intention that basically, anyone who wanted to make other changes could before we eventually finalized it.

Main changes I made were:

I separated out a lot of the stuff that was just lumped together in two files into several. The idea was that you just include whichever file in the api folder is appropriate for the plugin. And I actually like the new separation a lot better on the pcsx2 side as well; seems a little more intuitive.

I added a function to export the location of the ini folder to the plugins. Right now the plugins are basically guessing that their in the correct directory, and I've had to browbeat them into saving in the right place before on the Linux side. It makes it more flexible, anyways.

A few plugins gained the ability to freeze and respond to keystrokes. (So that you can, for example, control the volume from the keyboard).

And I combined the dma functions on the spu2 plugin side. :)

Oh, and ChickenLiver made some revisions to Sio, both there and in the current api. Though you may have already noticed that...

ramapcsx2

Replace:

"

if(MinDelay<0x7FFFFFFF)

SetDmaUpdateTarget(MinDelay);

else

SetDmaUpdateTarget(10000);

"

with:

SetDmaUpdateTarget(1000);

to fix lots of freezes ;)

gigaherz

that's like killing ALL THE TIMINGS, basically.

if you want to try diff timing factors, look at the BCount/2 :P

cos I dont' have a damn clue about the iop dma timings maybe it should be /8 or *4 or something like that, but if it's too small or too big, it woudl be unrealistic.

Jake.Stine

if((Cores[core].IRQA>=Cores[core].TSA)&&(Cores[core].IRQA<(Cores[core].TSA+0x20)))

... shouldn't that be TDA+0x20?

Also, +20 should only be on DMA reads, not DMA writes. Doing +20 on write like that breaks lots of games.

gigaherz

Oh makes sense, shitty memory. I thought it was 0x20 on writes, and 0x1 on reads, guess it's the other way around then xD

gigaherz

... and no it's not TDA, cos the "final" value is already in TSA by then, TDA is basically used as a temp variable as it is now, just I was too lazy to remove it from the struct xD

ramapcsx2

if(MinDelay<0x7FFFFFFF)

SetDmaUpdateTarget(MinDelay);

else

SetDmaUpdateTarget(768);

Better?

You can't go above 1000 for the second part, causes freezes in like all streaming stuff.

Changing BCount/2 to something else doesnt help :p

Revision 1063

Rough draft of wiki page added through web interface.

arcum42

I thought I'd be a good idea to actually have Linux compilation instructions up.

Jake.Stine

Well you thought wrong. I demand an immediate reversion of this commit!

In other nearly related news, I noticed the the linux version of pcsx2 fails to find my rom1/erom files. I guess the path concatenation logic isn't totally linux-friendly after all. It'll prolly be fixed in the wx branch though, since it's being switched over to entirely wxFileName based.

arcum42

If I think about it, I might even fix that in the main branch. It should be easy enough; I was just so used to the warning, it didn't occur to me...

Revision 1064

New Iop Dmac: Fixed the problem that killed the dmac timings beyond repair.

Ateliere Iris now doesn't choke to death anymore, but wild arms still doesn't

boot. Also fixed the IRQ over-read thingy in spu2, so it's done on reads, not

writes.

ramapcsx2

I got WA5 booting earlier with "SetDmaUpdateTarget(768)".

It doesn't work on this version anymore though.

(And guess what it did when it booted? Yep, the old freezing again :/ )

OTOH this here indeed fixed the freezing streaming audio in many games.

-BIOS still doesnt boot

-Star Ocean 3 has sio issues, memcards die on larger reads

Revision 1065

New Iop Dmac: Fixed another timing issue.

kenzozus...

Can't build SPU2-X

1>..\spu2replay.cpp(129) : error C2660: 'SPU2irqCallback' : function does not take 3 arguments

1>spu2replay.obj : error LNK2001: unresolved external symbol [email protected]

1>spu2replay.obj : error LNK2001: unresolved external symbol [email protected]

1>spu2replay.obj : error LNK2001: unresolved external symbol [email protected]

1>spu2replay.obj : error LNK2001: unresolved external symbol [email protected]

gigaherz

Yeah, I know... it's WIP code so I always run in debug/devel mode within vstudio, you will have to manually "exclude from build" the spu2replay.cpp file (it's in Source Files / debug), or wait until my next commit.

Revision 1066

New Iop Dmac: I have been too much time without coding spu2-related stuff.

Forgot that the Memory Access IRQ has a flag to EANBLE it (or disable).

Revision 1067

New Iop Dmac: Stop crashes on grandia extreme, and any other game which dmas

past the end of the spu2 memory.

Ami.Mizu...

This is still WIP code I suppose so games may have more bugs than normal still or?

gigaherz

Yep, that's why it's in a branch, and not directly in /trunk/. When it gets fully implemented and working appropiately, it'll be merged into /trunk/ for everyone to enjoy.

Revision 1068

New Iop Dmac: (Call me commit-whore or whatever, but I'd rather keep a history

of my changes)

Fixed what probably was a bug in my sio2 handlers, because I'm not sure about

it, I rather have this in a commit on its own.

Also changed a bit of the spu2-x dma code to use "thiscore" references, and

renamed all the "thiscore" references to "thisCore", cos it looks nicer this

way.

Jake.Stine

I think you just want to get to 2048 faster so that you can do something special for crossing into the 11-bit range. ;)

gigaherz

HAHAHA, lol xD not rly, but that's a fun idea actually.

Actually it's more like i dont' trust my own memory, so id' rather have a step by step history of what i changed, so i know if i fucked up somewhere in the process, and what did i do.

Jake.Stine

Also, not that I really care much either way really, but if you (or anyone else) wants to keep some rollback/reversion stop points prior to testing another change, you can create a patch of your current changes. And afterward, if the idea doesn't pan out, revert your code and re-apply the patch.

I do that a lot for code that's more or less broken (so I don't want to commit it) but needs to be retooled in a significant manner to get it the way I'd like.

Jake.Stine

... but of course when it's in a branch it doesn't really matter if the code is semi-broken or not. So being a commit whore is acceptable. :p

cottonvibes

so when giga gets "unlazy" he turns into a "commit-whore" :p

gigaherz

pretty much yeah

gigaherz

[and it seems I also a double-poster...]

basically my reason is: my memory sucks, so I dont' know when will I forget whe I did before, so I better keep a history I can check, and also I never know when will I lose my unlazyness, so I better commit often so that there's as few uncommited changes as possible.

arcum42

No problem with that; just glad this code's being worked on.

Just as long as we have it working with ZeroSPU2 before it's merged, anyways...

Revision 1069

wxGui branch: Holy crap! I converted it to unicode! This was an absolutely

maddening experience. [also: Merged with /trunk]

Jake.Stine

Hi ho, Hi ho. It's off to linux I go.

Revision 1070

microVU:

-Finished operand logging, so microprogram logs are very detailed.

-Apparently XGkick specifies the address divided by 16 (thats how zerorecs

handles it), so now microVU does the same thing.

-Zerorecs also saves '(PC+16)/8' instead of 'PC+16' in BAL/JALR instructions, so

I did the same with microVU...

ramapcsx2

Arc the Lad now has it's blue background back. The SPS look the same still.

At this point I'd be glad if it showed a few more of those.

It looks like they originate from about 10 polys only :p

Anyway, the logging will help lots.

Jake.Stine

Wow, html logging. That's exceedingly fancy.

Revision 1071

pcsx2:

- fixed the 5 warnings in hacksDlg.cpp

microVU:

- major changes to microprogram logging. logs are now in html format with color-

coding, hyperlinks to branch addresses, horizontal rules separating blocks,

etc...

- made mmx reg usage for VI regs toggable (off by default now)

- minor changes

Nne...

You removed SUPERVU_XGKICKDELAY from zeroRec? Why?

refraction

I was just thinking the same thing, it is commented to why its needed :p

ramapcsx2

Prolly slipped in? :p

cottonvibes

the SUPERVU_XGKICKDELAY change was slipped in by mistake. :p

forgot to uncheck iVUzerorec.cpp :(

Revision 1072

wxGui: Doesn't *quite* compile in Linux, but it's close.

Jake.Stine

DevCon::WriteLn( Color_Cyan, g_pbuf );

DevCon::WriteLn( Color_Cyan, "%s", params g_pbuf );

Either of these should work fine, with the first one being more efficient/direct. Does GCC generate a warning/error for it the first one?

arcum42

Oh, it thought it was "ambiguous". As with a lot of these things, the more verbose it is, the better gcc likes it.

IopHw.cpp:673: error: conversion from 's8 [1024]' to 'const wxString' is ambiguous

/usr/include/wx-2.8/wx/string.h:692: note: candidates are: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:682: note: wxString::wxString(int) <near match>

Jake.Stine

Crap, that's a problem with wxWidgets code. :(

I'm also having similar ambiguity issues with the wxCharBuffer on MSVC (dunno yet if gcc has the same problem). Although in this case I'm really not sure how "s8[1024]" is even a 'near' match for (int). It's an array! How can it match to an int? >_<

arcum42

Perhaps it thinks we want to print out an array of numbers rather then a string? I don't know. GCC just likes to find any possible misinterpretation of things and complain about it.

In case you're curious, the errors I left it with were:

AppConfig.cpp:92: error: conversion from 'const wchar_t [11]' to non-scalar type 'wxFileName' requested

AppConfig.cpp:92: error: conversion from 'const wchar_t [11]' to non-scalar type 'wxFileName' requested

and this one:

main.cpp:125: error: no matching function for call to 'AppConfig::LoadSave(IniLoader)'

./../Config.h:187: note: candidates are: void AppConfig::LoadSave(IniInterface&)

main.cpp: In member function 'virtual int Pcsx2App::OnExit()':

main.cpp:138: error: no matching function for call to 'AppConfig::LoadSave(IniSaver)'

./../Config.h:187: note: candidates are: void AppConfig::LoadSave(IniInterface&)

Once I got to the latter, I just decided I'd rather deal with it when I was more awake and committed what I had...

Jake.Stine

Actually I'm wrong. There are two versions of WriteLn now. One takes wxString, and one takes char*. wxString deals in wchar_t only (aka wxChar in unicode), and so there is no suitable match for char[] -> wxString conversions.

So in this case gcc has failed to determine char* as a match for s8[1024] (wtf?), and is instead intent on using wxString instead, for which there is clearly no suitable match. -_-

arcum42

Yeah, and wxT doesn't work on variables, so I figured this was the easiest way around it.

In any case, I'm off to bed...

Jake.Stine

The problem is fixed by changing s8's to char, or by changing our s8 typedef to be 'char'. Turns out that 'char' and 'signed char' are not interchangeable types, and currently:

s8 is a typedef for int8_t, and int8_t is a typedef for signed char.

As far as we can tell this is some kind of provision for 1's compliment cpus (and no, there haven't been any made in a long long time as far as we can tell).

Jake.Stine

Just so you know, I have most of the errors fixed now on my end. I'm just fiddling around with some other little things and cleanups, and will commit within an hour or two.

Revision 1073

Fix xgkick delay mistake

cottonvibes

hurray ;p

ramapcsx2

Awesome work, eh?

Go me! .. lol :P

Revision 1074

GSdx: fixed Issue 182 (narrowed the neq alpha test range to +/-0.4f/255, scream

if something broke), and re-enabled something to make DATE faster (counting

min/max of the vertices outperforms stencil buffer clearing when there are many

small primitive batches).

gabest11

damn, commited my old vcproj...

Autor...

Why have you deleted DVD9 NTSC GoW Crc?

Autor...

Sorry CRCs on place but game's green again

Autor...

Very sorry again just started the game from run->Execute, normal start if fine

toammar2...

Thanks Gabest .... It Is work Fine

Revision 1075

GSdx: just restoring the vcproj from two revisions ago...

zantezuken

Hmm...

Sadly, it doesn't fixes Castlevania shadows issue.

But, I guess, it shouldn't, lol.

gabest11

not really :P

zantezuken

No, lol, I don't mean GSdx_vs2008.vcproj commiting, I mean previous rev changes, lol >_>

ramapcsx2

Speeds up a few games, but breaks breath of fires dq menu items :/

Tested a whole lot of hard to render games, and all the others are fine.

GS dump for the bof bug:

http://www.sendspace.com/file/8zkoi8

Hope you can solve this one ;)

Revision 1076

GSdx: more alpha test magic

ramapcsx2

Yep, fixed BoF.

That was quick :)

Jake.Stine

maybe you can code it with like "clip( rand()*0.8/256 ..." then you can just put a clause in somewhere "if image is missing geometry, restart emulation repeatedly until it works."  ;)

gabest11

lol

kaboo...

O_o rofl jake, feeling evil today? XD

junr...

FF12 optimization version?? FF12 speed increased 15~20%.....

now it is almost fully speed on my N6600 video card, nice work.

but other games no change....

gabest11

ff12 also uses DATE on the character shadows, that's faster now

Dhalai.L...

Nice job then. :)

Revision 1077

microVU:

- fixed a bug in the logging system causing incorrect branch-to addresses.

ntcong.it

I don't know much about your code yet. But will microVU work when I comment out the two define in Pcsx2Config ?

I can say that it boot fine in FFX, but the graphic is...not fine, we still need, err, more stuff :D, but anyway, great works

Revision 1078

wxGui Branch: [Linux] Fixes for various warnings and errors.

Jake.Stine

Because of some complications inherent to how gcc does things, I'm going to "flatten" some of the directory structures in places. The first one was the NewGUI folder. I've noticed that it just makes it a lot easier to get header file references to resolve correctly, and thus should help simplify the build system.

Jake.Stine

Gah! Just to complicate things, I'm using CodeBlocks now (and it's really nice), but it *wants* code divided out into folders. It works better that way. So I'm thinking I might revert on my idea of flattening directories and do the opposite and add a little more depth.

Admittedly I like the idea of having a bit more folder depth. Drives me nuts for example having all the EE/IOP/DMAC(vif/gif/sif) stuff in the pcsx2 main folder. I haven't done it up to now because I've known it'll cause havoc on the already messy header include problems on linux. But so far using codeblocks I've had none (I was in fact able to set it up much the same way I configured the MSVC side, so that it dynamically figures out the SvnRoot and ProjectRoot, and sets all the necessary include folders from that -- only ends up being like four in total).

Jake.Stine

Omg! I got it compiling and running in linux! I did it, I did it!

Master! The Plane! The Plane!

... most of the existing dialogs look like crap though, and the ini file location picker prolly needs work too. But besides that, it compiles and runs. I'll sort it out and get it committed momentarily.

ntcong.it

Oh my, great works Jake.

May I expect a Pcsx2's wxWidget release in next few days :D

arcum42

I'm all for folder depth, really. It was just frustrating trying to tweak the autobuilds sometimes. Especially since having the common folder on a lower level then the actual makefile was really messing with things...

Revision 1079

wxGui branch: [linux] Added workspaces and projects for Code::Blocks IDE. Main

workspace is currently located in pcsx2/linux/ (will move it to a top level

later), and only Pcsx2/zlib projects are tested (and working!). Haven't gotten

to any plugins yet.

The CodeBlocks project is tested for Debug builds only, and will generate the

executable binary to /yoursvnroot/bin/ [same as the MSVC/Win32 build does].

* Note: The 'regular' build script is currently broken and I haven't a darnedest

clue how to fix it, since my knowledge of Automake doesn't extend past the end

of this sentence.

Jake.Stine

I also fear that I may have broken Win32 builds with this commit. I'm too damn tired to test it. It'll have to wait until tomorrow. :P

I'm out for the next 6 hrs!

ntcong.it

Hey, I can say that Pcsx2 still compile and run fine in Vista, I wonder if it help you something.

No dialog work yet :), only the Patches dialog

federelli

Code::Blocks at last!! :D

arcum42

I'll try to fix the build scripts, but honestly, if we're using Code::Blocks now, I won't worry too much about it. We could always just require use of Code::Blocks. I wasn't too happy with the current build system anyways, and if using Code::Blocks works better, I'm all for it.

Jake.Stine

I tend to agree. Code::Blocks just makes it very easy to compile a project like pcsx2 (since pcsx2 really doesn't need all the cross-platform fanciness of Configure anyway), and it's not a bloated dev tool. A full installation [minus the dev/debug build stuff] was like a ~6 megs download or something.

I wouldn't mind having an IDE-independent makefile still, but the current automake system has issues with resolving header files correctly, which complicates its setup considerably .. and I think it'd have to be redesigned from the ground up to fix that.

Revision 1080

wxGui branch: [linux] Added soundtouch and bzip2 projects for Code::Blocks, and

fixed up Release mode build targets for pcsx2/zlib.

Revision 1081

wxGui branch: [linux] Minor fixes to the GUI -- Ok/Cancel buttons line up where

they should now. :)

CodeBlocks Project Changes:

* Fixed some absolute folder specifications (/home/pubuntu/) which went

unnoticed.

* Enabled Precompiled header support (speeds up compilation about 40% for me).

Revision 1082

wxGui: Start work on a Speed Hack dialog. Update the Game Hack dialog.

arcum42

As you can probably tell, not everything is working in the new dialog box yet.

I wanted to get it in place, though.

Jake.Stine

Also! Pseudonim pointed out that codeblocks has a makefile exporter. Haven't had a chance to pay with it to see if/how well it generates working makefiles, but it might be a nice easy way of giving people access to makefiles that are not dependent on codeblocks.

arcum42

I'll have to look at that. I'd like to leave some way to compile it from a command line for Linux distributions that are source-based.

And I did all the work on this commit in codeblocks, btw. It isn't that difficult of a transition; the editor widget that codeblocks uses is scintilla, and Scite, the text editor I have been using, was originally developed to demonstrate scintilla.

arcum42

And the main things currently wrong with the speedhack dialog, incidentally, would be that the sliders won't move, the text below them doesn't change, and the text on the right isn't lined up well.

Since the dialog boxes aren't exactly hooked up yet anyways, not that big of a deal.

Revision 1083

Merged drk||Raziel's "BTS Manual Protection" enhancement for the vtlb into

/trunk, and combined it with Pseudonim's "Manual Block Clear" enhancement for an

ideal two-phase protection system.

Most things should be a bit faster with this new system. The system is more

balanced than the previous one, in that it provides a better overall performance

across most games, but some specific FMVs (like Disgaea 2's) will be a bit

slower. On the other hand, others like DQ8 and Kingdom Hearts 2 FMVs get a big

speedup. Almost all in-game stuff should be either the same or faster now.

Set a bunch of ignores for TortoiseSVN users, as suggested in Issue 166 .

junr...

Great big revision

Zeydl...

Could I ask you to use unix slashes in includes :-).

arcum42

Already got it...

masataka...

Load Star Ocean 3, run into some monster so that battle stuff loads -> crash (TLB miss).

100% reproducible.

Doesn't happen with r1083, does still happen with r1088.

Revision 1084

All right, now that's just silly... (Fix Linux compilation.)

arcum42

I could have just fixed the include, but since it wasn't actually neccessary...

Jake.Stine

oh that slipped in from the merge. Drk does everything in his power to break linux. :p

arcum42

I've noticed. :(

This was one of these cases where it took me more time to shove aside all the minor changes in my local copy then to make the commit, though. Since I'd been focusing on wxGui for a bit, forgot I had any.

I was planning to do the Advanced dialog next, but got sidetracked. I should probably fix up those sliders first, anyways...

Jake.Stine

You should see the code branch I merged.. Drk added windows.h to a couple files, added GetAsyncKey() to the Iop Counters, etc. Just loads of Win32-specific everywhere. :p

arcum42

Yeah, I've looked at the vtlb-exp branch, which started off with a commit that said "This breaks Linux", and has Windows stuff everywhere. I saw that commit just after having woken up within half an hour or so, and thought it'd been done to the main branch, and had a whole bunch of work ahead of me.

Realised I was wrong within an hour or so, but not before making a comment to refraction about it (That was about the time we were both doing all sorts of Vif Unpack changes)...

Revision 1085

Bugfix for r1083. [Don't ask me what I was thinking when I wrote >>10 instead

of >>12]

Revision 1086

Improved SSE detection:

* SSE3 detection via cpuid implemented. [fixes Linux -- the force_sse3 option

should no longer be needed!]

* Instruction tests are now done for SSE3, SSE4, and SSE4.1 to confirm cpuid

results (I doubt this is necessary, but the old code did it for SSE3, so I

figured I'd keep it and log results anytime an inconsistency is detected).

* SSE4.2 and SSE4a detection added.

Jake.Stine

Linux still can't do instruction tests, but they shouldn't be necessary anyway, so I think we're fine to ditch the forced SSE3 thing entirely. :) CPUID should like never be wrong, and if it is then the cpu in question is defective and probably not something we should be debugging our code for anyway. ;)

Jake.Stine

Also the SSE4 was supposed to read: SSSE3. There is no such thing as SSE4. Yay, just more confusion to add to the rift of SSSE3. >_<

arcum42

Mostly looks good, but something's a bit funky with the cpu clock info. Here's what it looked like before for me:

x86Init:

CPU vendor name = AuthenticAMD

FamilyID = 2

x86Family = AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

CPU speed = 2.902 Ghz

Cores = 2 physical [2 logical]

x86PType = Standard OEM

x86Flags = 178bfbff 00002001

x86EFlags = ebd3fbff

Features:

Detected MMX

Detected SSE

Detected SSE2

Detected SSE3

Not Detected SSSE3

Not Detected SSE4.1

Extended AMD Features:

Detected MMX2

Detected 3DNOW

Detected 3DNOW2

and here's what it looks like now:

x86Init:

CPU vendor name = AuthenticAMD

FamilyID = 2

x86Family = AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

CPU speed = 1.742 Ghz

Cores = 2 physical [2 logical]

x86PType = Standard OEM

x86Flags = 178bfbff 00002001

x86EFlags = ebd3fbff

Features:

Detected MMX

Detected SSE

Detected SSE2

Detected SSE3

Not Detected SSSE3

Not Detected SSE4.1

Not Detected SSE4.2

Extended AMD Features:

Detected MMX2

Detected 3DNOW

Detected 3DNOW2

Not Detected SSE4a

arcum42

And, for reference, here's my real cpu info:

# cat /proc/cpuinfo

processor : 0

vendor_id : AuthenticAMD

cpu family : 15

model : 107

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

stepping : 2

cpu MHz : 2900.235

cache size : 512 KB

physical id : 0

siblings : 2

core id : 0

cpu cores : 2

apicid : 0

initial apicid : 0

fpu : yes

fpu_exception : yes

cpuid level : 1

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch

bogomips : 5800.47

TLB size : 1024 4K pages

clflush size : 64

cache_alignment : 64

address sizes : 40 bits physical, 48 bits virtual

power management: ts fid vid ttp tm stc 100mhzsteps

<repeated a second time for the other core>

Ami.Mizu...

Well PCSX2 CPU clock speed detection has always been a bit off and also got the typical problem many other software have, it reports my overclocked CPU as 4.5GHz rather than 4.0GHz due to I'm using 8x CPU multiplier and not the default 9x. But these are things that doesn't matter IMO. :p

arcum42

Quite true, and I just realised that I still have some funky stuff I need to undo in my local copy, anyways, so that might take care of it. We'll see.

Jake.Stine

I tried to speed up the cpu clock detection, but I didn't think about it too hard.. just reduced the test time from 1 second to 0.6 seconds. I forgot to change the fractional divisor to accommodate.

What Pcsx2 measures is your CPU's actual instruction throughput, as according to your rdtsc. But really for it to work well it needs to have single-core processor affinity and stuff (which we don't do).

arcum42

2900.235 * 0.6 = 1740.141, so that sounds about right.

And I'm undone all my funky changes. I was testing a few things with all forceinlines turned into regular functions...

Revision 1087

Fixed a bug in the cpu mhz detection introduced in the prev revision, and

improved the algo to be much quicker and generally more accurate than before

(and with luck AMDs will agree!)

arcum42

Looks good. 2899 Mhz is close enough to 2900 Mhz in my book...

ramapcsx2

Also works fine on my cpu. Startup is lots faster :)

Revision 1088

Get rid of duplicated code in PS2Etypes.h. :)

arcum42

Oh, and I got rid of the force options in the configuration, since Jake's changes made them unneccessary.

arcum42

Hmm... an extra */ crept in. At the end of a line that's commented out with //, it should be harmless, though.

arcum42

I also accidentally reverted the change to jASSUME. That'll be taken care of.

Revision 1089

Fixed bugs in BTS instruction emitters, and working on fixing bugs in BTS memory

protection.

Revision 1090

Some unpack fixes/changes

Revision 1091

Reverted BTS due to unexpected complications, but retained a minor optimization

we developed during the BTS experiment. :)

Revision 1092

Darned fungly header file dependencies, broke compilation in dev/release builds.

>_<

Revision 1093

*experimental* Added forced block splitting at 4k code boundaries in PS2 memory.

This fixes issues with frequent recompilation of certain uncounted manual

blocks, and also allows for us to greatly simplify the memory protection and

recompiler block management code, but *may* have performance penalties under

specific conditions. So I've added a verbose log message to Devel builds so

that we can look for any problem games that might invoke more than their fair

share of tiny block splits.

gabest11

if (startpc != 0x81fc0 && manual_counter[inpage_ptr >> 12] <= 2 + (rand() & 3))

Jake.Stine

How's performance and stability on this revision? If things seem good then we can go in and simplify some of our code regarding cross-page code blocks. I don't want to do that unless this mod seems a keeper.

ramapcsx2

So far so good. Speed is slightly better than before the BTS try i some games.

Compatibility seems fine. Games so far don't print too many "Pagesplit" messages.

Jake.Stine

Ok, that's about what I was seeing also. And really a game would have to *hammer* a pagesplit for it to be a noticeable speed hit, and that's both extremely unlikely and would still not be as significant as BTS's impact on many FMVs.

arcum42

Main example I've seen so far of a game spamming Pagesplits is Baroque, and that's mainly at the start of the game. Still seems reasonably fast, though.

Revision 1094

Fixed a typo in the SIO2 hardware read interface: SIO2_getSend1 and getSend2 had

inverted switch cases (probably been there for years).

refraction

bored tonight jake? lol

Jake.Stine

The hard part of course was determining if it was intentional or not. ;)

refraction

ah well itll probably solve some of mattmenke's problems, or make them worse, so we will soon find out :)

crushtes...

or make project zero 2-3 work (and that ofcourse was a joke :P)

refraction

stranger things have happened, fixing the clock made MGS3 work :p

junr...

It truly fixed some issue

Revision 1095

Committing various cleanups I'd put aside at one point or another...

Revision 1096

Fixed some 'too many newlines' bugs in the Console namespace.

Revision 1097

wxGui: Type the letter 'L' a whole bunch of times.

arcum42

And accidentally included two files that haven't been committed yet in the project. Oh well, can always correct that later.

Revision 1098

wxGui: Add two dummy files, to make codeblocks happy.

Revision 1099

Rushed my prev commit. Here's some basic thing, only much less broken and

crappy. (fixes double-spaced emuLog.txt file contents)

rodiablo...

Sorry to ask you this, Jake. But... are you finished here? Or do you plan to commit something else? I dont want to bother you, it's just a question. ^^

jfre1...

Strange question rod........

rodiablo...

he rushed his previus commit, that's why I asked :P

Revision 1100

R3000air: More work on a new IOP memory system, added re-written IopHwRead

functions.

junr...

Jake, I think you are a iron man :P

Revision 1101

minor microVU changes

Revision 1102

Some work on CDVD.cpp. Slight change to the branch statements in

Interpreter.cpp. Restore a change to Pcsx2Defs.h that got reverted.

arcum42

One of my changes ended up being reverted before committing because it would have broke backwards savestate compatibility. I'm starting to save up those changes, so I can do them all at once, sometime when savestate compatibility has broken anyways...

Jake.Stine

Some of the stuff in CDVD.h should probably be moved to a CDVD_Internal.h or something, since it's not stuff that any other code in Pcsx2 would ever care to use. That's why I never bothered to stick it in CDVD.h earlier.

arcum42

Probably a good idea. I had been thinking about that when I realized that if I wanted to create a enum for the sCmd values that it'd overwhelm the rest of the header. Main reason why I didn't create said enum was that I didn't feel like typing out 69 or so names...

Revision 1103

Bugfix for recent cleanups: SetResultSize was defined with different behaviors

in two separate files, without being static. Depending on the whims of the wind,

MSVC would sometimes pick the one from CDROM and link it into CDVD, overriding

CDVD's version, and resulting in complete emulation failure.

Revision 1104

R3000air: Updated branch to latest /trunk.

heatbla...

WOW! Over 20 SVNs for a few days... Guys, you surely work hard... don`t overdo it. It`s 1st of May - the day of the work so have a break (have a KitKat)

Revision 1105

Begin work on renovating the Null plugins. (On the Linux side, anyways, though

some of that will spill over to the Windows side.) Starting with FWnull.

arcum42

Not sure if the Windows version of this till compiles, though I did update the one file name that had changed. I'll check later. Practically no one builds these on the windows side except for official builds anyways.

I'm mainly doing this because a number of the null plugins and some of the older plugins have really bad build systems, and do weird things, like splitting the plugin into two files.

I want the null plugins to be good bases to build working plugins on.

And, no, my work on FWnull isn't done.

Revision 1106

Helps if I have FW.cpp in there. :(

arcum42

That's the trouble when you're renaming, deleting, and adding a bunch of files. It's easy to miss one...

ramapcsx2

Nice idea. I'm fairly sure you're the first to look at this in years ;)

arcum42

Thanks. And given that I changed 2004 to 2009 in the copyright, probably.

And the basic plan is to modernize the build systems of each of the null plugins, convert them to C++, and straighten out the source a bit while doing it.

Once that's done, I'll start looking at some of the older plugins that are still in use. (Like the linuz iso plugin. Most of the things I fixed in FWnull are problems in linuz as well...)

I think it'd be nice to have them have enough code in them that you could honestly take it and start making a plugin relatively easily, too. If I get really carried away, I might even add null plugins that don't currently exist. GSnull might be fun...

Revision 1107

That's USBnull down. (And yes, I'm aware the dialog boxes for USBnull & FWnull

are incorrect. For now, I just told it to use the incorrect one that was already

in the plugin.)

arcum42

I was able to reuse a bunch of changes I already made in FWnull for USBnull; the one was clearly originally copied from the other.

Why they both have dialog boxes intended for Dev9 is beyond me, though.

hondza...

More error exist. :(

Jake.Stine

>> Why they both have dialog boxes intended for Dev9 is beyond me, though.

Because Dev9 was probably made first. ;)

arcum42

I could see that if Dev9null had a dialog box...

Revision 1108

I don't even wan to know how these got deleted during the commit...

arcum42

want, rather. I have lunch waiting, so was typing fast.

Revision 1109

And there goes SPU2null. This one deserves a lot more work, though. A real gui

and backporting all the changes I made to ZeroSPU2, for starters. (And again,

Windows may or may not compile for it. Looking at the Visual C++ file, I'm

pretty sure it already wasn't compiling.

Revision 1110

And that's CDVDnull. Given how barebones this plugin is, it's closer to making a

null plugin then cleaning it up...

Revision 1111

And that's dev9, which was about as barebones as CDVDnull.

arcum42

Well, that's all the null plugins, though they'll need checking over on the windows side, SPU2null could use some code revision, and most of them could use some fleshing out.

Next would be plugins that actually do something...

Revision 1112

Lets get the null plugins working in Windows again...

arcum42

If any error out, just rebuild them. I thought some of these were likely to break when making the Linux changes. It's easier to fix them all at once then one at a time, rebooting twice for each plugin, though.

Revision 1113

microVU: fixed some bugs in stall calculations.

rodiablo...

Man, this gonna be good when finished. Thanks cottonvibes ^^

Revision 1114

Removed VU-Skip [helps simplify the frameskipper logic] -- Use the VU Cycle

Stealer hack instead for better, faster, more stable speedups of the VU1 unit.

rodiablo...

Xenosaga does not work with the Vu Cycle Stealer Hack. VU Skip is crucial to be able to run it on not-so-high-end-machines. And I bet other games don't take benefit of the Cycle stealer either. Please, don't remove it, Jake.

rodiablo...

Vu skip is an alternative to when the VU Cycle Stealer don't work properly. Sorry to be rude, but I don't see a good reason to remove the VU skip feature. It's very usefull to me at least.

Autor...

T5 still better use of VU Skip than new hack

Jake.Stine

VU-Skip was a nightmare to maintain and generated a constant stream of complaints from people since every time we changed VIF timings, the effects of VUSkip would shift and people wanted me to "make it go back!" (which I cheerfully ignored since it's not possible).

And most of the games you guys have mentioned aren't even that slow because of VU skip, but rather because of the crappy way that the GS does frameskipping in general. If/when I get the chance to fix the GS plugin API, plain old frameskip will probably run much faster than VU skip ever did, with no side effects.

rodiablo...

I hope you're right, Jake. Because without frameskip, I just can't test the few games I have properly. I don't want to sound ungratefull, but I've been testing and hoping for a playable Xenosaga (and other games) on a 3.0GHz C2D cpu, even if I have to jump some frames. And, with the recent progress, I'm almost there. I hope you can get the chance to fix the GS plugin API. Take yout time. No need to rush. ^^

ramapcsx2

rodiabloalmeida:

Xenosaga is definitely playable with some speedhacks on that machine.

Use dx10 and it runs well above 60fps most of the time. Even without

turning off an entire processor every few frames (worst hack ever) :p

kraka...

Weee, pitching in another positive review before it gets swarmed with unmotivated negative comments.

Face it people, this was one crazy hack, and you and us are much better off without it :)

veaac.fd...

Very nice. This should eliminate many "bug" reports in the forums about shaky / corrupted graphics.

Jake.Stine

>> I hope you're right, Jake. Because without frameskip, I just can't test the few games I have properly.

If you're "testing" with VUSkip enabled then you're not really testing at all.

du...

sorry to hear this news , i used vu skip alot with my amd 4600+ , and i know for a fact that cycle stealing or frame skip just aren't good enough in some games (i.e. enthusia , dragon quest 8..... which i play alot)

heatbla...

I`ll test it asap, btw you have to read one guy`s bug report of Fate: Unlimited Codes where a gameplay bug occured when EE rec and VU recs were set to Chop/Zero. When swithced to Nearest the bug is gone... I`ve seen that simillar bug in Tekken 5 in PCSX PG projects far ago when the characters used to get out of the ring in the nothingness...

rodiablo...

I agree that VU Skip is more trouble then solution. I know that, for sure. I read the forums everyday. I just don't usually post because my english sucks. :P

@rama

Maybe it's possible to run Xenosaga at 60fps. But not at a constant rate. It drops to less then 60fps many times, at least on my rig. "My" goal its to be able to run at a constant 60fps.

@jake

Sorry to the negative I gaved to you, but with frameskip turned on is the only way I can test/play some games. Maybe not these days 'cos there is plenty improvements recently (the Vu Cycle Stealer for example that made Shadow of the Colossus perfectly playable at 60fps on my rig). And I'm very gratefull that I can test this way because for almost 2 years I could not test PCSX2 due to not having a reasonable machine to do so.

Sorry for the long text and bad english. I just don't want to sound ungreatfull at all. Keep up the great work you all do. :)

ItsAGraf...

Never used this anyway. It's better to be slow, then choppy. :)

And if this commit simplifies the future work... let it be.

heatbla...

Accuracy >> Speed

andreas....

Like 90% of my games worked great with vu-skip, maybe 30~50% with vu-stealer... With the addition of vu-skip I still usually disabled it and used vu-skip for best result. So it's a bit weird move to me but ok...

andreas....

err meant with addition of vu-stealer

ntcong.it

Err, development version is not for speed, you shouldn't expect fps increase with software in dev channel. It'll include bug, experimental feature or some weird things.

As Jake said, we would not lose time for making VU-Skip compatiable, and we'd have time to improve normal frameskip works better

bin.gang

Just remove this feature if it helps the dev team better in coding.

Wagnar...

A good choice imo even if there "may" be some down side of it.

+1

gabest11

If any skipping method works it's purely accidental, no guarantee that the gs state is updated for each frame by the game, for example it can assume the palette was uploaded and set but we just skipped that frame.

valles...

VU skip was just wrong. It's not sane to skip code that actually does things.

I'm happy that's gone from the F4 cycle.

Autor...

Well, i think this is a good commit, safety comes first, besides i almost never used it

jadjkor...

VU Skip makes any game i run to crash after a few minutes.

I trust more in the new speedhacks.

ntcong.it

-~> misc.cpp(459) : warning C4700: uninitialized local variable 'newFrameLimit' used

Compile pcsx2 give this warning, it's only a warning, of course, but I don't like warning :).

Give it a init value should be okay.

toammar2...

Remove this feature Is Good ID Now need to Skip any Code....

bfb...

Never was able to run something without bugs in VUskip mode.

But if you can improove normal frameskip instead it will be very good.

hirits...

Remove it will make Valkyrie Profile2 not run

nokiaqdman

>>>Accuracy >> Speed

No. It's like that

Accuracy <<<<<<< Speed

Dhalai.L...

I don't care about hacks. Give me compatibilty =P ++++++++

Revision 1115

Finish removing VU Skip from Linux, and fix a few compiler warnings left over

from the work on CDVD.cpp.

Revision 1116

*Experimental* Made new IopHwRead and IopHwWrite from scratch, in pre-

preparation for a new lookup-based IOP memory manager. Could be some lingering

bugs or typos. :/

Win32/vcproj: Re-structured the folder layout of the project.

rodiablo...

*Experimental* is good. I like when I see that word in here.^^ Thanks, Jake.

guhun...

I can't run games in this revision. It crash right away when I run games (r1115 works fine).

Console output:

PCSX2 (beta) - compiled on May 2 2009

Savestate version: 8b410001

x86Init:

CPU vendor name = GenuineIntel

FamilyID = 7

x86Family = Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz

CPU speed = 2.499 Ghz

Cores = 4 physical [4 logical]

x86PType = Standard OEM

x86Flags = bfebfbff 0008e3fd

x86EFlags = 20100000

Features:

Detected MMX

Detected SSE

Detected SSE2

Detected SSE3

Detected SSSE3

Detected SSE4.1

Not Detected SSE4.2

Hotkeys:

F1 - save state

(Shift +) F2 - cycle states

F3 - load state

Resetting...

Ready

Bios Version 2.0

Framelimiter rate updated (UpdateVSyncRate): 59.94 fps

detected blocksize = 2048

isoOpen: F:\New Folder\FINAL_FANTASY_X-2.iso ok

offset = 0

blockofs = 24

blocksize = 2048

blocks = 1944448

type = 2

MTGS > Thread Started, Opening GS Plugin...

MTGS > GSopen Finished, return code: 0x0

No accelerated IMDCT transform found

Issuing EE/iR5900-32 Recompiler Reset [mem/structure cleanup]

* PCSX2 *: ExecuteBios

# Initialize memory (rev:3.70, ctm:393Mhz, cpuclk:295Mhz detected)

ItsAGraf...

Tested some games... there is no sign of any new bugs for me.

bin.gang

Yeah, I got this problem too. The error window appears everytime I try to run a game and it notifies that the program has stopped working. Pls fix it.

Wagnar...

Not sure if this is the revision that cause it, but all my games are crashing at start too.

kenzozus...

I can't run all game. Please fix.

ItsAGraf...

guhungry, kenzozus, Wagnard28, maybe, you did something wrong?.. Because I have no problems. Compiled svn1117 and played VF4Evo, God Hand, Warriors Orochi II and some other games a bit. Everything is OK.

Just for test (compiled for Core2Duo or higher with ICL, needs SSSE3):

http://rapidshare.com/files/228338988/pcsx2.7z

Wagnar...

Ill test more since the version I have compiled is 1120. so maybe its not this revision after all.

Wagnar...

OK I have tested. THIS revision is the problem.

I have compile R1115 and work without a problem. R1116 crash at every game I load up even on BIOS load.

nexxus86

see, this is a experimental commit, so no wonder why it doesn't work for some people.

nexxus86

@ ItsAGrafKaliostro:

what did you do that it worked?

ItsAGraf...

Who knows... Just compiled it. :)

Maybe, it's also GSdx or something - I recompiled most plugs not too long ago. Maybe, it's ICL specific.

Is this exe works in your case?

Wagnar...

May I have more information about ICL?

Also I saw that your .exe is larger than mine.

ntcong.it

ICL is Intel's C++ Compile, maybe it have some optimism, or it just ignore something, in my opinion

guhun...

I debugged and I got error in iR5900-32.cpp @ line 629. It seems function recEventTest() doesn't available in this context.

Error in MSVC

Unhandled exception at 0x00000fff in pcsx2.exe: 0xC0000005: Access violation.

address 0x00000fff is location of the function recEventTest().

ntcong.it

Seems the problem with jNO_DEFAULT in IopHwRead.cpp.

I tried to find more specific problem but since I'm not know well about pcsx2's code :P

arcum42

@ntcong.it:

Well, jNO_DEFAULT in a case statement is a macro that basically means that the value should have been one of the ones already given, and if it isn't, to throw your hands up and give up.

If you wanted to get more detail, looking at that section of code, if you changed it to :

default: Console::Error("masked_addr = 0x%x", params masked_addr); jASSUME(0); break;

It would tell you what value it was crashing on. Of course, I'm not Jake, but that could help Jake out...

It's quite possible that changing it to this:

default: ret = psxHu32(addr); break;

Might work, but then, it might not. I'm not familliar enough with that area of the code to say, and I'm not having that issue...

ntcong.it

the masked_addr can easily found by some debugging :).

I don't want to break Jake's code, so insert those code may get pcsx2 work

mcase(0x0000047c):

ret = psxHu32(addr);

break;

I don't know if it break other thing :P

arcum42

Looking at that case statement, I have a feeling the first statement:

mcase(0x1f801264)

is supposed to be:

mcase(HW_SIO2_FIFO) Which would be mcase(0x1f808264).

If you look at the top of the function, it says "all addresses are assumed to be prefixed with 0x1f808xxx", and that address isn't, which is why I'm thinking it's a typo.

arcum42

Oh, and btw, rather then saying mcase(0x0000047c), it's a bit more correct to say mcase(0x1f80847c). That would be what the actual address would have been before all but the last three digits were hacked off, and it should work the same.

ntcong.it

0x1f801264 and 0x1f808264 should be the same with mcase ( addr & 0x0fff ), so I think it's an unknown address that he forgot to add in the case

arcum42

Yeah, thinking about it, that may be a typo, but wouldn't have affected it.

ntcong.it

I've just thinking about it and changed it :).

That revision contains bugs, that why he marked it as *Experimental* :)

arcum42

And that's why he said: "Could be some lingering bugs or typos. :/"

I'm somewhat debating whether to leave it as is till he gets a chance to look at it, or just commit, and let Jake revert if need be...

ntcong.it

I think you should make a changes, so that some people will not randomly make negative comment at the HEAD revision, said "omg, this revision broke my game" :))

arcum42

Given that I was the last one to make a commit, and it was one of these commits that could only affect Linux (and was 3 lines!), that is influencing my thinking, admittedly.

arcum42

See r1123.

ntcong.it

That's why I don't like a public guide for compile svn. People just do an svn update, compile it, and complain about some bugs at the HEAD rev.

Nice fix, no more warning when compile :D

arcum42

No prob. I'm fairly used to dealing with compiler warnings...

And I like the comment system, but the positive/negative thing irritates me. Especially because part of the nature of svn is it is supposed to occassionally break for a few revisions, and a lot of people don't seem to understand that.

Some of the reasons are irritating, too. I've been marked down simply for doing a commit that only affects the Linux port before. :(

Revision 1117

Linux: Quickly hack the new files into the main makefile.

Revision 1118

CDVDiso: Now uses automake, is C++, isn't split into two files, and doesn't

change around the working directory on us.

arcum42

And you don't know how much time I spent making sure this worked on both Linux and Windows...

guhun...

It seems that /trunk/plugins/CDVDiso/src/Windows/svnrev.h was accidentally added in this revision.

arcum42

Must have come with it when I transferred it back to Linux after testing in Windows. I'll delete it relatively soon...

Revision 1119

R3000air: performing maintenance merge before weekend departure.

Revision 1120

wxGui: performing maintenance merge before weekend departure.

Revision 1121

Plugins: Fix the dialog boxes on FWnull & USBnull so the buttons work. Fix

inconsistant version numbers. Delete a stray file.

Revision 1122

Linux: Iron out a few issues with the configuration dialog in Linux.

nexxus86

one of the latest revisions is broken in Windows.

it just crash when i try to run something, older revisions from April works fine

arcum42

Take a look at the list of affected files for this revision. See how the only file affected is in a folder marked "Linux"? Nothing in that folder is compiled on Windows.

Therefore this is not the revision you are looking for.

Wagnar...

This revision is not the problem.

Leave arcum42 alone :P

arcum42

Thanks. One of my pet peeves is when people mark the top revision negative without checking to see what revision caused their issues, or even if it makes sense.

I'm personally not having issues with it, but r1116 seems the most likely one to have caused problems, both from the comments, the fact that it's marked *Experimental*, and the note 'Could be some lingering

bugs or typos.'.

I did like the fact that Jake put some commented out code in IopMem.cpp in that revision specifically marked to uncomment for regression testing...

Revision 1123

Atn Jake: Please review. Quick patch to counter problems reported with r1116.

arcum42

And, yes, I added warnings when those are encountered, until Jake has had a chance to sort the issue out.

bin.gang

Oh, it's just a temporary fix, isn't it? When i start a game, the debug window shows a red line which is: "iopHwRead32_Page8: Calling 0x1f80847c for some unknown reason", though the game still runs fine. There may exist another error. Anyway ,thanks arcum42, now i can get it work again.

arcum42

No problem. And, yes, this is a temporary fix.

There's a decent chance that Jake may just remove the two lines I added to the debug menu for this, but I put them in just so that Jake can get a bit of feedback into what's causing the issue.

Mainly because I'm not sure if the proper fix is letting everything unknown go through with psxHu32(addr), like I did, restricting the range of addresses it looks at, or just adding an address or two.

I'll let Jake decide that, but in the meantime, people affected can play games. I committed this since I wasn't sure how long it'd be till Jake could look at it...

kraka...

Jake will be back tomorrow I think, just for your information :)

arcum42

He said "a couple days", so I figured I'd make sure we were covered...

kraka...

Oh, was just referring to the fact he would not be able to take a look till tomorrow

Revision 1124

Edited wiki page through web user interface to fix typo.

Revision 1125

ZeroPad: Apply the multiple key patch in issue 197 to ZeroPad. Currently Linux

only.

Revision 1126

ZeroPad: Commit bolche's Analog control code, ifdeffed out, so I don't forget to

add a gui for it and enable it some day.

arcum42

This is the code from this thread here:

http://forums.pcsx2.net/thread-4699.html

Not particularly tested, but not particularly enabled, either. Just didn't want to forget about it.

Revision 1127

Zeropad: Clean up the code so that if I have to go back into it, it's easier to

read.

Zeydl...

Also change in Windows/Win.cpp wparam to wParam at lines 193 and 201, please, It's my fault to misspell it.

Zeydl...

O! And made an return -1 to FindKey default path, also add -1 check in Linux.cpp, Win.cpp and Zeropad.cpp that use this function. If key does not found, nothing should be done.

Zeydl...

Add proposed patch to issue197 .

arcum42

Taken care of...

Revision 1128

ZeroPad: Patch to fix a bug introduced in r1125.

Revision 1129

Fix bug from r1116 [essentially a misplaced jNO_DEFAULT directive].

Jake.Stine

Explanation: jNO_DEFAULT is an optimization directive that hints to the compiler that the "default" case will never be reached. I incorrectly used it because for some reason I thought that switch statement was inside a more strict if() conditional (admittedly it may have been at one time -- I ended up restructuring the entire IopHwRead.cpp file after finishing IopHwWrite.cpp).

Anyways, jNO_DEFAULT asserts in debug builds since, if the assert fails, it means the directive is invalid and should be removed. In release builds the compiler hint forces the compiler to disregard out-of-range values, in which case they'll usually be handled by god-knows-what code or will just casue an access violation when they reach the switch.

The kicker is this: in devel builds they'll tend to work, because devel doesn't optimize as much as release and doesn't perform the assertion check either.

ItsAGraf...

It seems like ICL just ignored this and optimised code with own methods... because ICL-compiled bild doesn't have such bug!

Jake.Stine

The optimization is MSVC-specific, as MSVC is the only one that supports the __assume() keyword. ICL would have performed no special optimization and would have assumed the default case is reachable (default non-optimized behavior). GCC does the same.

Revision 1130

ZeroPad: Revert the changes to the Windows files in ZeroPad, and ifdef off the

changes in the common areas, as the Windows version of ZeroPad is clearly only

working by voodoo and bailing wire on Windows. (Note: unable to reproduce

ZeroPad working properly in any revision [including playground days] on any

version of Windows available. Likely because I don't have any poultry handy to

sacrifice.)

Revision 1131

Improved handling of jNO_DEFAULT so that it performs a sanity check in Devel

builds [currently applies to Pcsx2 only since we don't have a standard define

macro for devbuild in the plugins].

Cleaned up and abbreviated logging for the new IOP HwRead/Write handlers.

guhun...

# pragma warning(disable:4244)

was accidentally disabled in release build.

Jake.Stine

oops! darn.

ah well, not critical. I'll roll in the fix with my next commit (whenever that is).

Revision 1132

Apparently the MSB of integer register specifications in VU micro instructions

is ignored, making the upper 16 registers mirror the lower 16. Changed all

relevant instructions to reflect this.

ntcong.it

Hey, I thought that VUmicro is cottonvibes' part, right ? Glad that we have another one looking at it

ntcong.it

Arr, my wrong, VUmicro don't have the "i", and it's in pcsx2 folder :)

Revision 1133

Apply recent Iop HwRegister handler changes to the EE's mapping [EE has direct

access to IOP memory and registers through a special tlb mapping, intended for

ps2dev debugging, and generally used by bios only during boot-up).

Revision 1134

This is why a type safe emitter is important.

Revision 1135

Small speedup for the EE/IOP recompilers, by removing the legacy limit on the

number of recompiled blocks (was causing recompilers to reset the code buffers

way more than necessary).

bin.gang

Don't know much about coding, but I like the word 'speedup':p

Revision 1136

pcsx2:

- PCSX2 would repetitively call CDVDopen if loading an elf file and your cdvd

plugin didn't have an ISO already pre-loaded. Basically I had to switch to

CDVDnull whenever I wanted to load an elf... well not anymore xD

microVU:

- Implemented the VI regs thing where if an opcode tried to access vi regs

16~31, the VU's should return vi0~15 (viReg & 0xf); technically it should never

happen, but from my tests the BIOS seems to do this... so maybe some rare games

do it too...

- Our VIF code apparently uses VU cycles for some stuff, so I now update the

cycles variable VIF relies on.

- Minor Optimizations

junr...

it seems the bios is interesting

yujack2...

Well then,if I want to run the game just after the elf(for example,the CodeBreaker),what should I do now?

cottonvibes

going to revert the elf change later because some elf files need to read cdvd; like the snes emu for ps2...

i had a feeling people would complain..

ideally we should have a run->bios option as well, that just runs the bios.

so you don't have to switch to CDVDnull if you need to run/test your bios...

chane2k1

a run bios option would come in handy i like using it to manage my memory cards rather than the one built in pcsx2. plus i just like to play with bios sometimes.

kaboo...

I second the run bios option^^

also it would be good to make the Run/CDVD and the execute function more distinct... a newbie wouldn't know what does what XD

also I think they should be in the same list Oo

kk enough with the complaining

I think the progress the emu has made great (I mean the progress this year XD) I can finally play Wild Arms 3 *LUCKY*

cottonvibes

i think jake made the run cdvd and run execute on the same list in the new wx gui :p

ntcong.it

Yeah I think he did, I saw an "Quick and Full boot CD/DVD" and a "Boot without CDVD".

It would be a nice option so we don't have to switch plugin to boot the bios

Revision 1137

Optimized vtlb direct path memory operations using some crafty asm code. Expect

2-3% speedups in most things, and perhaps more in some FMVs.

Jake.Stine

This commit might break linux, I dunno. I couldn't test it because my CoLinux install just up and decided that it can't resolve eth0 anymore! I fought with it for 3-4 hrs and finally gave up.

I was able to get a fedora image to find eth0, but I couldn't get xwindows to connect. I might try re-downloading some other distro's image and seeing if X works better there, and if it can find my eth0 too.

I still have no idea why my portable ubuntu install can't find eth0 tho. For a while it failed on DHCP, an after some fussing now it fails just finding anything (says module isn't there, or something). I ended up upgrading CoLinux though, so who knows. I don't feel like re-downloading the 450meg Portable Ubuntu install to get the CoLinux and conf files out of it -- might fix the issue, or might not. I dunno.

ramapcsx2

Nice to see it worked out, Jake :)

Now all games see a benefit from this. No slowdowns in any game i threw at it.

Seems this speeds up load/store situations quite a bit. Hence the FMV increaes.

Oh, and 2-3% is prolly an understatement :p

GREGORIO...

I've tested this, and OMG

There is 5-10 fps speedup on every game i tested (Final Fantasy XII,Resident evil 4, Onimusha)

Superb work!

Jake.Stine

oh yea, forgot to add: this probably benefits P4s and older C2Ds the most, making it indeed a very effective optimization.

arcum42

Still works fine in Linux, btw.

Autor...

Excelent

Jake.Stine

>> Still works fine in Linux, btw.

Yay. My original version used naked functions, which would have required externalized asm files. I retooled it to use the emitter. Looks like it worked out to be a nice solution. :)

xat...

Very cool. Tested ToA; for me it's running well above full speed in most cases with absolutely *no* speedhacks.

nexxus86

66 to 67fps in FFX intro.

i expected something like this.

ItsAGraf...

Last time I tested Ubuntu on coLinux (it was 8.04 as far as I remember, though not portable) there was no any problems with eth0, while it manually set in the /etc/network/interfaces like this:

auto eth0

iface eth0 inet static

address 192.168.1.2

gateway 192.168.1.1

netmask 255.255.255.0

broadcast 192.168.1.255

Tested it with Xwin & Xming and found it very useful.

But much easier to use VirtualBox (or any free VMware product). Moreover, coLinux works slower (really slower!) with HDD, and slightly faster with CPU. At least, so was one year ago. Also, rendering speed roughly x2 better with VirtualBox.

...and about PCSX2. :)

Great! 42fps -> 45fps average in VF4Evo.

refraction

2-3%? youre crazy dude, things are hugely quick on an i7 :)

airmake...

This commit broke the Linux client for me :\ It compiles, but many games crash at startup.

Revision 1138

Some code cleanups for the new vtlb optimization (no intentional functional

changes -- just deleted unused code and converted all of vtlb to the new emitter

syntax. Let's hope I didn't typo anything!)

Revision 1139

R3000air: Implemented new vtlb-style memory system (uses LUTs to dispatch

indirect memory operations to HWregs, SPU2, DEV9, etc -- big speedup for memory

operations). Started work on new IOP recompiler.

Also: Merged against /trunk.

Jake.Stine

The new vtlb memory system sped up the interpreter substantially. The old system gave ~94 fps on the Disgaea menu and now it's 117 fps. For the record: I get 207fps in the current EE/IOP recompilers (trunk), and ~66 fps using the current IOP interpreter. So my interpreter runs at 117fps against 66fps for the old one. :)

veaac.fd...

Be sure to include some "tuning"-parameters when merging into the main trunk limiting the speedup to 10% or so and add another 10% every now and then to keep the masses happy :-)

Autor...

I'm looking forward to test it someday :)

ntcong.it

We're having many huge rewrite right :D.

I need to clean my HDD a bit and then checkout this branch and test :D.

And that's great to hear you're working on the recompiler, are we near the complete ?

nuku...

I'm getting a little sick and tired of all the speedups. Jake seems to assume everybody has an asus Eee PC shoved up their arse or something. I-4-1 dun't OC muh' boxes juz tah run dat superpi yuh noh.

Seriously, keep it coming.

kaboo...

why the heavy slang ?...and why EEE PC? I read nothing about that anywhere near pcsx2... and that's probably cause even the heaviest OCing wouldn't help for an EEE PC ....

the more I think about the post ... the less I understand it...

anyway nice hopefully your recompiler has a similar fps hit ^^

nuku...

I don't see why it was so hard to understand.

The whole thing was sarcasm. That means speedups are good, eee pcs are slow(but now fast enough to run pcsx2 more than full speed thanks to the ridiculous number of speedups...not really but thats the joke), and the slang about superpi is that if its fast enough to run without an OC then the only remiaining reason to have an OC box is running superpi(also bogus but again thats the joke)

got it now?

kaboo...

.... it's really sad that I didn't get it...

andreabo...

So we are working on new ee recompiler and vu recompiler.

When Both will merge will have a totally new emu...

:)

Revision 1140

A few minor counter changes to prevent scenarios where branch targets could be

missed on counter resets/target changes, also a situation where the vsync

counter could cause repetative branch tests to be triggered in quick succession

on cycle counter overflow

Jake.Stine

btw, you probably kinda noticed: cpuSetNextBranch was created for the express purpose of setting cpuNextBranchCycle in convenient and lazy fashion (and the iop has a matching one). And yes the signage on the function is intentional and important, in case you were worried that the function using signed compares internally was somehow bad. (it's quite intentional, as it avoids ensuing mayhem if the start cycle is greater than the current branch cycle -- which can happen in obscure cases).

The 'limited' scope of the s32 compare isn't harmful since the absolute maximum of any counter or interrupt duration is well below 2 billion cycles (it's right about 34 million cycles, actually).

refraction

oh i noticed that dont worry :p what really threw me was on an iop counter update the start cycle was greater than the next branch cycle, which threw some of the equasions off lol. But the sign compares are probably much safer as targets can be missed and immediate retriggers can be done.

arcum42

Just as a note, in Linux, at least, that SPU2async message in IopDma.cpp gets printed out quite a lot...

...

)

SPU2async Setting new counter branch, old 246ffaf new 246e3fb ((246ffaf - 246e12b = 1e84) > 2d0 delta)

SPU2async Setting new counter branch, old 2470000 new 246f107 ((2470000 - 246f0d7 = f29) > 30 delta)

SPU2async Setting new counter branch, old 2470000 new 246f891 ((2470000 - 246f591 = a6f) > 300 delta)

...

refraction

yeh its game dependant, it should be on devcon printout only, rather than release builds.

Revision 1141

microVU: various minor fixes that effected big stuff...

refraction

Lets hear it for stuff!

Revision 1142

GSdx: Reworked the sw renderer texture cache a bit, at page level its

correctness was questionable if the base address was not page aligned, so now

keeping track of blocks (32x more), may be slower or faster by a few percent

(number of blocks vs. finer resolution).

nexxus86

higher resolutions for the software rendering would be nice.

i know, doubling the resolution would require an almost doubled CPU Speed O.O

but its nice to make highres screenshots in games wich are buggy in hardware mode.

ramapcsx2

Yea, we all wish that would be possible. Just it isn't :p

gabest11

Just would have to face the same problems that make the hw renderer less compatible.

The swizzled memory is in the way mostly (that tricky 16 bit mode that causes stripes is totally impossible).

But also the fractional parts of texture coordinates that were not given with non-native resolution in mind are a PITA.

Shifted overlays after ping-pong rendering, or gaps between sprites are the usual symptomes.

Jake.Stine

@nexxus86: Actually doubled resolution requires over 4x as much CPU power. It's 4 times the total area, and on top of that causes more headaches for your CPU cache. So yea, it gets really slow.

Revision 1143

Made some tweaks to the EErec block manager in hopes of resolving Issue 208

[Soul Calibur 3 missing gfx], involving the willbranch3 logic path.

Emitter: Added xJcc8 / xJcc32 functions for doing modified jump targets.

Also: minor cleanup to recent counters fixes (nothing relevant, just reduced out

some copy-paste jobs for clarity).

refraction

129+ s32* bah = xJcc32( comparison );

130+ *bah = (s32)target - (s32)xGetPtr();

lulz! and i see what you meant (in the other thread) now i did originally have that as you probably saw my commented out one, i had the others in place merely so i could debug it without having to put loads of logging in that heavily used function and didnt see a great deal of advantage in replacing it.

Autor...

Tried this version bug still presented in NTSC-U

Jake.Stine

hehe, I went bah because this doesn't work:

*xJcc32( comparison ) = (s32)target - (s32)xGetPtr();

C++ decides to resolve the R-Values first, so when it assigns the pointer returned by xJcc32, the pointers it assigns are old. I couldn't find any way to make it run the L-Value first and then the R-Value.. but it'd have been so much simpler/nicer code ;_;

Revision 1144

Linux: These weren't intended as externs...

arcum42

Dev note: If fast_routines.cpp and fast_routines.S were put in the same Makefile, gcc'd try to compile them both to fast_routines.o. And fast_routines.cpp is entirely Windows code anyways, so it's left out.

But fast_routines.S *needs* _xmm_backup & _mmx_backup declared somewhere in the program. So they are declared in NakedAsm.h.

arcum42

I'm sure there's a way around the conflict. (Beyond the obvious "rename the file" fix). I just hadn't yet seen a need to go out of my way to change it.

ntcong.it

afaik we can tell gcc to compile and output as file.ext.o like fast_routines.cpp.o.

Jake.Stine

@arcum42: Ah, that explains then why it compiles ok. I wonder, maybe I should build memcpy_fast using the emitter instead and get rid of more asm duplication?

arcum42

Sounds good to me. The more of the *.S files we can get rid of, the better, and this one just has memcmp_mmx, memxor_mmx, and memcpy_amd_ in it.

I just tend to view each *.S file as an extra opportunity of incompatabilities between ports to creep in... (Though it's a lot better on that front then it used to be.)

Jake.Stine

I think if I do that I can make it faster too. I can use const-propagation by the C++ compiler to use optimized compilations of memcpy_fast for fixed-length copies, and copies where the length is known to be aligned. :)

Revision 1145

GSdx: 3.4.9. Texture Function => Decal/TCC=RGB: Av = At (gs_user v3 and v5) or

Av = Af (v6)? Seems it was Af... Sonic unleashed was one of the games relying on

this setting, could not find any other yet. Also removed the green stripes,

shadow sw-mode only.

Revision 1146

IopMem: Added FireWire port handling to the new IopHardware handlers (oops!).

EErec: Removed an instance of duplicated cycle counting for split blocks.

Revision 1147

Gah... dumb mistake. >_<

ntcong.it

I like the Java style more than GNU style. In Java style, masked_addr should be maskedAddr, so we won't make some mistake like this :D

david.jennes

Do you mean camelcase? 'cause that's used kinda everywhere, not just java...

Revision 1148

R3000air: Implemented all recompiled Load and Store operations (including

LWL/LWR/SWL/SWR)

Revision 1149

Zeropad: Break up linux.cpp into multiple files.

arcum42

Oh, and I fixed a fairly blatant bug (One function was chacking the PADOPTION_REVERTLX option for ly, rx, and ry...), and took out all the uses of the define "FORIT" in the code.

arcum42

Erm, checking, I mean.

Revision 1150

Zeropad: fix minor typo in previous commit that got copied and pasted several

times.

Revision 1151

microVU:

- Fixed up some code so blocks are recompiled less often.

- Tweaked flag code.

- Minor changes...

Jake.Stine

This gets a +1 from me because you fixed that grammatical error in VU_Misc.h! hehe

My Pcsx2 priority chain, since everyone else has been doing it lately: grammar > compat > speed

My 9th grade english teacher would be proud! (a thought that, admittedly, I'm not too comfortable with. She was really creepy)

cottonvibes

yeah changing "it's" to "its" lets me get full speed in most my games now; i can only imagine what fixing more grammatical errors will do! :p

Revision 1152

microVU: Cleanup and added microVU_Flags.inl to the project.

Revision 1153

Minor bug fixes. Reformat iVUzerorec.cpp & get rid of all occurrances of the

FORIT macro.

arcum42

Hmm, that bit in ix86_inlines.inl wasn't *quite* what I meant. Should have been:

#if !defined(__LINUX__) || !defined(DEBUG)

#endif

Not critical, though. Just a console message. I'll fix it next commit.

arcum42

Main reason for the reformat of iVUzerorec.cpp was because half the file was indented wrong, making it very hard to follow, incidentally.

Oh, and that if statement in iR3000Atables was *never true* because it was unsigned. And it was clear from the other statements around it that it should have been cast to int. Not sure if that was breaking anything, but this should be more correct.

arcum42

It's also worth noting that this commit fixed compilation of the DEBUG build in Linux, incidentally. That's what the changes in moremovs.h were for.

Revision 1154

better fix for my elf-fix a while back.

basically if you run an elf file now, the cdvd plugin will attempt to open once,

and if it has an error (like loading no-game), it'll let you continue running

the elf file, and it won't bug you again.

but if it did open successfully, it'll initiate the cdvd plugin normally

(allowing elf files to read the cdvd contents, like the Snes emu for ps2...)

ramapcsx2

..and media players, and other emulators.. and dunno what more.

Ah, codebreaker (yes, it works :p ).

Revision 1155

More cleanup on iVUzerorec.cpp. Fix a few things from the last commit.

arcum42

I noticed that the reformat didn't fix the indentation on all the commented out code, so that's been fixed manually. I'm *assuming* it's reference code, and not just junk I can delete... (Mainly since this whole file really needs reworking.)

I noticed along the way a copy & paste mistake I made, and some code that I was able to simplify a little.

Revision 1156

Initial commit of a new null plugin, GSnull (Linux only until I get around to

porting it). Yes, it's just what it sounds like; running the pcsx2 without any

graphics. May be useful under somewhat bizarre circumstances. :)

arcum42

Though it may not seem like it, there are uses for this; determining if the graphics plugin is causing a crash, for example. And this is a graphical plugin that doesn't require version 2.0 pixel shaders, or any pixel shaders. So Jake should be able to actually run pcsx2 in his coLinux environment with this plugin.

I actually do plan to flesh this out a bit, and make it actually a skeletal graphical plugin that someone could actually create a full GS plugin from. That'll be later, though...

djo...

Useful for benchmarking CPUs, maybe?

arcum42

To be fair, there are two or three graphics commands in this. I had to open an X11 display, pass it to the pad plugin, and close it, or Zeropad would crash when trying to attach to the display to poll the keyboard.

And I'll admit I felt really good when I managed to start a new game in Kingdom Hearts 1 without a picture...

arcum42

That's another potential use. Of course, I'll have to get it showing frame rates first...

I did mainly have debugging, possibly profiling, and having a base to create GS plugins in mind.

v...

What about GSdx

Direct3D9 (Null)

Null (Software)

Null (Null)

how this plugin is different?

Does GSdx still has requirements even if I use some of the Nulls?

arcum42

Well, for one thing, this plugin runs on Linux, which those don't. I suspect that those still check for a new enough version of DirectX, too, though I could be wrong.

Also, source-code wise, this is intended to be a shell of a GS plugin that someone could take, flesh out, and use as the start of their own graphics plugin. I haven't added a bunch of stuff I'd want to be in there, like GifTransfer1-3, yet, but that's the idea.

It's mainly intended for developers, though.

Especially since right now, you not only have to be in linux to use it, you have to go to its folder, type:

sh build.sh all

and then copy the libGSnull.so.0.1.0 file to your plugins folder for it to work.

Porting it to Windows shouldn't be too difficult, though. I basically committed it right after getting it working in Linux, so it's basically a work in progress...

Jake.Stine

GSDX NULL is also (for some reason) still quite remarkably slow for being a NULL plugin, and still has the same memory leak problems on things like the XS2 intro/opening as does the non NULL output selections. And yea, getting GSDX to compile under gcc (let alone for linux) would probably take a lot of significant code modifications.

refraction

I think its because it simulates all the memory transfers and processing (as image data can be requested by VIF and some other GS register read commands) so it is technically a fully functioning NULL plugin. But this also proves that the graphics renderer for output isnt much of a bottleneck on the GS side.

Jake.Stine

>> I think its because it simulates all the memory transfers and processing (as image data can be requested by VIF and some other GS register read commands)

Yeah the registers are important, tho a NULL plugin should in theory just be able to return zeros for the GS->VIF transfer, since that's normally requesting image data for modification/effects processing and re-display.

Revision 1157

R3000air: More recompiler work, but mostly just renamed some files and need to

commit the diffs.

Revision 1158

Mostly port the GSnull plugin to Windows. Currently asserts on startup in

Windows about GSirq not being null. (Though it works if you hit ignore.)

arcum42

And yes, I used the FWnull plugin as a basis for this one. All the dialogs still say "Firewire" in fact...

arcum42

Oh, the pad input doesn't work yet on the Windows port when running, either, btw.

arcum42

Figured out the assert. Still working on the plugin side. Right now, ZeroPad lets it run, but the keys don't respond, and LilyPad aborts.

Revision 1159

microVU:

- mac flags now stored memory instead of in upper 16 bits of GPRs.

- minor changes...

cottonvibes

oh i also implemented the vu cycles hack for mVU...

Revision 1160

All right, this version of GSnull doesn't assert, and if you finagle enough with

LilyPad's settings, you can get the keyboard to work (but not a gamepad).

Occasionally causes the pad plugin to close on starting emulation.

arcum42

And, yes, that's hackish. I have to attach it to some window to get it to work, though...

Revision 1161

GSdx: optimizations here and there

kaboo...

I thought this day would never come *sob*

I'm so happy *cries*

xat...

Working nicely.

Just a note, issue 148 still remains present as of r1161; this affects games with similar effects as well.

gabest11

kabooz:

Huh? Maybe next time I'll use the word "speedup" too :D

xatnys:

There is a commented out line that removes the ghost effect, but also makes it less colorfull (https://code.google.com/p/pcsx2/source/browse/trunk/plugins/GSdx/GSState.cpp?spec=svn1161&r=1161#2060)

Autor...

This is nice but what i have to do with this line to disable ghosting?

Autor...

Oh, i thought we can play upscaled without ghosting

nexxus86

@[email protected]

remove the //

nexxus86

at skip = 17

Autor...

Tried Already, not helped it seems only for PAL and i've got NTSC

Dhalai.L...

Wow it worked in GOW2(PAL). No more ghosting, and dammit it looks gorgeous with higher res.

Revision 1162

Zeropad: Continuing to do some cleanup.

Revision 1163

Zeropad: Add analog.cpp & analog.h.

Revision 1164

Zeropad: More cleanup, and some incomplete work on the POV code, which looks

like it was only halfway implemented.

arcum42

Interesting how many blatant copy and paste mistakes are in here. Initializing an array of axises to be the size of the number of buttons on the controller, for example. Or setting the button state after testing for the axis state. It's amazing this plugin works.

And the hat code is all screwed up. I managed to hack some currently disabled code in to have it recognise hats on the configuration screen, but I still need to figure out how to get it to recognise them in game...

Revision 1165

Zeropad: Experimental. Enable analog key controls in Linux. Currently does not

work well if you also have actual joysticks set up as analog controls.

arcum42

And if anyone wonders why most of my changes on Zeropad affect Linux and not Windows, the two ports share a lot less code then they should. Most of the actual joystick code is duplicated, and given that Zeropad's using SDL, it shouldn't be.

kenzozus...

Windows can't use keyboard. It crash. :(

arcum42

Yeah, I've heard Zeropad works properly for some people in Windows, but I've never had much luck with it. I looked at the code on the Windows side of things, and there are a number of things that clearly aren't coded right in there.

It works just as badly in this latest revision for me as previous versions, though, and didn't change any code that should have affected anything.

I might renovate ZeroPad a bit and try to get it to work properly for me in Windows at some point. Main trouble is I'd really need a new gui coded for it...

arcum42

Just thought I might to take the time to point out the Revision Review Etiquette link on the wiki here:

https://code.google.com/p/pcsx2/wiki/RevisionReviewEtiquette

silicon...

arcum42,

This is somewhat off topic but it would be silly to open a new issue just for that:

Coudl you do me (and all the x86_64 people building without a 32 chroot) a huge favur?

Add an "-m32" gcc switch to the non autotoolized plugins (CDVDlinuz, PeopsSPU2, CDVDisoEFP, maybe others).

Maybe you could make it global for the whole build?

It won't affect the native 32 bits build in the slightest.

thanks

arcum42

Autually, I autotoolized everything but PeopsSPU2 and CDVDisoEFP in the last week or two.

I could add -m32 to the flags. Thing to keep in mind, and the main reason I haven't done it, is that while that switch works for the C and C++ files, it doesn't do anything for the *.S files, which are straight assembly.

So it'd work for most of the plugins, it wouldn't work for ZeroGS, I believe, and definitely not pcsx2. (I've tried it before on pcsx2, so I can state that with certainty.)

arcum42

It was May 1st and 2nd, btw. That was done when I was doing all that work on the null plugins and CDVDiso. Though, come to think of it, I didn't touch any of the non iso cdvd plugins...

silicon...

I am already able to build pcsx2 on my x86_64 without any chroot by just putting the following exports in the main build.sh:

export GCC="gcc -m32"

export GXX="g++ -m32"

export LD="ld -m32"

#this builds using both of my cpu cores for the autotoolized parts

export MAKE="make -j2"

Of course than I have to remove every env var owerwrite for GCC or LINK for the non-autotoolized plugins. It's the only way I've been building on my box, I don't have any 32 bit chroot. The produced binaries are squeaky clean 32 bits.

thanks for liststening :)

arcum42

I'd tried something similar before in configure.ac and not had much luck. This time I think I've got it, though. I needed to add it to CCASFLAGS, as well as all the C/C++ flags...

silicon...

oops sorry, misstyped the env vars... they should of course have been:

CC="gcc -m32"

CXX="gcc -m32"

Any autotools build honours them.

hopefully you haven't wasted any time trying out the bogus ones...

I way I know to pass CFLAGS, CXXFLAGS and LDFLAGS to the autotools without touching the current ones is by using the "AM_" prefixed equivalents: AM_CFLAGS, AM_CXXFLAGS and AM_LDFLAGS.

http://www.gnu.org/software/hello/manual/automake/Flag-Variables-Ordering.html

arcum42

Oh, what I'm doing is modifying CFLAGS, CPPFLAGS, CXXFLAGS, and CCASFLAGS in configure.ac. That's where I've been setting all the optimization flags anyways.

I've actually got most of them to compile now. I'm just trying to get Peops to work...

arcum42

See r1169.

silicon...

cool thanks arcum, I'll give it a shot ASAP. :)

arcum42

If you do, make a minor change first. In 3rdparty\SoundTouch\configure.ac, change:

CFLAGS+="-g -fPIC -Wall -Wno-unused-value -m32 "

CPPFLAGS+="-g -fPIC -Wall -Wno-unused-value -m32 "

CXXFLAGS+="-g -fPIC -Wall -Wno-unused-value -m32 "

CCASFLAGS+=" -m32 "

to

CFLAGS+=" -m32 "

CPPFLAGS+=" -m32 "

CXXFLAGS+=" -m32 "

CCASFLAGS+=" -m32 "

Otherwise pcsx2 will mess up when ZeroSPU2 is chosen as the sound plugin. I'll be committing that change pretty soon...

silicon...

ok, take your time and thanks.

Revision 1166

microVU:

- Major flag algorithm rewrites (work in progress)

- Abused macros to create my tables, knocking off 800 lines of code.

- VU0 and VU1 have different dynarec cache sizes now (vu0's is 1/4 the size of

vu1's)

- Minor changes...

ramapcsx2

Several games show a bit more now, but xenosaga regressed.

I'm getting less and less mvu unknown ops btw. Programm cache is full messages increased though.. :p

cottonvibes

the "program cache is full" message is fine, it just means mVU will overwrite an old saved-microProgram to store its new microProgram.

if you get any messages in red-text those are the bad ones.

"program went over its cache limit" is really bad, and means i need to increase the dynarec cache more (so tell me if you get any of those xD)

i think there's an opcode (unrelated to this flag update )that is causing sps.

and any regressions is because more 'stuff' is showing, and that stuff brings more sps (due to the messed up opcode).

so we just need to find the cause of the sps, and the regressions will probably be gone (hopefully :D)

shagkon

There is lots of "microVU1: Unknown Micro VU opcode called <8000033c>". The message is in white text though. Graphics looks like it was before refraction fixed zeroRecs.

shagkon

Ooops! In God of War 2, I mean.

crushtes...

how is speed in gow 2 with the microVU shagkon? Is it any faster compared to the regular builds?

shagkon

I get "program went over its cache limit" too. This makes the emu crawl then crash. I think there is a lot of work to do before we can compare zerorecs and cottonrecs.

ramapcsx2

Speed is irrelevant on a half working recompiler. Fully working it could be 4 times slower or 4 times faster.

Revision 1167

microVU: coded a speedhack that optimizes out all status flag updates in a

microprogram if the entire program doesn't read the status flags.

FFX's intro got a 8~10% speedup with the hack, and it should be safe for 90~95%

of games.

It can be enabled in microVU_Misc.h

nexxus86

what?

microVU is usable now?

how?

ItsAGraf...

You REALLY don't want to try this now. I assure you. :)

http://img219.imageshack.us/img219/3654/clipboard02v.jpg

shagkon

Good screenshot! Most of the time it's even worse.

nexxus86

i want to try it, but i don't even know how to use it.

how can i change between zerovu and microvu?

shagkon

Try to play with sources. If you are able to enable new recs you will understand it very quickly.

nexxus86

i found it in the pcsx2config.h

yea most times games looking worse, but i got a moment in KH where it looks almost good:

http://img9.imageshack.us/img9/6710/05112009145055.jpg

animus...

And how about speed?

ramapcsx2

Speed is irrelevant on a half working recompiler. Fully working it could be 4 times slower or 4 times faster.

ntcong.it

FFX graphic is broke now, it can render fine ( but not complete ) in previous version....I'm finding the specific rev

ntcong.it

btw,I know that microVU is not complete now, but I'm just reporting :P

nexxus86

it isn't much slower.

FFX intro:

microVU: 60fps

ZeroVU: 68fps

nexxus86

@ntcong.it:

thx, can you post the rev number where it is "less" broken?

bin.gang

Really nice improvements, hope it will officially replace the old VU recompiler soon ^_^.

@ ramapcsx2: Can you pls fix the tlb miss error in Naruto 4 that is caused by r999? It's r1167 now and the error still exists. Also pls have a look at Issue 171 for more detail.

ntcong.it

@nexxus: r1152 has a little better graphic, but the character look funny.

microVU is still incomplete, so I guess it's normal to have *broke* graphic

ramapcsx2

[email protected]:

No, I won't voodoo-fix the game (and break 2 others). The game not booting is

an emulation issue we've had for some time now, and only a new dma controller will really fix it.

To get your game working in your build, just randomly add one or 2 cycles to the load/stores until it boots.

bin.gang

But the game had worked fine in r998 and below. I didn't say that it is not booting, it's just a tlb miss error caused during the gameplay. Btw, if you said so, there's nothing more I can do rather than wait for the new dma controller. Thnks anyway.

cottonvibes

about mVU:

the recs are a work in progress so everything is subject to change.

its also hard to compare speed at this stage because broken stuff can make games faster/slower.

for a rough estimate, so far zerorecs is a bit faster, but my recs are faster in some games with the speedhack.

my benchmarks on a small scene in the ffx intro are:

mVU normal: 46fps low, 49fps high

mVU hack on: 50fps low, 54fps high

zerorecs: 48fps low, 51fps high

there are games my recs run really-slow in, that's most-likely due to computation errors causing infinite loops and stuff. so speed is best compared in games that kindoff-work with mVU.

and right now we're focusing on making mVU more compatible/working, instead of thinking about speed.

I just coded this speedhack cuz the idea popped into my head, and i was curious on how it would impact speed ;p

Revision 1168

GSdx: trying to get rid of windows dependencies, still many classes to replace

:P

gabest11

First, I'll try to port the software renderer to linux, but for that something is needed to display the final image in a window.

Since wxWindows is already there in a branch, I could use that for windowing.

For gfx I think the only choice would be opengl, could anyone help me how to just copy a pixel array from memory to a surface and display it? I have no idea :D

Autor...

Gabest i saw you found the way to fix Ghosting in Gow2 but it works only for PAL, please can you make or say the numbers for NTSC

arcum42

Don't really know much about opengl myself, though I've looked at it a few times. I've just never got around to sitting down and doing anything with it. From what I've heard, the most popular OpenGL tutorials are the NeHe ones:

http://nehe.gamedev.net/

Lesson 6 is texture mapping... Those were the ones I was planning to sit down with at some point. Zeyditz would know more about OpenGL, since he's been working on ZZogl.

OTOH, I could easily set up a bad gtk+ dialog box like all the other linux plugins have, or, spending a bit more time, write one in wxwidgets.

gabest11

arcum42:

Old gssoft used gtk (and sdl), its source is still up on sourceforge, I could probably copy that.

But I'd rather have something that works on windows too, so I don't have to keep two different implementations of the dialogs.

[email protected]:

Could you make a .gs for ntsc then?

gabest11

arcum42:

Do you know if opengl works under virtual box + ubuntu?

I can see transparency and windows flying in 3d, some kind of acceleration should already be there, emulated or real.

arcum42

Yeah. It's probably for the best, anyways. The gtk+ code's all generated by an obsolete version of a gui builder I keep around for the purpose. Newer versions don't build code, they read the .glade file at runtime and generate it from that, but I've never managed to update pcsx2 to do that due to threading issues...

And wxwidgets is the future of pcsx2, anyways.

diegoocampo8

From the changelog of VirtualBox 2.2.0: "OpenGL 3D acceleration for Linux and Solaris guests (see chapter 4.8, Hardware 3D acceleration (OpenGL), User Manual page 70)"

And extracted from the Manual: "Technically, VirtualBox implements this by installing an additional hardware 3D driver inside your guest when the Guest Additions are installed. This driver acts as an OpenGL hardware driver and reports to the guest operating system that the (vir-

tual) hardware is capable of 3D hardware acceleration. When an application in the guest then requests hardware acceleration through the OpenGL programming interfaces, these are sent to the host through a special communication tunnel implemented by VirtualBox, and then the host performs the requested 3D operation via the host’s OpenGL programming interfaces."

Autor...

gabest11:

here's the gs dump http://rapidshare.com/files/231650939/gs.rar.html

BTW your code for ICO turns off the wall of Fog, maybe you can make something like this for GoW

arcum42

I just opened up a VirtualBox session with a copy of Ubuntu installed in it, and glxgears, a sample OpenGL program that comes with mesa-utils (which I think is standardly installed) runs fine.

This is under Linux, but it should be the same in windows.

(And yes, I have several dozen virtualbox and vmware sessions lying around with different oses in them. Somewhat of a hobby of mine.)

And keep in mind, since OpenGL's designed to be multi-platform, you should be able to test a lot of it in Windows, too.

And, as a note, while this isn't used in the main project, we're using Code::Blocks as an ide for Linux in the wxwidgets branch. So far it seems pretty nice. (And it's cross-platform, Linux and windows).

gabest11

diegoocampo8:

Nice, I'm pretty impressed by virtual box, first time I tried it.

[email protected]:

Problem is, I never played any of those games, only trying to fix the dumps :D

gabest11

arcum42:

Yea, codeblocks is what I installed too. Seems to be the number one ide recommendation on the web.

Autor...

gabest11:

lol, well i hope you'll find the numbers in the dump

Jake.Stine

I have some old code lying around that opens up a simple OpenGL software viewport. A good old fashioned pixel pusher so to speak. Performance on Win32 matches DirectX for the purposes of software rasterization. Only trouble (maybe?) is that I used GLUT for the window manager. Setting it up to work with wx instead should be trivial tho, iirc.

arcum42

Looks simple enough. There's a sample of setting up a wxGLCanvas in the wxwidgets wiki:

http://wiki.wxwidgets.org/WxGLCanvas

Zeydl...

Well, drawing one array into screen is easy:

GLuint texture[1];

glGenTextures(1, &texture[0]);

glBindTexture(GL_TEXTURE_2D, texture[0]);

glTexImage2D(GL_TEXTURE_2D, 0, 3, texture1->sizeX, texture1->sizeY, 0,

GL_RGB, GL_UNSIGNED_BYTE, texture1->data);

glEnable(GL_TEXTURE_2D);

glBegin(GL_QUADS);

glTexCoord2f(0.0f, 0.0f); glVertex3f(-1.0f, -1.0f, 1.0f);

glTexCoord2f(1.0f, 0.0f); glVertex3f( 1.0f, -1.0f, 1.0f);

glTexCoord2f(1.0f, 1.0f); glVertex3f( 1.0f, 1.0f, 1.0f);

glTexCoord2f(0.0f, 1.0f); glVertex3f(-1.0f, 1.0f, 1.0f);

glEnd();

If you array have non power of 2 dimenasions, than you should use GL_TEXTURE_NV

silicon...

GL_TEXTURE_NV is an nvidia-only old extension

from http://www.opengl.org/documentation/current_version/

"Non-Power-Of-Two Textures

* The restriction of textures to power-of-two dimensions has been relaxed for all texture targets, so that non-power-of-two textures may be specified without generating errors. Non-power-of-two textures was promoted from the ARB texture non power of two extension."

Zeydl...

No, it's not Nvidia only. It's work's better than ARB_texture_non_power_of_two

silicon...

>No, it's not Nvidia only.

Yes it is, see below.

>It's work's better than ARB_texture_non_power_of_two

On NVidia hardware, I am sure it does.

So I have ATI Catalist 9.4 (OGL3 support)

$fglrxinfo -x|grep GL_TEXTURE_NV

$ fglrxinfo -x|grep non_power_of_two

GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,

Those are te only nvidia extensions avaiable (ATI impements them only when they make sense)

$fglrxinfo -x|grep NV

GL_NV_blend_square, GL_NV_conditional_render,

GL_NV_copy_depth_to_color, GL_NV_texgen_reflection,

GLX_NV_swap_group, GLX_NV_swap_group,

There you go!

Zeydl...

Well, you better try it on code. It works. And GL_ARB_texture_rectangle and GL_TEXTURE_NV have simply the same id.

Revision 1169

Linux: Add -m32 to the compiler flags of pcsx2 and all plugins.

arcum42

Grrr... Something's screwing up running pcsx2 in here, and it's only showing up if you fully recompile everything.

Time to hunt around a while to see which config file did it...

arcum42

Ah; think it's either ZeroSPU2 or SoundTouch. Probably the latter.

arcum42

Yep. I'll commit soon. Just going to do a few other things with the makefiles first.

silicon...

BTW PeopsSPU2 needs and -m32 switch to the LINK env var (plugins/PeopsSPU2/Makefile line 24) or it will fail linking.

Thanks a lot for the commit, you're pretty much saving my life with this :)

P.S.: I confirm all the plugins are 32 bit by issuing a "file" on them. :

$ file bin/plugins/*

bin/plugins/cfgCDVDisoEFP: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

bin/plugins/cfgCDVDlinuz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, stripped

bin/plugins/libCDVDisoEFP.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libCDVDiso.so.0.9.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libCDVDlinuz.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libCDVDnull.so.0.8.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libDEV9null.so.0.4.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libFWnull.so.0.5.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libSPU2null.so.0.7.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libspu2PeopsOSS.so.1.6: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libUSBnull.so.0.6.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libZeroGSoglr.so.0.96.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libZeroPAD.so.0.3.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/libZeroSPU2.so.0.1.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

bin/plugins/ps2hw.dat: data

arcum42

Commited before catching that. Oh well, next commit.

And glad to help. I'd wanted to do this a while back, but hadn't figured out that you need to add it to CCASFLAGS as well.

Besides, I don't really like pcsx2 being a second class citizen on Linux 64, that's just how it worked out...

arcum42

Actually, looking, I think lines 31 and 35 are the appropriate lines for that. I caught one, but not the other.

Revision 1170

Fix up r1169 a bit, and a few minor changes.

Revision 1171

GSdx: small fixes

ramapcsx2

People with god of war 2 might wanna check this out ;)

AzNLuC...

does this fix the gow2 ghosting at higher res?

crushtes...

Yes it does. Not out of the box, you have to remove the // and compile.

Autor...

Thank you Gabest!

andreabo...

This revision make the the textures from SIMPSON THE GAME to become BLACK.

LOTS of MISSING TEXTURES.

Autor...

Are you sure this very revision cause this?, this revision is the possible fix for GoW2 Ghosting on high-res bug

Autor...

it seems r1168 make the the textures from SIMPSON THE GAME to become BLACK

ramapcsx2

I deleted most of the not so useful post.

Remember to stay on topic with code comments..

Revision 1172

microVU: fixed a few problems...

eliotfur

So, I just missed that moment when microVU began to actually LOAD games... Nice...

Crash Mind Over Mutant - microVU1: Unknown Micro VU opcode called (8000033c), garbage.

Devil May Cry 1 - SPS, slowdown

Devil May Cry 3 - Intro looks almost perfect, has some interlacing errors all the time, SPS ingame.

Silent Hill 2, Okami, Rayman Raving Rabbids, ICO - SPS

Disgaea - no problems as far, - and Disgaea 2 - only slight SPS...

arcum42

As a note: anyone planning on testing out the microVu code should keep in mind that it only compiles in Windows currently...

shagkon

I'm still getting "program went over it's cache limit" in gow2.

http://img517.imageshack.us/img517/4223/gow2microvu.jpg

ramapcsx2

We're working hard on this, and on some debug builds it's starting to look very promising ;)

http://img3.imagebanana.com/view/murxi7bw/Unbenannt.jpg

ramapcsx2

http://img3.imagebanana.com/view/azcvfqfk/Unbenannt.jpg

Revision 1173

microVU:

-increased rec-cache so GOW2 should be happy (untested)

-hacked-fixed some problems for now that I'll be working on properly fixing over

the next few days.

cottonvibes

fun stuff:

FFX appears to be perfect with the fixes (and faster than zerorecs with the mVU speedhack), Disgaea 2's minor SPS is gone, and other games show a lot more stuff.

After properly fixing this stuff, compatibility should rise even more.

animus...

Wow, cotton, you rocks!

xat...

Odin Sphere also appears to be working perfectly.

andreabo...

is this micro multithread? so can i use all four cores of a quad or X4 processor?

animus...

More games working now... maybe it's time to include it already as an option. For the sake of "mere" users ;)

cottonvibes

andrea:

its not threaded yet; its best to wait till its working better before introducing multi-threading problems :p

animus:

i want to wait till its more compatible before adding it as an option.

right now the games are working better because of some hackfixes, so i want to properly fix these hacks (as well as other bugs) before releasing to the public.

shagkon

Well, GOW2 still isn't happy. Here is emulog http://www.sendspace.com/file/1mzt4j

Line...

Thanks cottonvibes !!! This fix is asskickin'cool ! Waiting for applying this fix as new checkbox in gamefixes dialog window :)

Autor...

Great commit cotton, but it seems new VU has the same problem with Denormals are zero in some games which was fixed in Zerorecs

LM1...

.\common\include\Pcsx2Config.h

enable

//#define PCSX2_MICROVU

//#define PCSX2_MICROVU_

enable = remove "//"

Revision 1174

Found the typo responsible for the clipping bug.

Changed a few lines from cotton's idea of readability to mine, at least

until cotton reverts it.

Revision 1175

And the same typo elsewhere.

Revision 1176

microVU: due to the 2 flag fixes the hacks can go now :p

xat...

I suppose the plan at this point is improve compatibility (things like resolve sps in general), begin to implement multithreading, and then move to open testing?

ramapcsx2

Hmm, no.

The plan for now is play some games, watch star trek again, study for university and uhm.. play some more games.

:p

kaboo...

can I switch from "Star Trek" to "Big Bang Theory" cause I'm not a trekkie... "Futurama" is good too Oo

back to the topic xD: the testing will be fun when multi_threading comes into play XD

xat...

Out of curiosity in microVU's testing, have there been any cases where micro VU worked where Zero VU didn't?

ntcong.it

I think not at the moment, microVU is still WIP

btw, FFX show *more* in those 3 changes at mVU recently.

mVU with the hack gets same speed as zero VU :).

Good works

cottonvibes

xatnys:

yeah, zerorecs fails some of my custom VU tests that i programmed (microVU gets the same result as ps2).

however, as for real games that work better with mVU, currently i don't know any :p

unless you count mVU with speedhacks being faster then zerorecs in games such as ffx.

Revision 1177

microVU:

- Implemented Nneeve's logical min/max algorithm. This should fix the problems

with DaZ and mVU.

- Applied a patch by Gigaherz that more clearly distinguishes Immediate values

in microProgram log files.

- Added a speedhack to disable the logical min/max code. (see below)

Note:

From my testing, using DaZ on mVU doesn't do much. However I have an AMD cpu,

and they don't benefit as much as Intel C2D's from DaZ. So this could be

effecting results.

The logical min/max code is SLOW, and the little-benefit I get with DaZ means I

get better performance with DaZ off and the min/max speedhack (which disables

the extra min/max code).

It would be nice is someone with an Intel C2D can compare the speed of:

-mVU normal without DaZ

-mVU normal with DaZ

-mVU min/max speedhack without DaZ

-mVU min/max speedhack with DaZ

eliotfur

I could... Reliable benchmark, anyone?.. Or is it still plus/minus 1 fps in some game intro?..

Autor...

Thanks once again, cotton!

shagkon

I just tested FFX intro. Yep, there is no noticeable difference.

ramapcsx2

Core2Duo with sse4.1

FFX scene with lots of characters:

-mVU no hacks, DaZ on = 67fps

-mVU no hacks, DaZ off = 58fps

-mVU min/max hack, DaZ on = 67fps

-mVU min/max hack, DaZ off = 61fps

Jake.Stine

afaik, FFX was one of the few games that benefited very little from DaZ anyway. Perhaps someone should benchmark TOTA or something? :)

spam.Sai...

if you talk about tales of the abyss, it's not possible to benchmark this game. it suffers from very heavy sps( i can't get further then the first menu screen, whole pc slows down and mouse gets jumpy :) )

eliotfur

Well, one thing that definitely doesn't benefit from DaZ is DMC3 intro:

I measured the time it takes to render intro from when the phone rings to the end, when the screen fades out. It's a total of 10700 frames. To get average fps I simply divided one by another...

Core2DUO E6550 (no sse4.1) at 3048 MHz

DMC3 intro (10700 frames):

-mVU no hacks, DaZ on = 84.9fps

-mVU no hacks, DaZ off = 84.9fps

-mVU min/max hack, DaZ on = 88.4fps (4.1% better than no hacks)

-mVU min/max hack, DaZ off = 88.4fps (exactly the same number of seconds)

-zerorec, DaZ on = 87.0fps

FFX (intro from frame 0 to frame 9000)

-mVU no hacks, DaZ on = 56.3fps (+2.6% from DaZ)

-mVU no hacks, DaZ off = 54.9fps

-mVU min/max hack, DaZ on = 59.2fps (+15.9% from DaZ) (5.2% better than no hacks)

-mVU min/max hack, DaZ off = 51.1fps

-zerorec, DaZ on = 62.1fps

cottonvibes

thanks for the testing guys ;p

Revision 1178

microVU: fixed a bug in the Jump opcodes. this probably fixes a lot of problems

in games (grandia 3 intro works properly now, ffxii shows more stuff in-game,

etc...)

shagkon

GoW2 works now. It's very slow, but even goes ingame.

joaolvas...

Good work, but Gran Turismo 4 still has garbled menus, but keep this work, i think is good.

genci16

Anyway i can confirm that Dragonball infinite world for the first time to mo is showing glitches (part of textures missing from the characters). I haven't had this problem with build 1164.

eliotfur

I'm still getting microVU1: Unknown Micro VU opcode called (8000033c) in Crash Mind Over Mutants... This Error is gone in FFXII, but not in this game...

FFIXX goes ingame, the only bug I found so far is "funny looking characters"... =^_^=

eliotfur

Beyond Good and Evil crashes in MTGS.cpp at the line 556

If I disable MTGS it crashes in VifDma.cpp in VIFunpack function at the line 686

I don't know, I may be wrong...

Master.h...

TEkken 5 and GOW 1 are screwed up!

but BLoody Roar 3 seems to has a slight boost + polygon syndrome! (when ussing Vu skip mode! )

in normal mode they are really slow! considered to the former svns !

Autor...

GoW1/2 much better now, also fixed bug in Okami when some far objects are half textured and half black in ZeroRecs but still hage SPS and Geometry misses and *slowdowns It seems cause of many Upper opcodes still unimplemented

Revision 1179

GSdx: more refactoring (aka search and replace)

keb...

i'm getting and error compiling, missing file?

1>c1xx : fatal error C1083: Cannot open source file: '.\GSRect.cpp': No such file or directory

Revision 1180

microVU:

* Smartened up the microprogram cache. Programs are (quite accurately) selected

based on how often and how recently they have been used. Solves constant

recompilation issues in games like FFXII and Tekken 5 [but not the SPS, sorry!].

* Changed memory allocation so that microprogram blocks are allocated *on

demand* -- this saves a lot of memory and makes it possible to test 64-program

caches (which would previously fail due to exceeding 2gb ram allocations!).

Also fixed a few small memory bugs in Init/Alloc, and made it so mVU only

allocates memory once instead of on every reset. :)

* Tweaked uses of progSize in microVU.h so that it's consistent [all instances

of progSize are (vumem_size / 4) now]

cottonvibes

"Programs are (quite accurately) selected

based on how often and how recently they have been used."

if you're talking about the program elimination (when cache is full), then i initially did this, but there is a problem (i'm not sure if your code solves it).

basically a program can be used alot in the beginning of a game, and then never used again later on.

if you base your program elimination on how much a program is used, then its possible a program that was used alot initially (and never used again), will never be deleted.

my solution was just to pick a semi-random program to delete, instead of basing it on some 'used' ammount.

"Changed memory allocation so that microprogram blocks are allocated *on

demand."

well i purposely allocated all memory at runtime, because you mentioned C++ has slow memory allocation due to no garbage collection.

so allocating on the fly should be slower no?

cottonvibes

hmm okay its hard to look at the code here at work, but i guess your code solves the problem i mentioned before by factoring in how recently the program was used. :p

Jake.Stine

>>well i purposely allocated all memory at runtime, because you mentioned C++ has slow memory allocation due to no garbage collection.

so allocating on the fly should be slower no?

Doesn't really matter if the recompiler isn't working in overdrive. Also, it was allocating so many blocks that at a certain point it was taking about 1/50th of a second to allocate any new blocks at any point in the program (and things like logging, for example, always have to alloc and free blocks to function properly), so it was killing performance all over. But in any case, 400megs just for microprogram cache at startup was a bit excessive. ;)

cottonvibes

tested ffxii with the code, and it runs great now ;p

(well still sps on characters but not related to this)

great job :p

Revision 1181

Removed the microVU enabler define (oops >_<), and removed some SPU2 counters

message since the code in question is behaving as intended.

cottonvibes

lol, you officially made mVU On by default for like 6 minutes! :p

ramapcsx2

Well, in some cases the occasional user wouldn't have noticed.

FFX for example, or Disgaea :p

bin.gang

Does it mean that the old VU Recompiler won't continue to be developed anymore?

Revision 1182

GSdx: just fixing the typos...

ramapcsx2

Hmm, I just benched this revision against one before the dependency cleanup.

It's gotten quite slow now :/

Xenosaga went from 154 to 128 fps (more drastic case), others loose around 5% speed.

Hope its just a typo or smth :p

Saif...

Gabest,

Black screen ...

Gsdx10 r1182, SSSE3/SSE2

MGS2 NTSC

joaolvas...

GT4 (NTSC) has Black Screen with this version.

gesielon...

for me breack

gesielon...

break :D

hondza...

Black screen all games. :(

AntiS...

Nothing seems to be really broken, but performance went down 15-20fps overall and all video output is blurry.

gsdx10 SSE4, hardware, no interlace

gesielon...

Break when load states.

gabest11

ok, there might be other typos, use older builds until everything is fixed :P

Revision 1183

Minor tweaks here and there. Removes a couple compiler warnings, adds in a -m32

flag I missed, and updates the Makefile a bit.

arcum42

Oh, and regards the microVU.h change, while that was close, __fastcall is already defined in Pcsx2Defs.h to __attribute__((fastcall)) for Linux, so it's better to just keep the line the same in both versions.

cottonvibes

yeah jake told me about that a while ago, i thought he had fixed it already :D

i think he did it in his branch but not on the main trunk.

arcum42

I kept seeing it, then forgetting about it, so figured I might as well take care of it now.

Haven't nearly started getting it to work on Linux yet. If microVU keeps making this much progress, I may have to start actually working on it. :)

Right now, it gives errors like:

microVU_Misc.inl: In function 'void mVUcheckSflag(int)':

microVU_Misc.inl:310: error: 'mVUopU' was not declared in this scope

microVU_Misc.inl:310: error: expected primary-expression before ')' token

microVU_Misc.inl:312: error: 'mVUopL' was not declared in this scope

microVU_Misc.inl:312: error: expected primary-expression before ')' token

microVU_Log.inl: In function 'void __mVUdumpProgram(int)':

microVU_Log.inl:89: error: 'mVUopU' was not declared in this scope

microVU_Log.inl:89: error: expected primary-expression before ')' token

microVU_Log.inl:111: error: 'mVUopL' was not declared in this scope

microVU_Log.inl:111: error: expected primary-expression before ')' token

microVU_Compile.inl:267: error: 'mVUcompileVU0' was not declared in this scope

microVU_Compile.inl:268: error: 'mVUcompileVU1' was not declared in this scope

microVU_Execute.inl:99: error: 'mVUcleanUpVU0' was not declared in this scope

microVU_Execute.inl:100: error: 'mVUcleanUpVU1' was not declared in this scope

microVU_Execute.inl:124: error: no matching function for call to 'mVUsearchProg()'

I'm guessing that most of that is either includes, or code that isn't implemented yet. Gcc has this habit of trying to make sure everything works, even if it's never called...

cottonvibes

i bet most of those can be fixed by some function prototypes.

they're all implemented stuff, GCC seems to be annoying about needing function prototypes with templated functions that MSVC++ doesn't care about.

if you start working on it and all it needs is some function prototypes, i'd appreciate it if you put them in microVU.h with the other function prototypes. (i like to keep all similar stuff together :p)

arcum42

No problem. I'll put any function prototypes I put in there.

How soon I get to it all depends how much GCC complains, and what I feel like working on, since I've sort of been jumping between a dozen projects depending on mood... :)

arcum42

Looks pretty easy to fix, actually...

arcum42

See r1187.

Revision 1184

Zeropad: Archiving some hat work. Still disabled and buggy, but I want to be

able to revert back here if neccessary.

Revision 1185

GSnull: Add some Gif Transfer code from pcsx2 (not currently hooked in).

arcum42

And yes, most of that is slightly modified code from MTGS & GS. ZeroGS originally did the same thing (only it was just GS then). Difference is that there have been bugfixes since then that haven't made it back to ZeroGS. :(

gabest11

gsdx has a bit cleaner logic inside giftransfer, that in pcsx2 is an older version.

arcum42

Thanks, I'll have to look at that and update the code.

And if you find yourself wanting to make changes to the GSnull code at any point, feel free, btw...

Revision 1186

GSnull: A bit more work on the gif transfers.

Zeydl...

Well, are you sure about pMem as (u8*)? ZeroFrom use (u32*)pMem as (u8*)pMem + (u32*) addr, and you give to_gifTransfer only (u8*) part?

arcum42

Not absolutely sure, no. The GifTransfer function is a slightly modified copy of the gifTransferdummy function in pcsx2, and that uses a u8. I wasn't sure yet which was correct, and hadn't really sorted out the proper way to handle GifTransfer1 yet. That's the main reason I hadn't enabled it yet.

The fact that it crashes Kingdom Hearts 1 when you go in-game if you enable that code is also part of that. :(

I mainly wanted to get the code in place first. I figured I'd straighten it out afterwards...

arcum42

And it looks like GSdx's code uses u8's, so I'll probably go with that, as well as updating it to a version of gabests current code, since that's apparently more up to date then the code in pcsx2...

Revision 1187

microVU: fixed up microVU so that it compiles in Linux if the appropriate

defines are uncommented, and runs surrealistically.

cottonvibes

heh glad that was all that was needed :D

arcum42

So am I.

I even fired up Kingdom Hearts 1, and verified that it was, in fact, using the new VU's, and didn't have any runtime issues. Admittedly, I was able to see through walls, and there was various graphical distortion, but I believe that's normal... :)

cottonvibes

yeah the game still has bugs with mVU.

but at the rate we've been going, it'll probably be fixed soon.

arcum42

That's what I figured, looking at your recent commits. That's one reason why I was starting to think it was about time to ease it into working on Linux. I expected it to take longer, though...

Revision 1188

microVU:

-implemented Jake's suggestion for proper alignment in the microVU struct.

-minor optimizations/changes

Jake.Stine

Yea I learned about the alignment thing when I tried to do the same thing in the MTGS. It worked most of the time (read: always for me!) on MSVC, but I got reports from some people that their own local builds would crash on an illegal op. And then it just failed totally in linux.

It's not a critical issue if you're not using SSE on the flags registers, since that's where illegal ops come from (unaligned SSE memory ops). But then if you do add such ops in the future, it's one less headache to worry about when someone reports a random mysterious crash for seemingly no reason. ;)

mahmoudk...

jake stain where r u man i missed you

i always was walking up checking the google page and see u making about 5 new comments and now is zero what man we want the 2000 comment at the end of this month u r a legend here in egypt you and cttonvibs i am going to give your programming to computer science department of engineering faculty

thanx cotton and jake for your hard work and hope more improvment

cottonvibes

jake: i am using sse ops with that memory, that's why i needed it aligned! :p

xat...

Alright. ToA exhibits the usual SPS but it seems to be getting better.

Opcode error -

microVU1: Unknown Micro VU opcode called (8000033c)

After bearing through the menu for a while, several different cache limit errors -

microVU Error: Program went over its cache limit. Size = 0x109fa4

microVU Error: Program went over its cache limit. Size = 0x1150d4

microVU Error: Program went over its cache limit. Size = 0x1176ec

microVU Error: Program went over its cache limit. Size = 0x119403

microVU Error: Program went over its cache limit. Size = 0x119495

microVU Error: Program went over its cache limit. Size = 0x1195b9

microVU Error: Program went over its cache limit. Size = 0x11970d

microVU Error: Program went over its cache limit. Size = 0x11c28a

microVU Error: Program went over its cache limit. Size = 0x11c343

microVU Error: Program went over its cache limit. Size = 0x11f7cb

microVU Error: Program went over its cache limit. Size = 0x1204c1

microVU Error: Program went over its cache limit. Size = 0x12236a

microVU Error: Program went over its cache limit. Size = 0x123c18

microVU Error: Program went over its cache limit. Size = 0x123f4a

microVU Error: Program went over its cache limit. Size = 0x124599

microVU Error: Program went over its cache limit. Size = 0x124a12

microVU Error: Program went over its cache limit. Size = 0x124d59

microVU Error: Program went over its cache limit. Size = 0x124e9d

In the actual log these actually repeated almost hundreds of times; unfortunately I cut if off early before I noticed the cache limit errors. I've been trying to repeat it's been crashing around the unknown opcode error.

Will keep testing. :p

Revision 1189

Linux: Work on dialog boxes for a bunch of plugins. mostly null plugins. Not

finished, by any means, but this seemed like a good commit point.

arcum42

For a more detailed idea of what is done in this commit:

Clicking on About on the FWnull plugin no longer crashes pcsx2.

The close button on ZeroPad's about box works.

FWnull, USBnull, and SPU2null all now have simple config dialogs that let you turn logging on and off and save that setting to an ini file.

I started to move the Dev9 config dialog to dev9 and create a dialog for CDVDnull that's similar to FWnull and co, but haven't hooked them up.

I plan to do the same for GSnull, but haven't done it yet.

ntcong.it

Pressing "Esc" in CPU, Speedhacks and Advance dialog will make main Pcsx2 dialog lost focus and crash :)

arcum42

Really? I'll have to look into that some time...

arcum42

Taken care of in r1190. :)

Revision 1190

Linux: Fix focus problems with various dialogs when hitting escape, and hook in

dev9's dialog box.

ntcong.it

Nice one, Pcsx2's main window has focus when we press "ESC", but it still lost focus when we press the "close" button in the top-right corner, or just "alt+F4" :P

arcum42

Yeah, I added a callback to any of the actual dialog boxes, telling them when they are closed to call a function that all it does is sets the sensitivity on the main window to true.

Before, it knew to do it when you hit Ok or Cancel, but was going on automatic if you exited any other way...

bWo...

Somehow it wont compile

st -f 'Linux/Config.cpp' || echo './'`Linux/Config.cpp

Linux/Config.cpp:29:20: error: Config.h: No such file or directory

Linux/Config.cpp: In function ‘void OnConf_Ok(GtkButton*, void*)’:

Linux/Config.cpp:112: error: ‘is_checked’ was not declared in this scope

Linux/Config.cpp: In function ‘void DEV9configure()’:

Linux/Config.cpp:130: error: ‘set_checked’ was not declared in this scope

Linux/Config.cpp: In function ‘void LoadConfig()’:

Linux/Config.cpp:148: warning: format ‘%hhx’ expects type ‘unsigned char*’, but argument 3 has type ‘int*’

make: *** [libDEV9null_a-Config.o] Error 1

One revision before was ok, debian lenny again

keb...

can't compile dev9 either

1>DEV9.obj : error LNK2001: unresolved external symbol "void __cdecl LoadConfig(void)" ([email protected]@YAXXZ)

Zeydl...

Arcum! Maybe you know how should I properly close GSwindow in full screen mode?

arcum42

Not offhand. ZZogl and ZeroGS use X11 directly to create windows, and most of the time I've been working with windows is using Gtk+ windows...

Revision 1191

GSdx: this should fix d3d9 mode and the aspect ratio bug

kenzozus...

Black screen all game. Last revision works 1171.

DX9

GSdx-ssse3

nVidia user 8800GT

C2D E6600

GREGORIO...

Yeah. Black screen on all games

heatbla...

Anyone tested Steambot Chronicles in GSDX or ZERO GS?

Revision 1192

GSdx: fixed a few more typos in GSVector4i, the black screen bug should be gone

coopm...

its gone - thx a lot

its all working now

joaolvas...

In GT4 Crash in DX10.

gabest11

then drive more carefully :D is it a new crash?

joaolvas...

The game enter ok, but when i select a car, crash, in DX10.

joaolvas...

And the version r1190, still can play, because has garbled menus. The only way is select x1.5 Cycle Rate. I'm just try to help Gabest and i appreciate very much your work.

joaolvas...

Works, I am so sorry, was another problem, once again apologies Gabest. The menus still the same :

http://img41.imageshack.us/my.php?image=image2w.jpg

and

http://img41.imageshack.us/my.php?image=image2m.jpg

I no it was not you, is other people, but if you can tell them....

Very thanks and once more sorry.

Jake.Stine

>> I no it was not you, is other people, but if you can tell them....

WE KNOW. We banned you from the forum specifically because WE KNOW but you KEPT POSTING ABOUT IT ANYWAY.

>> Very thanks and once more sorry.

Stop being so annoying and you won't have to apologize so much.

gabest11

gt4 menu text got scrambled around when ref was messing with the transfers, no idea why it looks so now, I have a build from 03/20 and the text is still ok there.

gabest11

an old build of pcsx2, not gsdx

joaolvas...

I was banned for the first time in a forum, by person who should have stock problems, I think they are right, I have no age for these things, look like a kid, but i like very much the game because my profession.If i can help, i have a lot of games, tell me, otherwise I stop to say whatever.

About Krakatos, we will talk soon.

Thanks.

ramapcsx2

It's some dma priority, or timing issue. We know how to (hack)fix it, but that isn't the point here :p

Saif...

Gabest,

fps really goes down ...

Somthing wong with GsDx SSE2, it crashed, GsDx10 SSE2/SSE3 fine.

gabest11

do you mean sse4 crashes and sse2/3 is fine?

Saif...

No

Just SSE2 Build using Dx9 Hardware.

Revision 1193

Linux/Plugins: I left this out at some point...

Revision 1194

GSdx: blur removal works again

Saif...

Gabest,

fps goes normal again ...

SSE2 and SSSE3 work fine again on both Dx9 & Dx10

Saif...

Gabest,

fps goes normal again ...

SSE2 and SSSE3 work fine again on both Dx9 & Dx10

gabest11

Strange that one fullscreen blend takes so much hit on your frame rate, I can only guess that you play at either too high resolution or have a weak gpu.

Saif...

Internal Res 1280x720

Seinfeld...

Don't know which revision of GSdx helped, but now on FFXII in the begining when the spaceship comes down to atack it only slowdown 5fps, meaning between 1006 and 1194, this same scene that was runing at 20-35fps is now 55fps. Thx.

Revision 1195

R3000air: Lots more recompiler work, optimizations, bugfixes, and stuff. Still

a while until I get it all shaped up into a full blown rec tho.

mahmoudk...

can i ask something???????? what is the use of r3000air??

ntcong.it

Afaik, it'll replace the current EERec

kaboo...

i thought IOP replacement (R3000) or otherwise called the psx like chip

or am I seriously wrong?

ntcong.it

Yes, it the EE/IOP recompiler

Revision 1196

R3000air: Start work on getting this to compile in Linux. Incomplete.

arcum42

For reference, this is about as far as I got:

In file included from R3000air/dynarec/iR3000air.cpp:21:

R3000air/dynarec/iR3000air.h:283: error: explicit specialization in non-namespace scope 'class R3000A::IntermediateInstruction'

R3000air/dynarec/iR3000air.h:293: error: too many template-parameter-lists

R3000air/dynarec/iR3000air.h:316: error: explicit specialization in non-namespace scope 'class R3000A::IntermediateInstruction'

R3000air/dynarec/iR3000air.h:365: error: too many template-parameter-lists

R3000air/dynarec/iR3000air.h:366: error: too many template-parameter-lists

R3000air/dynarec/iR3000air.h:368: error: explicit specialization in non-namespace scope 'class R3000A::IntermediateInstruction'

R3000air/dynarec/iR3000air.h:369: error: explicit specialization in non-namespace scope 'class R3000A::IntermediateInstruction'

R3000air/dynarec/iR3000air.cpp: In function 's32 R3000A::recExecuteBlock(s32)':

R3000air/dynarec/iR3000air.cpp:353: error: expected `(' before '{' token

R3000air/dynarec/iR3000air.cpp:354: error: 'push' was not declared in this scope

R3000air/dynarec/iR3000air.cpp:354: error: expected `;' before 'ebx'

R3000air/dynarec/iR3000air.cpp: In function 'void R3000A::recAlloc()':

R3000air/dynarec/iR3000air.cpp:417: warning: unused variable 'RomPages'

R3000air/dynarec/iR3000air.cpp:418: warning: unused variable 'Rom1Pages'

Jake.Stine

I'll clean up the namespacing soon. It's kind of all over the place because of how I had to hack things in initially.

arcum42

All right, cool. It happened to occur to me that it'd be a good idea to have this compiling on Linux, or close, before we actually start using R3000air in the main time, and I figured this was as good of a time to start as any...

And, yes, I'm pretty much bouncing back and forth between different branches, and different sections of the code right now.

Revision 1197

Half fix for Gran Turismo 3-4 menus. Some text is still garbled but better than

it was. Oh this was done by implementing "Wait for GS transfers" a bit better

than the previous attempt

AntiS...

I'm not sure why, but this svn breaks Persona 3. I've used different plugins and versions thereof, and have fiddled with all available settings, which seems to narrow it down to PCSX2.

The game won't load as it would normally and sits at a black screen. When loading a save state from the PS2 BIOS screen, it runs normally for a moment, but locks up with the sound buffer looping after a short time or any user interaction.

Dhalai.L...

@Antisoul: This problem sounds a lot like Fatal frame 2 and 3 problem.

jfre1...

Antisoul: And you`ve checked the previous version to see if the game broke on this exact revision? or taking a guess?

AntiS...

hockl: I've been keeping up-to-date on the revisions, but I did skip 1195 and 1196.

xat...

This revision also broke ToA on my end. Works up to r1196; with r1197 it starts up normally but shows only a black screen, and shortly after the framerate drops to sub-30fps (from ~110fps+).

refraction

I suspected some games which use Path3 Masking would break, which is a pain in the rectum :P ill look in to it

AzNLuC...

This revision broke soul calibur 3, doesn't get past intro screens now.

Revision 1198

Cleanup: Moved some rather intrusive instances of global namespace pollution in

Sio.h into a new sio_internal.h, so that the rest of the world doesn't have to

ensure the pain of having BREAK and RTS macro'd to integers. ;)

arcum42

Thanks. Didn't notice that breakage.

That's the trouble with my going through and fixing up the null plugins, really. I'm only doing it on the Linux side, and the Windows side can get a little out of sync. I can test it in Windows, but since I'm using the Express version, I can't easily make gui changes.

I'm basically making it so most of the null plugins have a configuration window with the title being the name of the plugin, and one checkbox labeled "Enable Logging" which toggles conf.Log, and saves its state to an ini file.

I thought about making them use wxwidgets, but I figure that can wait till we already have it in the trunk as a dependency.

Revision 1199

Break out a bunch of clutter from CDVD.h into its own file. Meant to do this a

while back, but forgot about it.

Revision 1200

R3000air: maintenance merge against trunk, plus fixes to get the merged changes

compiling correctly.

Revision 1201

Work on pcsx2's Makefiles a bit. Move CDVD*.* and CdRom.* to a separate

subdirectory, to make things a bit less cluttered.

arcum42

If the new code at the top of the Makefiles seems a bit repetitive, it is. I'm looking for a way to move it to an external file, but autotools are not exactly an area I'm that great at.

ntcong.it

Hey hey, you broke Windows build :P, I have to resolve the include myself to get it compile on Windows :P

arcum42

Suppose I should take care of that, then. I'd rather hoped what I did to pcsx2_2008.vcproj was enough...

ntcong.it

That's because /CDVD/ folder is not in the include path

arcum42

Should be up shortly.

Revision 1202

Let's try that again...

wishstu...

compiles again, good work

arcum42

np

Revision 1203

microVU:

- Cached Program search is faster/smarter thanks to an idea Jake had to search

recently used blocks first.

- Fixed a problem with block searching.

- Minor changes.

Revision 1204

GT menus look much better now (GT4 at least) - Bugfix from r1197

Note to users: Does this fix ToA or Persona?

Zeydl...

For me it does not fix p3FES.

joaolvas...

GT4 menus sttil equal r1197.

ramapcsx2

Nope, sorry.

Persona3 and 4, Tales of the Abyss, Suikoden5 still don't boot or run anything after loading a savestate.

Didn't test more :p

refraction

umm, dont use savestates for testing please..

ramapcsx2

Persona3 and 4, Tales of the Abyss, Suikoden5 still don't boot.

Better? xD

ramapcsx2

No, seriously. We need that new unified dma controller to get any further now.

Proper priorities and all :p

refraction

this is why i hate path3

Revision 1205

Linux: Added a console log regarding page protection, based on a hunch I have

for what's causing Issue 220 . [need a linux person to check it and see if the

console logs the new error or not]

bWo...

It wont compile for me debian lenny again

gcc -DPACKAGE_NAME=\"pcsx2\" -DPACKAGE_TARNAME=\"pcsx2\" -DPACKAGE_VERSION=\"0.9.6\" -DPACKAGE_STRING=\"pcsx2\ 0.9.6\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"pcsx2\" -DVERSION=\"0.9.6\" -DSVN_REV=\"Revision:\ 1205\" -DNDEBUG=1 -DPCSX2_DEVBUILD=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_NLS=1 -I. -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I.. -I../CDVD -I../../common/include -I../../3rdparty -pipe -msse -msse2 -O2 -Wno-format -Wno-unused-parameter -Wno-unused-value -Wunused-variable -fno-guess-branch-probability -fno-dse -fno-tree-dse -fpermissive -Xlinker -zmuldefs -m32 -MT LnxSysExec.o -MD -MP -MF .deps/LnxSysExec.Tpo -c -o LnxSysExec.o LnxSysExec.cpp

LnxSysExec.cpp: In function 'void HostSys::MemProtect(void*, size_t, PageProtectionMode, bool)':

LnxSysExec.cpp:396: error: 'mpagemask' was not declared in this scope

make[1]: *** [LnxSysExec.o] Error 1

Jake.Stine

Gah, I tyop'd. Will fix momentarily. -_-

arcum42

Checking, this seems to be what fixed Star Ocean, Jake...

arcum42

And every other Linux issue known to man, apparently.

Revision 1206

Linux: Typo fix from prev commit. >_<

bWo...

Debian lenny here. Games was Twisted Metal Black and Twisted Metal Head On error is same.

It a bit sux coz i cant attach all log coz it is quite big and messy

http://www.usaupload.net/d/ppw7bwe2h8f

sry for stupid solution of placing log :D adblock+ rulz

I dont know maybe it is mine system specific error i still compile it in lenny schroot coz i m too lazy to manualy add needed librarys to debian emul folder but i will...

arcum42

And for reference, while I haven't been having issues running games, I am acually getting the "*PCSX2/Linux Warning* Inappropriate use of page protection detected. baseaddr not page aligned: 0x16458328" (or whatever address) errors spammed all over the place.

Don't own either Twisted Metal Black or Twisted Metal Head, though.

arcum42

Also, you can put code along this line in:

Console::WriteLn("The alignment of VU0 is %d.", params __alignof__(VU0));

if you want to get a variables alignment. Not sure if there were any particular ones you were suspicious of...

arcum42

http://www.delorie.com/gnu/docs/gcc/gcc_61.html

Jake.Stine

I ended up forgetting a conditional check on the log anyway so it was spamming slightly more than it should.. but I checked the logs and everything seems fine. So the problem must be elsewhere. (tho could still be related to mprotect stuff)

arcum42

Yeah, I was kind of noticing that. Most of the spam in the log is from mmap_MarkCountedRamPage.

Out of curiousity, I tested the alignment of anything calling MemProtect. The alignment of m_IndirectDispatchers is 4096, which I believe is what it should be, and just about anything else wasn't supposed to be aligned, and was 4...

Jake.Stine

Yeah the only thing I was concerned for was the IndirectDispatchers in vtlb. So for now I'm still not sure what's causing problems for other folks in Linux.

And if we can't reproduce the crashes/freezes it's going to make it that much harder to track.

arcum42

That's the trouble. Everything seems like it's working for me. Within the normal bounds, anyways: Star Ocean obviously doesn't work (and it's a pcsx2 issue, not a GS issue.), and theres a bug I know about affecting Yugioh:Duelist of the Roses on Linux in the iVif code.

But, as I said in r1137, everything seems to work fine here.

I suppose things to know would be whether the issues occur when compiled in Debug mode, version of gcc, and possibly even the version of the kernel. Some of that we can guess based on it being Debian Lenny...

Jake.Stine

Oh, from what I've read by the way, it's supposedly a very bad idea to run stdio-related functions from the context of the exception handler under Linux. I just noticed there's a Console::WriteLn in there, and from what I read it seems like it *could* be a source of irregular kernel-dependent behavior.

Jake.Stine

(of course this revision itself dumps a potential crapload of logs from the exception handler itself, but it can be removed also -- it's served it's purpose)

arcum42

We could. Of course, an awful lot of crashes in Linux are easily picked up on when that starts spamming the same address over and over again...

Jake.Stine

Does that still happen? If so then that's pointing to a general failure still of the vtlb memory protection scheme under linux, and is likely related to this problem as well.

Jake.Stine

That is: even if you don't get that spam in these particular cases, to be getting it at all means the memory protection is *not* working as it should, and if it's not working it means games that rely on Self-modifying code (SMC), like Star Ocean 3, aren't going to work. Hmm. It doesn't. Yeah. Seems like we're on to something here.

Does booting Run::Execute (via bios) work in linux at all, or generally fail?

arcum42

Occassionally. Usually when I've mucked something up in either the pcsx2 code or the plugin code. For example, if I disable all the __fastcalls, or set all the packed structs to have _aligned(packed,ms_compat) insted of _aligned(packed).

(And yes, I've done both out of curiousity...)

arcum42

Run::Execute works.

arcum42

Now that's freaky. Just started up Star Ocean, and it didn't crash. I've got a totally blank screen, but I could hear the opening dialog going, which is after it normally crashes. Wow.

Jake.Stine

Ok then the signals are working as they should. That's good news. I'm still not sure what could be causing problems for other users though. I'll commit a cleanup for vtlb soon, tho not sure if it'll help anything.

arcum42

Not sure. I'll take back out the MemProtect message, and implement something to assert if an offset is repeated too many times in a row in the exception handler, and make it so that messages only show there if it's about to assert...

Zeydl...

List of Linux fixed from this release:

KH2 no longer crush when enter astroid field (this is made this game playable)

SO3 is no longer crush after difictulty select ( issue51 )

VP2 is no longer freeze ( issue 210 ), map is shawn, no longer crush on combat

Radiata Stories is no longer crush on battle screen

Okami is now start properly

MGS3 FMV is now started without crush.

It seems that linux issues was rooted from one place.

arcum42

A lot of them clearly were. Still curious about the root cause of it.

Still leaves the Yugioh:Duelist of the Roses issue, but if it comes down to it, I can fix that by re-enabling some old Linux-only code in iVif.cpp. I just prefer to have as little of that as possible...

airmake...

Hmm ... I still get the segfault ;\ With this rev. and the latest rev. Same behavior as since the 1137 rev (However, this time around, I saw alot of red colored error messages before the segfault). If it's working for everyone else, it might be because I use a chroot to compile the 32bit version (although I don't know why that should have anything to say) I have latest kernel 2.6.29.3, vanilla, and GCC 4.4.0 if someone's interested.

Revision 1207

Linux: Take back out the logging message from 1204-1205, since Jake seems to be

done with it. Remove the messages printed in Exception handing, and set up a

test to abort if it's endlessly looping on one offset.

arcum42

The test needs a bit of work; it doesn't appear to be properly segfaulting afterwards.

Revision 1208

Did some general cleanups to vtlb's memory protection and recompiled block

integrity checking systems.

arcum42

Looks good.

As a general note, the log statement is still commented out in LncSysExec. Since you added the conditional statement, tot sure if you meant to re-enable it.

Also, if uncommented, baseaddr needs to be cast to uptr, or it won't compile. After doing that, I haven't seen that log message come up yet, though...

Zeydl...

Hey! You fix SO3 crush!

arcum42

It was working in 1206, as well. I'm not sure which revision fixed it. I'll have to do some testing...

jfre1...

And its crash not crush. Crush means to press something into a smaller version.

Jake.Stine

Arcum: I think I fixed it when I changed the linux mprotect code to apply pagemask to both the address *and* size (was just size originally). Who knows, maybe that solves other problems too?

arcum42

No less then 3 issues in the issues tab, evidently.

Revision 1209

microVU:

- Added partial program searching support (helps to recompile less in games that

send a lot of small programs like Tekken 5)

- Optimized logical min/max code some more (knocked off 2 instructions)

- Fixed some cases where 'last_used' should have been set.

cottonvibes

so basically the parts in tekken 5 which slowed down a lot with mVU should be fixed.

tekken 5 went from using 32+ programs to 15 programs.

Revision 1210

Linux: Fix the exeption check up a bit, and mess with the configure.ac file. It

should now be possible to compile with versions of gcc lower then 4.3, though I

haven't tested that.

Revision 1211

microVU:

- Crashes when "microVU Error: Program went over its cache limit" message occurs

should be fixed.

- Miscellaneous code changes and cleanups.

Revision 1212

Half revert for earlier commit, didnt really make any difference to GT games

anyway, just hoped itd effect path3 masking :P

Btw, if it doesnt work, Blame Krakatos, he said it does!

kraka...

Hey I protest :P I only said that the game I tried now work XD

Anyway, persona, tales of the abyss, suikoden now all boot once again

bin.gang

Confirm that Persona 3 & 4, Tales of the Abyss, Suikoden V now work again! Great work! :]

refraction

This wasnt fixing GT4 it was fixing the games i broke. And yes some of the letters are still screwed, but the main menu is readable now and some of the sub menus. Generally the unimportant text isnt readable.

joaolvas...

And you can fix it? If you could please.....

Thanks Refraction.

refraction

im trying... lol

Revision 1213

R3000air: Implemented fundamental block caching and invalidation [still not

actually doing any recompiling] -- next up is the rec itself. :)

refraction

if( blowme == m_xBlockMap.Map.end() )

your variable names are getting as good as mine :p one in my latest path3 test code is "bool stallvifplz" :P

Jake.Stine

eheh I *hate* working with the STL's idea of clever API syntax. Iterators and std::pair can blow me, and thus I named the iterator accordingly :p

jamal.p

What is meant with the rec itself? will it give more speed or better compatibility? or both :p

kaboo...

why not shoot for "work" XD

rewrites do not grow on trees or appear magically overnight

ntcong.it

>> What is meant with the rec itself? will it give more speed or better compatibility? or both :p

It could give speed or compatbility, or It could even no, no one know yet :P

Revision 1214

Some work on variable type consistancy, and getting rid of 64 bit processor

checks.

Revision 1215

microVU:

- Fixed a bug with P-reg's instances; this fixes problems/SPS in a lot of games

such as (FFXII, NaN3, Digimon Rumble Arena 2, etc...)

Note: All the games mentioned still have other problems (ffxii for example has

missing geometry on characters, but looks a lot better than before :p).

eliotfur

Cheers!!! (I know, it's morning here right now)

I'll post my report on games I have later...

Revision 1216

microVU:

- Raised the run-cycles amount. This fixes FFXII's missing geometry (the game

appears perfect now :p)

- mVU prints a message to console now if games are exiting early due to infinite

loops (I'm interested in games that do this, so post any game you find that does

this. Dark Cloud does this for example...)

- Added some debug stuff to iVU1micro.cpp.

cottonvibes

i just tried KHII and it seems to work perfect now as well.

a lot of other games are probably fixed too :D

beenn197...

FFXII's perfect now?good work man,how's the speed by the way?if the speed is equal of faster than zero's,I will begin playing FFXII using microVU

Autor...

BTW, microVU DaZ is broken once again

Autor...

And what is more strange that games that have missing geometry or sps with Vu DaZ on now are broken even when VuDaz is off

cottonvibes

be:

in a scene in ffxii:

mVU normal - 40fps

mVU speedHacks - 46fps

zerorecs - 46fps

not sure if its worth it to play with mVU yet.

Autor:

how do you know? what game are you testing, and whats the problem?

cottonvibes

"And what is more strange that games that have missing geometry or sps with Vu DaZ on now are broken even when VuDaz is off"

that probably means its not related to DaZ

xat...

ToA - microVU Warning: Exiting Execution Early (Possible Infinite Loop) ad infinitum

kaboo...

Tales of Symphonia shows the infi loop too

eliotfur

Good one... Infinite loops are bad anyway... Hmmm... Or is it normal for PS2 game to have thouse?..

shagkon

GoW2 has Infinite loops

shagkon

Jak3 and Tekken 5 too

Speaking about other red messages:

MGS3, Jak2 and Ratchet&Clank Size Matters - microVU1: Ivalid startPC

arcum42

Getting an error in Linux about a function that shouldn't be inlined (due to being recursive). If I change microVUt(void) mVUreset() to microVUx(void) mVUreset(), looks like that takes care of it...

arcum42

Baroque does the infinite loops on startup. (On Linux)

arcum42

Dragon Quest 8 has the loops as well, right during the opening sequence with the mouse. (which was animating perfectly prior to that.)

crushtes...

Persona 3 and 4 have the infinite loops too. (and they are still spikey as hell)

Revision 1217

R3000air: Implemented constant propagation, added sign extension tracking, some

logging, and some ggeneral improvements to the block manager / validator.

Revision 1218

Cleaned up the dummy MTGS gif transfer function a bit, and let the F5-F7 keys to

be passed in GSkeyEvent (allows me to remove windows specific keyboard handling

from the gs).

arcum42

Thanks! I had looked at the GSdx code, but it was looking like it was going to be quite a job detaching it from GSdx for GSnull. I'll import this when I get a chance.

I'm getting tempted to update ZeroGS's giftransfer code...

gabest11

One day I had a weird dream of moving tag decoding into pcsx2 and just transferring regs, packed regs, image data and when tag.pre is set an extra prim call :)

arcum42

Yeah, that'd be nice. That'd be similar to what gigahertz is doing with dma. We could probably pull it off, too, in a branch.

There are only 3 graphics plugins around, after all, and I'm pretty sure that Zeydlitz could copy whatever changes I had to make to ZeroGS without a problem in ZZogl...

gabest11

ah, forgot about f12, capturing is broken now :P

1 line-by-line comment

/trunk/pcsx2/MTGS.cpp  

r1218  

line 392:

392: // along the way (often means curreg was in a bad state or something)

no, this actually means data wraps around in the buffer

Jake.Stine

>> One day I had a weird dream of moving tag decoding into pcsx2 and just transferring regs, packed regs, image data and when tag.pre is set an extra prim call :)

It's on my todo list since some months ago, actually. I could get rid of a lot of redundant memory movement, along with the fact that really there should just be one giftag processor, and it should be in pcsx2. ;)

.. but everytime I look at changing/fixing plugin APIs, I get frightened and run away. sorry >_<

arcum42

Yeah, that's why I was thinking we could work on it in a branch.

And I'll admit, the plugin apis do frighten me a little. Changing a parameter on one of the callbacks from int to s32 is enough to break the plugin, for example. And you should see what happened when I tried to move the EXPORT_C_ definition into pcsx2... :(

Revision 1219

GSdx: now I think only the window classes of mfc are left to be replaced (main

window, config dialog), trying to get familiar with wx...

genci16

I have problem with vsync activated in FF XII, the picture when the screen has a lot of characters moves by lagging, when i deactivate v-sync it is smooth. This didn't happen when i had build 1156. GPU is Nvidia GTS 250

gabest11

Please only comment on revisions that really caused the problem, this one has nothing to do with it.

Revision 1220

microVU:

- Fixed the bugs with the logical min/max code (DaZ should work fine again)

- Optimized some lower instructions a bit.

arcum42

While you're around, any issues with my changing microVUt(void) mVUreset() to microVUx(void) mVUreset(), to appease Linux? Gcc says I'm a bad person for requesting code be inlined that is recursive...

cottonvibes

nah, go ahead ;p

arcum42

Cool. Been loading up the beginnings of various games in microVU to see how they act. Anything by Atlas generally tends to work well (which seems to be 90% of my games...), though Atelier Iris slows to 2 fps for some animations. Baroque & DQ8 gave infinite loops, as a mentioned, and Star Ocean immediately crashed.

The distortion on Ape Escape 3's dump is entertaining, though since I haven't checked it in a while, I'll have to see if that's microvu or not. Overall, runs well, though...

Autor...

Now's fixed, thanks cotton, btw SoTC now also looks like on ZeroRecs-some little texture bug like missing geometry

eliotfur

Silent Hill 2: Director's Cut still have some SPS, similar to that of FFXII had, diagonal spikes from top-left to bottom-right... Much less though...

Crash: Mind Over Mutant has a lot of "Infinite Loop warnings" at load-time...

Devil May Cry has slight SPS issues and a bit slow...

Devil May Cry 3 looks perfect...

Okami is funny: it has missing geometry right near protagonist in default mode, no geometry at all in Full clamping mode, a bit more geometry if I set DaZ off... That's it...

eliotfur

Compiled r1220 with minmax speedhack... Full clamping mode still have more geometry when DaZ is set off...

BTW, is there any use of clamping modes with microVU?.. Or is it related to zerorec only?..

eliotfur

You're welcome!.. I'm glad you found yourself... It'd be a tragedy if you lose yourself somewhere... ...in the source of pcsx2... :-)

Good luck everyone... Looking forward to test new revision of mVUrec, cottonvibes...

cottonvibes

eliotfur:

yes clamping modes are in effect with mVU.

none is the fastest mode.

if you want to do accurate comparisons between zerorecs and microVU, they both should be set to 'none' clamping mode.

the reason is that zerorecs doesn't clamp stuff 20%~25% of the time (when it should). So microVU is doing more clamping which would bias the benchmarks.

Revision 1221

Linux/microVU: Uninline a function that isn't inlinable according to gcc, so

microVU is compilable on Linux.

G.Z.2...

ICC error

R5900.obj : error LNK2019: Unable to resolve external symbols "void __cdecl COP0_UpdatePCCR(void)" ([email protected]@YAXXZ)，The symbols in the function "bool __cdecl _cpuBranchTest_Shared(void)" ([email protected]@YA_NXZ) Was quoted

iCOP0.obj : error LNK2001: Unable to resolve external symbols "void __cdecl COP0_UpdatePCCR(void)" ([email protected]@YAXXZ)

HwWrite.obj : error LNK2019: Unable to resolve external symbols "void __cdecl dmaIPU1(void)" ([email protected]@YAXXZ)，The symbols in the function "void __cdecl hwWrite16(unsigned int,unsigned short)" ([email protected]@[email protected]) Was quoted

HwWrite.obj : error LNK2019: Unable to resolve external symbols "void __cdecl dmaIPU0(void)" ([email protected]@YAXXZ)，The symbols in the function "void __cdecl hwWrite16(unsigned int,unsigned short)" ([email protected]@[email protected]) Was quoted

airmake...

Holy crap :O This revision finally worked for me! (Although with gcc 4.3.3). Will test with gcc 4.4.0

airmake...

And it doesn't work for 4.4.0. I think we have a gcc regression here ;\\

Revision 1222

Linux: Fear and Loathing in GCC 4.4.0...

xat...

#ifndef THE_UNBEARABLE_LIGHTNESS_OF_BEING_GCC_4_4_0

Such creativity!

arcum42

Thanks. That def is mainly there for the future, though.

Gcc 4.4.0 lets me change optimization settings in the code, so if I can ever figure out which code is causing the problems, that code will let specifically say not to optimize those functions or that file, and get rid of all the ugly flags I just put in place for compiling in gcc 4.4.0.

I could have done it with a lot less flags, but I wanted to have it be about as optimized as on earlier versions of gcc...

airmake...

Awesome work arcum :) It built and ran just fine when built with GCC 4.4.0 here now.

Jake.Stine

I'd love to assume this is a GCC bug somehow, but I can't help but figure it's actually some "feature" and that pcsx2 is actually breaking some obscure C++ compliance assumption some where that no compiler, until now, has bothered to optimize for.

airmake...

Hmm. This post on the forum got me puzzled though:

http://forums.pcsx2.net/thread-4108-page-61.html

"ZZOgl Rev. 156 for linux

This time compiled in Ubuntu 9.10alpha1 with GCC 4.4,so let's see if there's any speed improvement.

EDIT: Added rev 156 compiled with gcc 4.3

pcsx2 rev 1213 + zzogl rev 156 compiled with gcc4.3 is more o less 3-6 fps slower tan the ones compiled with gcc 4.4 ^_^"

If he means that PCSX was compiled with gcc 4.4.0 (in Ubuntu), and it apparently worked without any issues, it may mean that GCC maybe was patched on the Ubuntu version (I bet Gentoo's GCC package is pretty vanilla, as Arch's package certainly is), and that it for some reason fixed a regression issue. Hopefully, it's a gcc bug :p

veaac.fd...

I have encountered several GCC bugs so far. If you use templates the probability rises enormously. So I would not be surprised if PCSX2 ran into some.

airmake...

"Yes both PCSX2 and ZZOgl were compiled with gcc4.4. And yes they work, cos yesterday i finished La Pucelle using this revision

This evening i'll see if i can compile a newer one."

It looks like it's a GCC bug after all ;S Who would patch something that already works.

arcum42

What tics me off, really, is there is a list of what optimization flags are turned on with -O1 and -O2 in the gcc 4.4.0 manual. And all of them are supposed to be reversable.

And I knew -O1 causes it to crash. So I Turned on -O1, and then turned off all the flags for -O1's compilation, with a plan of turning them on one by one, till it crashed.

And it crashed with all of them turned off. So it's a gcc issue, as far as I'm concerned. Besides, anyone that's used gcc should know better then to trust a x.x.0 release...

arcum42

Oh, and Jake, if airmaker90's able to compile with this release, I think you can close Issue 220 . I'll still work on a more elegant solution, but this'll work for the moment.

And you should be able to close Issue 122 and Issue 210 as well, since they were fixed by r1206, according to Zeydlitz.

Revision 1223

R3000air: Added second-pass IL register mapping, and re-wrote the DIV and

LoadStoreOps recompiled instructions to match. See iR3000airMemory.cpp for

remarkably clever (*cough* evil! */cough*) use of templates!

Autor...

Oh.. god it's totally rewrited, cant wait ot see it in action

arcum42

Remarkably clever use of templates? Oh dear...

Hoot.Haw...

I'm not really familiar with the code, but in iR3000airMemory, why don't you just do:

template <typename T>

static uint GetOperandIndex()

{

return sizeof(T)>>1;

}

G.Z.2...

Intel C++ Compiler error

R5900.obj : error LNK2019: Unable to resolve external symbols "void __cdecl COP0_UpdatePCCR(void)" ([email protected]@YAXXZ)，The symbols in the function "bool __cdecl _cpuBranchTest_Shared(void)" ([email protected]@YA_NXZ) Was quoted

iCOP0.obj : error LNK2001: Unable to resolve external symbols "void __cdecl COP0_UpdatePCCR(void)" ([email protected]@YAXXZ)

HwWrite.obj : error LNK2019: Unable to resolve external symbols "void __cdecl dmaIPU1(void)" ([email protected]@YAXXZ)，The symbols in the function "void __cdecl hwWrite16(unsigned int,unsigned short)" ([email protected]@[email protected]) Was quoted

HwWrite.obj : error LNK2019: Unable to resolve external symbols "void __cdecl dmaIPU0(void)" ([email protected]@YAXXZ)，The symbols in the function "void __cdecl hwWrite16(unsigned int,unsigned short)" ([email protected]@[email protected]) Was quoted

Jake.Stine

static uint GetOperandIndex()

{

return sizeof(T)>>1;

}

... only works for 8-32 bits. I'm used to coding with both EE and IOP in mind, and EE has 64 and 218 bit types, which can't be shortcutted as such. So out of habit I just never bother to use the shortcut anymore.

Dhalai.L...

When it will be merged in the main pcsx2 ?? I can't wait to see the new IOP.

Revision 1224

Added COMI.SS/COMI.SD to the emitter (and moved UCOMI from moremovs to

comparisons, where it belongs -- oops)

Revision 1225

microVU:

- Fixed a Q/P instance bug. This fixed some graphical corruption in Haunting

Ground, might fix some other games too.

- Minor Changes...

RebelliousX

+1 just for Haunting Ground.

rbuldo

Wild Arms 3 and Okami fixed

chane2k1

I've been looking through the recent revision logs and it looks like microVU is being used now. Is it enabled in the release build or only the dev build? Sorry if it has been asked before, haven't been on in a while.

ntcong.it

You have to manualy enable it in the Ps2config.h and compile.

ItsAGraf...

To chane2k1:

microVU isn't enabled by default. But it's easy to enable it (check some previous microVU-related commits).

bin.gang

Huh? Isn't it that mVU has been enabled by default in r1181?

ntcong.it

That's Jake's mistake when he made some changes in r1180

bin.gang

Oh im sr, my mistake, it's been disabled by default in r1181 ;p

Revision 1226

GSdx: optimized local-local transfer a bit, it boosts fps in games like ffxii or

ico, which do a lot of moves in local memory.

refraction

cool, i wonder if xenosaga would benefit from this, as the games you mentnioned (well ICO at least) tend to use 99% cpu on the GS alot and we all know Xenosaga is GS limited

gabest11

hm, can't remember if xeno games had this particular problem, frequent texture switching and region repeat addressing are more likely to slow hw mode.

ramapcsx2

Got a few games with considerable speedup. One even 100%.

So great job on this! :)

There's still the issue that GSdx got generally slower in that earlier dependency cleanup.

Jake suggested that could be bad c++ constructors.

Doing PGO on the dll fixes that slowness nicely though.

gabest11

ramapcsx2: try the latest revision, could be better now.

ramapcsx2

On it :)

ramapcsx2

Yep, that was exactly the problem. All back to normal speeds, plus the latest speedups :)

kimoki...

Thank you gabest.

I was wondering around and I found this GSDX 1076m, its a mod I assume that makes God of War 1 & 2 looks great actually, cannot this be merged into latest GSDX releases? maybe as an option at the config window?

Autor...

kimokimo1: This was my mod, actully it makes other games looks worse, so NO INTRODUCE IT HERE ANYMORE!

kimoki...

Well, as an option it will be good... like special game fixes..

it makes GOW really good.

jimjr...

how do you use these files? I am trying to fix GoW and new to all this

itoxi...

please help me

where is the plugin

Revision 1227

mVU: minor fix for branches, improving compat a wee bit.. like lots :p

ramapcsx2

We were working on this bug for days... Finally fixxor'd :p

LM1...

SSX 3 collision detection working now :)

Revision 1228

GSdx: found a compiler def for stl that removes a lot of iterator checks in the

release build.

gabest11

forgive me, I rarely use stl :P

p03...

Sorry, but my english is so bad (i'm from Belorusia). I read, that there is a microVU. What is this, & how can i turn it on on winXp? TNX!

ramapcsx2

Gabest:

Yep, that was exactly the problem. All back to normal speeds, plus the latest speedups :)

p03uta:

It is not yet ready for broader testing, or even usage.

Its better if you wait a bit still, we'll soon have an option for this. (propably)

p03...

I'll be hope on this! My PC config (athlon xp64 3200, video radeon 8600,ram 756), & for me important, every frame!!!!! But i see, that project is better and better for every day!

Saif...

The post-processing effect has been removed for some CRC (0x053D2239)

There is no option to turn it on/off ?!

gabest11

It's not removed, just skipped, because it cannot be emulated currently, so there is nothing to turn on.

Saif...

Thanks for explanation ...

ntcong.it

Nice fix, _SECURE_SCL is known to be slow :)

Revision 1229

microVU: minor changes

steven_copson

Ok as i havent done any programming since windows 3.1 first appeared in 1821(ok maybe not that far back but it was about 15-20 years ago since i last did any programming at college) can someone please explain to me where ps2config.h is so i can enable microVU, i search the whole source and couldnt find it

ntcong.it

1821 O.o, I though that we didn't have C at that time...

If you talked about machine language, you must be a pro, and there's no chance that you can't find the ps2config.h =.=!

refraction

trunk\common\include

that isnt a programming issue, thats a navigation issue :p

steven_copson

Ok i found it about 1 minute after i posted the question and to quote my grandmother 'i'm blind as a bat and twice as stupid' ;p

steven_copson

I wouldnt say pro but the Eniac was a sod to program and all those Vacuum tubes did my head in constantly blowing everytime you tried to play tomb raider underworld on it. ;p

steven_copson

Ok sorry for the 3rd post but i got to say since enabling the microVU Shinobi's missing backgrounds/textures and spikes have completely vanished and seems to play great, all i can say is thank you for all your hard work and the greatest emulator ever.

cottonvibes

steven: that's great news; when i was working on Super VU i would constantly test Shinobi to see if anything i did would fix the SPS (spikey polygon syndrome). I'm very glad to hear microVU recs fixed it!

going to test it later today :)

cottonvibes

steven: do you mind telling me what options you have set to fix shinobi?

i've tried a few different configurations, and i still get the SPS with microVU :(

cottonvibes

ok nvm i got it working :D

seems the major SPS was caused by older versions of GSdx; using the latest version fixed the major SPS.

using Super VU there was still some minor graphical problems, and microVU fixes that :D

Nice that this game is finally looking good :D

steven_copson

Sorry didnt answer mate its now 4.46am here in the uk and i had fallen asleep infront of the pc(sad i know)...lol, btw even though i have the latest version of directx(march09) i cant get the latest Gsdx plugin working in dx10 mode all i get is a 'Failed to init plugin' error but if i switch it to dx9 it works fine.

cottonvibes

you need windows vista for dx10 and a dx10 compliant graphics card :p

if you have more questions try our forums:

http://forums.pcsx2.net/

steven_copson

yeh i've got that, windows vista ultimate x64, 2x8800 gts 320mb, 4 gigs memory, 2 tb harddrive, amd x2 6000+ and 7.1 sound, it used to work but now refuses and i havent changed anything apart from updating dx to latest, i even tried re-installing my graphic drivers and also directx but no luck, stupid pc. ah well, i'll try the forums as this is for developement not questions, thanks mate.

Revision 1230

microVU:

- Fixed a problem that was causing microPrograms to be cached when they

shouldn't be (introduced in r1209). This also fixes broken logging in some

games, and is a small-speedup.

- Minor Changes

blackclaw

Nice work.

Tales of Legendia still goes infinite loop and exceeds cache limits.

microVU Error: Program went over its cache limit. Size = 0x100536

microVU1: Cached MicroPrograms = 1

microVU1: FSSET Optimization

microVU Warning: Block List Overflow

microVU Warning: Exiting Execution Early (Possible Infinite Loop)

arcum42

Not sure which commit it was(after r1221, though), but Kingdom Hearts 1 looks a lot better then it did in microVU. Sora no longer has eyes in the back of his head, and the graphics mostly look the way they should in the island world, with the exception of occassional large polygons in the sky and on the ground.

And the ones on the ground happen occassionally without microVU as well...

arcum42

Oh, Baroque and no longer seems to do the infinite loops (and looks pretty good), though Dark Cloud does.

Autor...

MGS3 is almost perfect, still a little sps and missing Geometry but much much better, and GoW1&2 is broken with SPS again

Autor...

futurama missing geomerty are is also fixed

Autor...

And oh god...VU DaZ is broken again

cottonvibes

Autor: when you report that DaZ is broken, at least tell us the game you're testing with; or else how can we confirm and fix the problem?

and we havn't messed with the logical min/max code (the code that fixes DaZ) since i fixed a bug with it a while ago, i think it should be fine.

Autor...

Oh sorry, really it seems i just compiled with min/max speedhack ON, the game is Naruto Shippuuden Narutimate Accel 2, it always has the same bug when VU DaZ is broken, also it can be confirmed by Tekken5 VU DaZ bug will give you just black scren with sound, i've just compiled version with no hacks, it seems DaZ is fine, sorry for bothering

Autor...

Okami now's also almost perfect and even shows Amaterasu's copybook sometimes

http://img34.imageshack.us/my.php?image=16516826.jpg

and sometimes shows this with missing gepmetry

Revision 1231

R3000air: Much work on the optimization mess for the recompiler. Think I'm

finally getting something I'm happy with.

* Added placebos for all recompiled R3000A instructions.

* made significant changes to the emitter, adding an xDirectOrIndirect type, and

several cleanups.

mahmoudk...

man plz i wanna know what does r300air do?

yan.eml...

It is recompiler for R3000 (PSX CPU, used as I/O Processor in PS2).

genci16

Is it compiled automatically with the project, or there is a switch for it somewhere?

ramapcsx2

It's not finished, so don't expect anything when compiling this.

andreabo...

refresh my memories.... scope of r3000air is to bring the I/O processor ( R3000 is for i/o if i remember ) emulation the new features added to the other part of pcsx2 , multi-threading , better recompiling and...?

Revision 1232

R3000air: quick merge with trunk and some minor code cleanups [prepping for a

weekend road trip]

Revision 1233

Minor variable type changes.

arcum42

Nothing major; just trying to make sure we don't run into any more "unsigned long" issues, and I don't really like having changes hanging around in my local copy when I'm working on other sections of pcsx2...

Jake.Stine

we need to remove decode_Xa already. IT's not used and never will be. It's a throw back to the old PSX/integrated SPU days or something.

arcum42

Agreed on that. Only thing used on it was one of the structs in the cdrom code, and that struct is never called; the only reason to keep it would be for savestate compatability. (And we could easily move that struct into a different header.)

I knew it wouldn't be used when I updated that file, but was going down a list and didn't see a reason to skip it... :)

Lunyov...

Crash Mind Over Mutant goes but with loss of structures

Lunyov...

Where it is possible error or bugs to spread???

Revision 1234

GSnull: Update the GifTransfer code. Start to add keyboard code.

arcum42

Note: I did not say *working keyboard code*. I've just basically sketched it out. Getting it to actually register the function keys will be later.

G.Z.2...

Compiler error

deci2_dbgp.cpp(363) error: argument of type "volatile s32={int} *" is incompatible with parameter of type "volatile long *"

deci2_dbgp.cpp(376) error: argument of type "volatile s32={int} *" is incompatible with parameter of type "volatile long *"

RDebugger.cpp(31) error: declaration is incompatible with "volatile s32={int} runStatus" (declared at line 58 of "..\../rdebug/deci2.h")

arcum42

I'll take care of it...

Revision 1235

Get rid of Decode_XA. A few minor changes.

arcum42

abiguous? Oh well.

wisestud...

Gsnull's Windows version build is broken,plz check it.

arcum42

As of r1237 it should work in Windows (with LilyPad, even.). Of course, I'll have to check back on the Linux version.. .

Revision 1236

GSdx: converted a few template classes to pointers and virtual functions, the

dll got more than 100k smaller, since there were many changes, backup your old

version first :P

Xeli...

Despite the larger size, isn't using templates generally faster?

ntcong.it

afaik, using template only slow down ( a little ) the compiler, and it doesn't slow down your program

gabest11

a few things aren't inlined now, like asking the dimensions of a texture, but nothing critical, only the LHC could measure the difference.

steven_copson

Well the build for windows is working again now no more errors when trying to compile but still getting that 'failed to init plugin' error when trying the dx10 option despite the fact that i've now re-installed vista completely with the latest drivers and everything :(

animus...

steven: "failed to init plugin' error when trying the dx10 option"

I had the same message when I ran plugin first time. But after that it was running with no probs.

ramapcsx2

Uhm, this doesn't slow anything down.

I'm seeing huge speedups rather. DQ8 from 108 to 135fps for example.

That other very slow scene in xenosaga2 is now at 55fps. Was 35 before :p

ntcong.it

Nice :), I heard that STL is Slow Template Library :D, so remove template will help the speed :P

Jake.Stine

When working with my IOP Interpreter, I routinely got speedups by using virtual member classes, instead of clever virtual-free templates. Go figure.

Jake.Stine

To clarify, I've also had other things that are faster as templates over the virtual member alternative, so it's not like templates are bad and virtuals are good in every case. But the only way to know is to try both methods and check the results.

And I can't really tell a specific pattern. The one use of virtuals in the IOP that result in a speedup doesn't generate any extra code bloat as a template, it just gets rid of the vftable. And yet it ends up being a speed-down. Optimizing for modern cpus is sometimes nothing more than a random game of dice. :p

Xeli...

It's funny how just following this project has taught me more about programming than my university has in the past few years.

malo.sa...

do you plan to fix the fmv in ffx-2 while using hardware mode ? thanks

gabest11

point rendering is only compatible with the native resolution, it's not easy to fix

malo.sa...

for ffx-2 it seems that ever the native solution has problem in hardware mode

gabest11

what kind of?

malo.sa...

for the intro movie for exemple ; first the movie is not full screen , there is a large black line in the bottom , in the past it was green , now it is like a snapshot of the moving Bios playstation logo. Then the movie is flickering a lot except if choosing blend xff interlacing mode. That's all not a big problem. The real problem is that on the the drawn part of the movie , there is a semi-transparent large line, excactly on the place where the subtitles appears. Furthermore the subtitles are never refresh and overlayed one on the other.

malo.sa...

intro printscreen : http://imagebin.ca/view/lRRZYm.html

subs printscreen : http://imagebin.ca/view/zm7hyf3J.html

In software mode or with zerogs it is perfect except for the speed impact

gabest11

hm, even ffxii movies were broken by this revision

trigunflame

filed crash report for this rev.

Revision 1237

GSnull: Make it work better with Windows and LilyPad.

Revision 1238

GSnull: Modularise things a bit more, so we don't have a bunch of platform-

specific code in the main code. (Note: the Linux side hasn't been tested yet.

I'll be doing that a bit later.)

ntcong.it

It would be a hard work for you to check both Linux and Windows version.

arcum42

I dualboot, so I can check both versions, it's just a pain to reboot before every commit. OTOH, not doing so is what usually causes Windows builds not to work after I commit, because I mainly develop in Linux.

There's a decent chance that this still compiles, though, because I'm fairly familiar with Linux; I just haven't run it through a compiler to check it yet.

And since not many people actually use GSnull yet, I can get away with that for now...

system.compiler

surely it useful for troubleshouting and logging ^_^

Jake.Stine

Am looking forward to this, since it'll help me test linux stuff eventually. (most of the time stuff I work on is audio and memory stuff that doesn't really need visuals anyway)

arcum42

Definitely.

It lowers the bar for testing, since you don't have to have a fully featured graphics card to use it. Means it'll be possible to have it set up in a series of virtual machines with different linux distributions without problems, if I really want to heavily test pcsx2.

And the main thing that needs to be taken care of on the Linux side right now is the fact that esc doesn't work.

After that, of course, the matter of fully implementing the gif transfers, registers, etc, comes along. But that isn't absolutely neccessary for it to be useful... :)

arcum42

Incidentally, as it turned out, this compiled without issues when I went back to Linux to test it. For the most part, I was just moving things to a separate file and wrapping them in new functions on this commit. Makes the main code cleaner, though...

ntcong.it

Arcum, I like when you always end up your comment with "though..,", lol

arcum42

Yeah, I've noticed that I overuse ellipses and the word "though". I'm actually starting to scan back and remove extra ellipses on anything I type because I type them so often.

It's a hard habit to break though... :)

arcum42

And let me correct myself; I do actually have to fix the Linux version of GSNull. Forgot that I hadn't updated svn. :(

Revision 1239

GSdx: more source cleanup and something interesting on F7

gabest11

found this today: http://en.wikipedia.org/wiki/Pixel_geometry

kaboo...

I love trying out new things XD

in this case pressing F7 once kind of rasterizes the picture

twice makes the effect fine but it looks like a darken picture function^^

no good use found yet Oo

gabest11

yea, somewhat darker because intensity is getting lost.

obviously it looks better on a high resolution display, rearranging the pixels can be done only by combining them into larger groups of red/green/blue pixels.

gabest11

... still thinking how to make it feel more tv-like

kaboo...

more tv-like... mm how bout my old arch nemesis filter

cause I think a dot matrix filter could do the job Oo

gabest11

you can hack in your own effects into convert*.fx ps_main5/6 :P

gabest11

just noticed I made the dx10 version a bit darker while experimenting with it, +0.25f vs +0.5f...

Leonhart...

Hmmmm... Pressing once F7 makes the whole screen violet:p

Leonhart...

Edit: It always becomes violet only in dx10. Tried with various settings on Star Ocean and Magna Carta. The second filter works fine with dx10

gabest11

hm, what video card?

Leonhart...

An integrated gforce 9600M GT

nefer...

Interesting, this made me realize i lost the ability to use the f5-f8 keys with gsdx some revisions ago...

nefer...

Ah seem to be related to the r1218 where something was changed to the f5-f7 keys, wonder if only I was affected by it?

gabest11

try other pad plugins

nefer...

Tried latest beta lilypad, lilipad 0.9.9 and the ssspsx pad 1.7 that comes with pcsx2 0.9.6 and all the same, it's not a biggie for the f5-f6 as they can be set in the GSDX interface when going out hitting "esc" key but i cant set the f7 :P

Revision 1240

Meaningless Commits Inc presents: Made jASSUME to be more scope-proof, and fixed

a minor signed/unsigned warning in cdvd.

gabest11

there is __debugbreak or DebugBreak for vc, inline asm is evil

Jake.Stine

Speaking of that actually, does GCC have a matching version of intrin.h these days? I'm thinking it does for some reason but I can't remember, and I'm too not-interested to look it up on google. ;)

arcum42

No, it's Microsoft-specific. xmmintrin.h and emmintrin.h, but not intrin.h.

It has the built-in atomic functions here, instead:

http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Atomic-Builtins.html

And projects like ReactOs have made compatibility headers using them:

http://www.koders.com/cpp/fidF6A8E722EF8A8D0E3BF173BC25726F66C56BB6B5.aspx

Revision 1241

microVU:

- Implemented the case where an Unconditional branch has the E-bit Set. This

solves a few games from getting stuck in infinite loops. (I still need to handle

conditional branches and jumps).

- Max/Mini Opcodes shouldn't set status/mac flags. This should be a minor

speedup.

- Minor Changes/Cleanups...

blackclaw

No more Infiloops on ToL. Just a bit sps left.

xat...

ToA still inf. looping.

Revision 1242

GSnull/PadNull: Add a null Pad plugin (Currently Linux only). Fix up GSnull on

the Linux side.

arcum42

It felt strange having only one type of plugin that didn't have a null version, so I added one.

Had to implement a little more here initially then on GSnull, because it has to pass keys back to pcsx2 for escape and the f-keys to work. But they do work.

I'll do a Windows version eventually. I just didn't feel like booting back into Windows right now.

Revision 1243

PadNull: It compiles in Windows. (It does not pass key events, such as escape,

though, so should not be used yet.)

arcum42

So much for "didn't want to boot back into Windows yet". Decided the next thing I wanted to do would be easier if I had the Windows side squared away, or on it's way.

system.compiler

how about getting a new computer with windows OS just for the project? that will speed up your work..... <just kidding>

ntcong.it

Why don't use Virtual Box to run Windows on your Linux, or just run Linux on Windows ( I think it's more easier, because gcc is more easier to install than VisualC )

arcum42

@system.compiler: Not out of the question, actually (though it wouldn't be "just for the project" if I did that), but I don't have space for another computer in my apartment.

I actually have two computers hooked up right now, one as my main computer, and one as a file server, both running Linux. The file server one doesn't have the specs to run pcsx2. My main computer does, and is triple booting Linux, Win XP, and Win 7 as a result.

And I also have an eeePc which dualboots. I tried running pcsx2 on it once, which was amusing. (This is not even mentioning the old, obsolete computers in my closet.)

@ntcong.it: I do on both counts. Last time I tried, I wasn't able to get pcsx2 running properly with either GSdx or ZeroGS, though it's been several versions of VirtualBox since I last tried with Windows. The trouble is that the generic video card in Virtualbox, KVM, and VMWare historically hasn't been good enough to run the graphics plugins.

Of course, GSnull didn't exist then. L)

Still, Visual C++ has given me trouble trying to compile from shared network drives before, so I still end up having to either copy the code from one partition to another or commit and then update svn, which I'm tending towards a lot more these days.

system.compiler

well...sometimes I angry to myself just do nothing to help and just waiting for the dev to improve the program without knowing their problems on optimizing it.

I think I only could give the support for this moment.

Just do the best

trigunflame

Arcum, setup dropbox on whichever pc's/installs. Small file changes should be nearly instant.

I use it for my *nix VM installs instead of samba/cifs, works fine for dev.

arcum42

Thanks, I'll take a look.

Revision 1244

PadNull: A bit more work on the Windows side.

Revision 1245

ZeroPad: Refactor a bunch of code. Escape now sets the key value to 'Unknown'

when configuring. Work some more on the hat code (still disabled).

arcum42

I'm not totally happy with some of the refactored code, but the huge function it came out of was worse...

Revision 1246

microVU:

- Added a new status-flag speedhack after learning how evil sVU is with status

flags (mVU with both flag-speedhacks ON is less evil than sVU's default setting

which does something even hackier)

- Minor Changes

nexxus86

uuhm can someone implement a VUrec selector and mVU Speedhack Checkboxes in the PCSX2 gui please?

I'm too lazy to activate it in the code everytime :S

thx!

jadjkor...

I agree with nexxus86, it would be nice to have them.

arcum42

Having to change the code to use it emphasizes that it's experimental, not totally implemented, and likely to break things. Once it can actually be turned on and off in the gui, it opens up people checking it in the latest beta, and complaining that things are broken.

That being said, it is planned eventually, eventually being when cottonvibes thinks it's ready for a wider audience. (Then, later, when it's really mature, we turn it on by default, and eventually remove the checkmark and the old code.)

And keep in mind, however difficult it is for you, it's more so for cotton. He has to remember to re-comment it *every single time he commits*... :)

Revision 1247

R3000air:

* Used some operator[] indexers to clean up iopReg.GPR references.

* Redid register mapping logic again -- only about half done. >_<

[this commit probably doesn't work, I've just changed too much stuff and need an

svn rollback spot].

Jake.Stine

To express the purpose of the R3000A rewrite:

I'm developing a new recompiler from the ground up, to serve as an eventual replacement of iCore / iCore32 stuff. For IOP concerns, the resulting code should be over twice as fast, sine the old IOP recompiler used a minimal amount of optimizations. However, that will only be a net 4-7% speedup for Pcsx2, depending on game.

The good news is this stuff can in large part also be applied to the EE. The EE's recompiler has pretty decent XMM regalloc currently, but has almost nothing in the way of x86 register optimizations. That's something we plan to fix (eventually).

joaolvas...

I can say if is good because the menus still garbed. Maby refraction fix this, when i dont no. LOL.Good work.

refraction

Farrarin: if you are still going on about GT bloody 4, i may have to kill you, right after jake has killed you.

gabest11

how about a GT4 OS?

refraction

still results in death

Revision 1248

Zeropad: Fix a glitch in the new esc code, and the hat code should not save in

the same spots as the axis code.

Revision 1249

Zeropad: All around my hat...