PCSX2 Documentation/Google Code svn repository comments archive 3500 to 3999

Yeah, I'm not sure how well all that DEVBUILD code still works either at this point.

Hmmm... for that matter, I should change ZEROGS_DEVBUILD to ZZOGL_DEVBUILD, or something similar, since this isn't exactly ZEROGS any more...

gregory....

Good for s_clut16. Now the code load xmm register with the content of a valid address instead of 0x0 !

Revision 3501

ReorderingMTGS: Change the location of the Linux version of memcpy_amd_qwc for

the moment, so it compiles.

What are the compilation errors when having it in a header file?

(though ultimately when GCC introduces global opts it won't matter where it is)

It starts telling me that memcpy_qwc_loop2, memcpy_qwc_1, and memcpy_qwc_final are defined multiple times. Regardless of any precautions I take to avoid that.

huh... well that one sounds pretty unfixable to me. :p

Yeah. Not sure why it didn't crop up initially, unless I didn't do a full clean build.

I'd hoped putting it in:

#ifndef LINUX_MEMCPY_QWC

...

#endif

#define LINUX_MEMCPY_QWC

would help, but no luck. Makes me worry about putting any assembly in headers, really...

And after all that work gregory just did with copyrights and licenses, I really didn't feel like bringing memcpyFast.cpp into the mix with that funky AMD license yet.

(And yes, I noticed the #pragma once. I was just hoping it wasn't working.)

gregory....

Did you try without the static keyword definition in the function?

Just tried it, and it has the same issues. (In fact, I usually put static on functions in headers to try to avoid multiple definition problems...)

gb2985

Isn't the #define supposed to inside the if block? If it's outside then avery time the file is called the variable will be redeclared.

Revision 3502

[wiki] : Add a new pages for amd64 linux user.

Revision 3503

ReorderingMTGS:

* Added a few assertions to detect when PATH transfers are started that violate

other pending PATH transfers.

* Removed a lot of obsolete code from vif1's DIRECT handler (Vif_Codes.cpp)

* Add alignment to Path1buffer to avoid SSE alignment faults.

JohnnyKi...

LEEEEEEEEEEEEROY JEENKINSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS :)

Note that the assertions are a bit overly aggressive at this time, since technically it's ok to slice PATH3 during IMAGE transfers. I'll be fixing that up shortly.

Revision 3504

ReorderingMTGS: Assertion fixes, some comments notes on MARK behavior.

Revision 3505

ReorderingMTGS: Comment out a few unused variables.

Just a bit of cleanup. Thought I'd escape the 110 degree heat for a bit...

Revision 3506

zzogl-pg: Working more on the new register code. Combined the KickVertex

functions.

Revision 3507

ReorderingMTGS: threading bugfixes, ringbuffer would do bad things when it got

full (GS load 80%+), or when vsyncs wrapped around the edge of the ring.

Revision 3508

zzogl-pg: Converted the TransferLocalLocal defines into inlined functions.

Revision 3509

zzogl-pg: Add some helper functions, and rework the _TransferLocalLocal

functions a bit. (Needs more testing)

I should probably change the helper functions to static arrays...

OTOH, I need to get groceries, and the temperature is down to 104. I can work on that when I get back.

pablobio...

It's really good to see work being done on zzogl-pg! I hope one day I'll be able to play God of War under linux! =)

Thank you very much!

Revision 3510

zzogl-pg: Convert the helper function into arrays. Use them in other places as

well.

Revision 3511

zzogl-pg: Cleaning up a bit after the last commit. Expand a hack to remove lines

when AA is on to cover AA at x8 & x16.

Looks like I left a log message in. I may need to remove that.

Also, I need to look more at that gsvertex code and see why the sprite is too small in the first place, because that problem doesn't only happen when AA is on.

Revision 3512

zzogl-pg: Change the messages when finding a game crc a bit.

Revision 3513

zzogl-pg: Lets try that again.

Revision 3514

zzogl-pg: Now it lists all the enabled hacks, and if they were manually or

automatically enabled.

Revision 3515

ReorderingMTGS:

* fixes flickering screen in Soul Calibur 3 (caused by VSYNC register bug)

* Optimized upload of queued Path1 transfers; such that all Path1's are

uploaded as a single MTGS packet.

Revision 3516

vifUnpack: Made V3_## Unpacks work the same as V4_32, this is how legacy did it

to, for some reason i made it copy the 3rd vector in to the fourth >.<

oops i meant V4_## not 32!

oh and i made it look a bit tidyer in there too, seemed all very squashed

Alright, we're lucky we got some forum users that help debug like this, eh?

(Kudos, kickstand ;) )

>> oh and i made it look a bit tidyer in there too, seemed all very squashed

Yes, cottonvibes dislikes having to use scrollbars.

Eh, debug? This isn't a bug by specification, the value of the fourth is indeterminate. Unless this happens to match the actual behaviour it's just a minor optimisation.

>> Eh, debug? This isn't a bug by specification, the value of the fourth is indeterminate. Unless this happens to match the actual behaviour it's just a minor optimisation.

Well how it is now, is how i originally did it in the normal unpack code, but got myself in a muddle when i was explaining the determinate indeterminate fields for V2 and V3 to cotton ;p Annoyingly thats now 3 games that rely on indeterminate data. Lemmings, And1 Streetball and now Fishermans Challenge.

Revision 3517

GSDx: fixed incorrect RGB->YUV conversion when capturing video which was

producing off colour results.

Thanks to patrickdinh for noticing this. The rest of you are all blind.

patrickd...

lol, sudonim.... I'm sure others have noticed, but probably didn't bother to mention it.

pcsx2gu...

I've mentioned it tons of times, with everyone ignoring me cause "who cares about gsdx recording, it's too broken anyway" :P

GJ patrickdinh and pseudo

Revision 3518

ReorderingMTGS: More tweaks to asm memcpy files (made code changes to Linux

side, comment changes to Win32 side).

Linux Devs: Let's get this memcpy thing finalized, if its not already. I'd like

to merge the current state of this branch into trunk as soon as possible, since

its currently looking very stable and has been, up to this point, a code cleanup

and stabilization project. (more invasive changes coming soon)

Can't wait to try it... I expect it will break my "SotC edition" GSDX fix, and I will have to make another one...

tarrag...

Thank you eliotfur for sotc edition of GDSX, I finished sotc yesterday:)

Good job Jake;)

Hate try.

Revision 3519

ReorderingMTGS: Revert changes to Vif_Codes.cpp from earlier, until other bugs

in VIF processing can be resolved. (fixes ICO bootup).

Yeh i dont think you can just remove all that :P mainly the case when its less than 1qw left in the packet, thats what ico relies on.

Yeah, blame cotton. I was pretty sure it was needed, he was fairly convinced it wasn't.

It can be simplified from what it is though; I'm just not interested in doing that right now.

@Ref: anyway I'm pretty sure ICO breaks because of other issues in how VIF parses DMA packets. Packets are *supposed* to be aligned to QWC -- the PS2 hardware should assert either a BUSERR or AddressAlignment error if you try to use DIRECT and the GIFtag data isn't aligned.

Furthermore, some docs indicate that having DIRECT data span across DMA packets is invalid. However it doesn't specify regarding CHAIN DMA, which Ico uses.

The problem is ICO does a DIRECT on the first part of a TAG, and it does TTE. Ive tried fiddling with it and it doesnt skip any data or ignore it, so it has to transfer the 2x32 bits from the tag and the rest from the actual packet, the problem is, usually this would all be in the vif fifo, so we wouldnt have these issues, but as we dont have one, we have to compensate.

cottonvibes

huh, jake i was the one that said ref had code that explicitly tested for non-qwc sizes.

i never said your code will work, i even told you to fix the assertion check because i was pretty sure it would break some random games...

maybe you got me confused with what pseudo said ;p

Revision 3520

ReorderingMTGS: Fix memcpy_amd_qwc.

I was hoping to use the testl instead of "dword ptr" or whatever; but wasn't sure if it was allowed in intel syntax mode or not.

I really hate GAS. Both for sucking and for not being very well documented (like the fact they more or less refuse to document the nuances of intel syntax mode).

Tell me about it. It seems to be working without the 'dword ptr' at this point, though.

If you want to merge this branch into the trunk, I don't have an issue with it, btw...

Revision 3521

ReorderingMTGS: Quick cleanups to gifMFIFO's path parsing.

Revision 3522

ReorderingMTGS: Clean up and unify all OPH flag handling to be in the BUSDIR

handler.

hmmm, i have a horrible suspicion the unifying will have just broken a lot of stuff..

Also it now has zero timing associated with it, so if something sits there watching the oph flag to start off the next transfer, it could attempt to start a DMA while one is still waiting (through internal delaying)

This is based on the only documented way to download data from the GS.

You write 1 to busdir, download the stuff, write 0 and done.

We need to set the OPH flag to high somewhere around then and disable it only when a game asks us to.

Compatibility testing shows this is right btw. All known games to depend on OPH were broken in this branch. Most work again with this.

Bleach doesn't yet though and idk about Killzone. (Bleach disables OPH too early it seems.)

Dude that is only valid for reverse fifo! do you not remember Ice Age 3? It depends on Path 3 on a normal transfer to set the OPH flag. In the documentation, setting Busdir starts the transfer, it doesn't stop it. This is pretty much what sudo originally did when we first got reverse fifo right and it broke a few games which relied on the OPH flag being set in non reverse fifo situations.

Bleach situation is really wierd ill admit, it does a reverse fifo, set everything back to normal then expects the OPH to be set, which is odd and not the documented way for things. However reverse fifo isn't the only situation this is used.

Going on the code you have put in, whenever there is a transfer on any path, OPH will always get set, but never unset as a busdir never gets called at the end of a transfer.

No, I don't remember what Ice Age 3 expects but it surely won't want to set the output direction (OPH) flag and download stuff from GS.

A normal PATH3 transfer is TO the GS, like any other transfer. The OPH flag doesn't have anything to do with that! It indicates that a transfer is happening, but ONLY when the transfer direction has been reversed.

If you think that is wrong, I'll need some docs that say so ;)

it doesnt want to download stuff from the GS at all, it just starts a path3 transfer, then waits for OPH to be set.

OPH does get used in other scenarios, if you check back to the commits when me and sudo were playing with it, you will see this was the case, we've been through this once already :P

If you want me to prove that its the case, ill compile this, test ice age 3 and let you know if it works or not.

Yea, we've been through this and there were misunderstandings :p

(Check the comments on r2954.)

OPH will never be set on a path3, path2 or path1 normal transfer.

I'd like some tech docs that say otherwise.

Games aren't the best thing to prove it ;)

Only if you can show me documents that say it doesnt set OPH when a normal transfer runs :P

However if a game expects it to happen, surely that is expected behaviour no? :P

The flag is called Output Path H(igh?). There's APATH and DIR as well to determine the state for uploads just fine.

OPH would only ever be useful for the EE side to tell when the GS has started sending data, imo.

The Ice Age thing is interesting though, I agree that it's at least something to investigate. Are you sure there's no BUSDIR call before it?

BUSDIR is generally called from the GIF packet, even with reverse fifo, the PATH2 transfer which gets sent before it starts has the BUSDIR in it i believe. In most path3 cases busdir is within the packet itself.

Anyways, just did some inital tests to see how this branch is coming along (and see what breaks here). I only built r3521 and r3522 to test, so i dont know if any of these have been fixed since :p

Broken in r3522

Ice Age

Batman Returns

Spyro: Heroes Tail

Not r3522 related

TOD2 is broken but i dont know when it broke in this branch

Gran Turismo 3&4: keeps freezing on the GS thread (from what i can tell) in this branch

Metal Gear Solid 3: the GS seems to get very stuck for about 10 seconds or so on scene changes (doesnt always happen)#

Grandia 3: Suffer similar things to GT4 and MGS3 on videos

oops just to elaborate, its generally dun via the gif packet rather than hardware write (which is where you centralized it), this is why the old reverse fifo stuff was in GIFPath.cpp.

Oh yeh forgot to mention, back when i wasnt sure about all this, i did run a test on the PS2 from a path3 transfer. OPH was set and APATH was set to 3, until it encounted EOP 1 NLOOP 0, at which point both are unset. Admittedly i didnt touch busdir or the transfer regs tho lol

Just thought that might be a useful tidbit :)

Okay, I'm really no expert on the PATH stuff. But BUSDIR is a GS privileged register. GIF has no access to it!

You access BUSDIR from the EE to signal that you want a GS download to happen.

GIF sees that and prepares all the necessary stuff (likely cleaning the FIFO and setting the DIR flag) and GS should start sending data. As soon as GS sends data, OPH goes high.

(This is how I understand it anyway. If there's some evidence that it's wrong the whole thing needs to be changed again :p )

Let's work out the status of the broken games later. I'll need dumps ;)

Actually a gif packet does have access to it, read up on A+D mode :P

Eh, I don't see how this would (or even could) be used in any meaningful way relating to BUSDIR :p

A+D mode allows writes to the privilaged registers (sends it through a router that the GIF can see and the GS is suppose to sort it) and it can write to busdir with it. Most (if not 100%) of games use it, try it yourself :P

A+D allows access to GENERAL PURPOSE REGISTERS, not privileged registers. Some even have the same address, e.g. BUSDIR is privileged register 0x44, DIMX is GPR 0x44.

[22:49] <rama1> (i'd be REALLY surprised if OPH is anything else than what i expect it to be, a flag that tells when the GS is sending data (ie: "responded"))

[22:49] <pseudonym> What we decided in the end is that OPH is, for whatever reason, a flag that signals activity on the (single) GIF<->GS path

[22:49] <pseudonym> I saw the disasm for ice age

[22:49] <pseudonym> It really does want it

[22:49] <rama1> ...

[22:50] * pseudonym shrugs

[22:50] <rama1> and there'S no doubt about it?

[22:50] <pseudonym> No, there's doubt

[22:50] <rama1> okay :p

[22:50] <pseudonym> We haven't got any really conclusive tests

[22:50] <rama1> well, then i need to get back to the drawing board

[22:50] <rama1> and figure out on which conditions it should be high

[22:51] <rama1> ... could take a while :p

sorry dude, wish it was as simple as you made it, im afraid its not :(

However pseudonym ever assumed that OPH is not set on standard GIF transfers is pretty easy to understand; in spite of it being pretty obvious that this flag (in spite of redundancy) should be set on all standard transfers. He makes those sort of bad assumptions a lot. You can filter them out by looking for words like "definitely", "absolutely", "impossible", or any other absolute condition he puts forth based on his interpretation vague documentation.

How he screwed up the PS2 hardware test is harder to figure out, but oh well.

In any case, my bet is that this is just another case of mixing up GIFtag status with DMA status.

Chances are, OPH should be set from GIFtag parsing *ONLY*; meaning it should never be set in response to GIF dmas being started, stopped, drained, or anything else. However! It may also refer to FIFO activity, which would mean it would be set to TRUE for Reverse FIFO transfers also. But if BBB is the only game having issues then chances are its something else causing it to get unwanted or unexpected GIF statuses.

Anyways, it looks clear that this mod shouldn't have been included in my merge after all. I can revert it out of trunk.

Actually maybe I won't, since I think it'll be easier to just set the OPH flag from the GIFpath parser, and it'll likely be just as compatible as the old system that set it from all kinds of places.

My test sent a lot of primitive data in a single gif primitive. It did not test multiple gif primitives to a packet nor image mode.

Jake: The only problem with having it all in the parser is there is no timing, so the OPH flag could be on and off in an instant, so those games which need to see it on, never will.

This is the only reason it was how it was. I was toying with the idea of making a function which handles all the status stuff to link from VIF/GIF etc, so there is a central point instead of much duplicate code. But the revert really should take place, this has only served to break more games with no fixed ones in the proceeds.

Revision 3523

ReorderingMTGS: Sync with trunk!

Revision 3524

zzogl-pg: remove an unneccessary structure.

Since I now know more about zzogl then I did when I started this, thought I should go back over this code a bit...

Revision 3525

zzogl-pg: Add Swizzle function arrays.

Revision 3526

zzogl-pg: Revise the TransferHostLocal functions a bit. More arrays.

Revision 3527

ReorderingMTGS:

- Delete path1 buffering code, prep-work for the ability to exit execution on

xgkicks.

- Increment save-state version.

Revision 3528

zzogl-pg: Messing around with the BLOCK struct.

Revision 3529

ReorderingMTGS: Added support for breaking and resuming execution on xgkicks for

microVU. (already tested the code... so it works)

Yay! I'll be implementing use of this as soon as possible! :D

Revision 3530

ReorderingMTGS: Minor change to my last commit...

Revision 3531

IPU: Documented YUV colour space used by the IPU since I researched this when

fixing gsdx recording.

Revision 3532

Merge optimizations and code cleanups from the ReorderingMTGS branch (r3523)

into Trunk. Summary of changes:

* GIFpath parsing copies as it parses (speedup!)

* Improved memcpy for 128-bit copies (speedup!)

* MTGS ringbuffer uses free-flowing wrapping now, which simplified ringbuffer

management logic considerably (speedup!)

* Various MTGS-related refactoring (var renames and such)

Goldbla...

I'm getting crashes when starting Persona3:FES and Tales of the Abyss. Running a debug build gives me this message, "GIFpath conflict: Attempted to start PATH2 while PATH3 is already active." Hope this helps. I saved everything from the crash, if needed.

Crashes should be fixed in my latest revision.

Revision 3533

* Converted SPR.cpp and hwMFIFOWrite to use memcpy_qwc in the place of

memcpy_fast.

* Fix a bug in my merge of the new MTGS code that caused crashes on some games

(PATH1 queue bug).

* Added assertion checks to hwMFIFOWrite for qwc alignment and a SPR_LOG for

null ringbuffer addresses (if a game specifies an invalid physical address).

Sajty...

There are more merging issues.

Tested with soul calibur 3.

r3530 reorderingMTGS branch, works with superVU and microVU.

r3531 trunk, works with superVU and microVU.

r3532 trunk, crash with superVU and microVU.

r3533 trunk, crash with superVU, bu works with microVU.

Well... Old revisions of GSDX do not work with ReorderingMTGS...

I had to compile new "Fixed SotC bloom" GSDX...

Will test it with other games later...

atia...

Persona 4 started to crash, sometimes though.

"GIFTAG error, size exceeded VU memory size 3ff"

Do I make something wrong? I'm using superVU.

Also, GH: Metallica does not work anymore. Just saying.

xat...

Gradius V appears to work fine after about an hour of play, at least compared to how it normally works under pcsx2 (glitchy audio, framedrops with vsync off as usual).

Oh right, superVU. I always forget that even exists.

>> Well... Old revisions of GSDX do not work with ReorderingMTGS...

Hmm, well that *is* fixable, though awkward and might be a bit sluggish on some games.

It doesn't worth it... Anyway, only new GSDX plugin will be included in the next "Official beta"... Let's not clutter up the code...

Hefra...

>> Well... Old revisions of GSDX do not work with ReorderingMTGS...

Hmm, well that *is* fixable, though awkward and might be a bit sluggish on some games.

It would be great if it can be done, since all revisions after r2754 have broken image upscaling under dx10 (especially visible in DMC3).

It's done. I thought of a pretty decently clever way to pull it off.

Hefra...

Thanks a lot Jake!

Revision 3534

zzogl-pg: More blocks stuff.

I'm trying to get rid of that FILL_BLOCK define. Main problem I'm having is that I'll need to work around those arrays it's calling.

Oh, and this commit only affects ZZogl-pg. Any issues you see when using GSdx should be reported in a commit prior to this one. :)

I mention this because r3532 was a major change, and things are likely to need adjusting...

Revision 3535

Fix superVU xgkick stuffs.

Revision 3536

GSdx / zzogl-pg / pcsx2:

* Implemented support for legacy GS plugins (considered anything prior to the

Reordering merge).

* Added a lot of 'const' qualifiers to the GSgifTransfer functions in both GSdx

and zzogl.

DevNote: GS plugins shouldn't be modifying the data provided to them from PCSX2

-- zzogl wasn't, GSdx was. I had to do a little bit of juggling to remove the

mem modifications from GSdx's TEX0/TEX2 handlers. With luck, nothing's broken.

;)

Also: I didn't do conversions for the "new" Reg handler in zzogl, since I couldn't really compile/test it. It'll have to be const-qualified later on and, probably, modified to match the changes I made to GSdx's in this revision.

I also really would have preferred to commit these ans separate commits, but too much dependency on the PS2Edefs common header. This is one (rare) case of where having independent copies of that file for each plugin would be helpful.

Having the one unified header was really helpful as we were doing wx conversions and other major/sweeping changes, but now it might be time to consider copying the shared files into each plugin and then upgrading that file together with plugin changes that upgrade the plugin's API. Otherwise a plugin can be built against the older API definitions and, thusly, would still work as a legacy PCSX2 plugin API.

I'll think about it.

Interesting... Have to recompile again...

Are you trying to explore GS emulation, Jake?..

JohnnyKi...

Jake.Stine , my doing those changes you increase compatibility and reduce speed , or vice versa?

>> Are you trying to explore GS emulation, Jake?..

Not really, and even if I did I wouldn't touch DX with a 10meter bungie hose. I'd do a software reference renderer only (with software upscaling), that relies mostly on multicore power.

(and it would still not look really good, and would be horrendously slow, and so no one would use it anyway -- thus its not going to happen ;)

thiago_...

its make new gsdx works again in legacy/old gui versions of pcsx2? because using legacy/old gui with all updated plugins is more faster than new gui... but gsdx not works later than r32xx versions...

No idea. Try it and find out. It's not something I have any interest in working on.

I've applied it. Actually, testing the new register code is just a matter of commenting out the define for "USE_OLD_REGS" in GS.h.

It's actually stable enough at the moment; I just break it often enough while making changes to it that I'd prefer it not on by default.

leomar....

thx very much, but where can i download this plugins?

Download TortoiseSVN, get the Visual Studio 2008, get the source and compile it...

https://code.google.com/p/pcsx2/wiki/CompilationGuideForWindows

Revision 3537

ReorderingMTGS: Sync with Trunk!

Hmmm?.. Sync?.. Again?..

Ragha...

Be happy, he is working hard.

Revision 3538

zzogl-pg: Apply the same changes to the new register code.

Revision 3539

ReorderingMTGS: Renamed input params for CPU_INT for clarity, and associated

minor header file tweaking to make sure the enum is defined everywhere needed.

Nice :)

Revision 3540

ReorderingMTGS:

* Redid the DIRECT upload stuff, while this time retaining full functionality

(the actual inner workings of the PS2 when doing DIRECT + TTE==1 are still a

mystery though)

* Used some references for VIF regs so that I can see their contents when

tracing code in the debugger (msvc can't inspect the macros >_< )

* Added underscores to padding and reserved members of DMA structs and unions,

to help separate them from the more useful members.

I still recon the alignment is down to the fifo alignment rather than the incomming dma packet. It is the only way i can logically explain the ICO missalignment of the DIRECT packets.

On another note with that, i did try padding with 0's, ignoring chunks of data, alsorts, nothing worked, it needs every last byte from the packet to come out correctly :(

Padding with 0's works, unless it has some specific problem later on in the game. I was able to go through the intro fine with zero padding, and I went through the game's loaded memory and didn't see any CALL or REF subrountines that used DIRECT with anything but zeros on the tag.

However, using zero padding isn't really any less invasive than storing up the QWC, so I went ahead and use the provided QWC.

And I agree, it's possible the VIF FIFO has something to do with it being able to coalesce unaligned partial bits into a QWC transfer. Or it should be masking or zeroing data, since ICO works fine with that (maybe some other titles don't? It'd be good to document them if so).

I think KH2 does a similar trick, i know there is another game, but i cant remember what, prolly be good having a devcon output in there so we can see if anything else uses it.

Revision 3541

ReorderingMTGS: Invasion of the POD-safe types...

Revision 3542

A line that got lost somehow. Fixes iop debugging output again.

Revision 3543

ReorderingMTGS:

* minor bugfixes and code cleanups to vif's DIRECT and MPG commands.

* Added const qualifiers to VIF command APIs and aligned/compacted the VifCmd

function tables.

I do plan on tackling the XGKICK and VIF scheduling issues very shortly. Still sorting through code and doing cleanups while I familiarize myself with all the dependency chains.

Revision 3544

ReorderingMTGS: More const qualifiers added, this time on the VIF unpackers.

Revision 3545

ReorderingMTGS: Add consts in Vif_Unpack.cpp. (Needed in Linux due to consts

added in Vif_Unpack.h.)

Hmm, I wonder why msvc didn't complain about that.

Revision 3546

wxWidgets/Win32:

* Fixed a bug that caused all but the first stackframe walk to fail with an

error.

* Improved thread safety of stack walking.

DevNotes: When walking stackframes multiple times from the same process, only

the first stackframe walk would work and all others would fail with an error

because of calling SymInitialize multiple times. So now SymInitialize is only

called once and SymRefreshModuleList is used prior to walking, if available.

(only available in winDbgHlp.dll v6.5 or later)

Revision 3547

ReorderingMTGS: Refactoring Explosion! Replaced a lot of macros to DMA register

structs with references. This way we can easily inspect the contents of the

vars from the MSVC debugger while tracing through code. (shouldn't have any

impact on performance)

Revision 3548

microVU: Added some const qualifiers to the instruction/opcode function LUTs

Revision 3549

Merge const qualifiers and cleanups from ReorderingMTGS: Includes the VIF DIRECT

changes, which seem to be stable this time. ;)

andutrache

See issue 899 .

Revision 3550

Unified the three DmaExec functions into one. :)

Revision 3551

ReorderingMTGS: Sync with trunk.

(getting ready for a weekend on the road)

tarrag...

+ 100 for the huge work done in recent days.

Revision 3552

Fix unintentional alteration of tDMAC_STAT in r3550.

Revision 3553

Need the same fix on reorderMTGS :p

Revision 3554

Revert the OPH work of r3522 as it was based on wrong assumptions (except the

direction flag in BUSDIR, that one was right).

Thank you :) will look in to this with you at some point, two brains are better than one :P

Lol, we already do. So if you wanna have some fun with it as well, irc, as always :D

Revision 3555

Forgot this. Sorry Bleach players.

"Bankais" will work again soon though, we hope :p

cottonvibes

hmm yes, tahnks very much ramsaspcxs2

i trieds ichigos bankais in game and no worked, soo realy happies, i try agains right now! :D

No problem :p

Revision 3556

Some changes to GS stalls. The code was there but commented out.

Fixes Quake III Revolution and the homebrew "Simple Media System".

It's probably all wrong still but hey, better than nothing :p

Revision 3557

GSdx:

Apply hackfix for Wild Arms 4. Thanks Lana and 89CamaroIROCZ :)

We're still missing the PAL and JAP CRCs though. Issue 185 collects them.

f3r....

Could this also fix the scramble white screen in BLACK!?

f3r....

sadly no...

the fix is for wild arms 4, linked to wild arms 4, only working when you play wild arms 4. So no, it doesnt fix Black.

Revision 3558

ZZOgl-pg: Yet more new register work.

wing...

Can you elaborate on what do those registers do?

Thanks for the update!

Well, the ps2 has a large number of registers dedicated to storing values important to graphics. ZZOgl's code for emulating the registers is quite difficult to understand, and does some rather odd things.

What I did is I made a duplicate of the register code, and I've been reworking it so that it is easier to understand. This will let me eventually get rid of some of the odd things it does in there, hopefully.

Since working on this causes games to break on a fairly regular basis, I've kept it turned off in the trunk, though. Right now, if you comment "#define USE_OLD_REGS" out in GS.h, it enables the new code.

I'll probably change it to an ini file setting soon, though, since I'm getting tired of commenting and uncommenting that line.

wing...

That would make some things easier for end-users but I'll give the new register a try then, thanks for explaining it =)