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

From PCSX2 Wiki
Jump to navigation Jump to search

Revision 3500

zzogl-pg:
* Removed extern "C" and applied static const to s_clut16 vars. Should be fine
since the old x86.S files that needed extern "C" have been removed from zzogl.
* Fixed a compilation error in Win32/Debug builds.
* Changed some references of DEVBUILD ZEROGS_DEVBUILD. Not sure if all of them
should be changed over or not, so I just stuck to some of the more obviously
correct bits.
arcum42
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.
Jake.Stine
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)
arcum42
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.
Jake.Stine
huh... well that one sounds pretty unfixable to me. :p
arcum42
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.
arcum42
(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?
arcum42
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 :)
Jake.Stine
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.
arcum42
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)
arcum42
I should probably change the helper functions to static arrays...
arcum42
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.
arcum42
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 >.<
refraction
oops i meant V4_## not 32!
oh and i made it look a bit tidyer in there too, seemed all very squashed
ramapcsx2
Alright, we're lucky we got some forum users that help debug like this, eh?
(Kudos, kickstand ;) )
Jake.Stine
>> oh and i made it look a bit tidyer in there too, seemed all very squashed
Yes, cottonvibes dislikes having to use scrollbars.
sudonim1
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.
refraction
>> 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.
sudonim1
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)
eliotfur
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).
refraction
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.
Jake.Stine
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.
Jake.Stine
@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.
refraction
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.
Jake.Stine
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).
arcum42
Tell me about it. It seems to be working without the 'dword ptr' at this point, though.
arcum42
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.
refraction
hmmm, i have a horrible suspicion the unifying will have just broken a lot of stuff..
refraction
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)
ramapcsx2
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.)
refraction
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.
ramapcsx2
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 ;)
refraction
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.
ramapcsx2
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 ;)
refraction
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
ramapcsx2
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?
refraction
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
refraction
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.
refraction
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 :)
ramapcsx2
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 ;)
refraction
Actually a gif packet does have access to it, read up on A+D mode :P
ramapcsx2
Eh, I don't see how this would (or even could) be used in any meaningful way relating to BUSDIR :p
refraction
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
sudonim1
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.
ramapcsx2
[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
refraction
sorry dude, wish it was as simple as you made it, im afraid its not :(
Jake.Stine
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.
Jake.Stine
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.
sudonim1
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.
refraction
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.
arcum42
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)
Jake.Stine
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.
Jake.Stine
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.
eliotfur
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).
Jake.Stine
Oh right, superVU. I always forget that even exists.
Jake.Stine
>> 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.
eliotfur
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).
Jake.Stine
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.
arcum42
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.
arcum42
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.
;)
Jake.Stine
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.
Jake.Stine
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.
eliotfur
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?
Jake.Stine
>> 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.
Jake.Stine
(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...
Jake.Stine
No idea. Try it and find out. It's not something I have any interest in working on.
arcum42
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?
eliotfur
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!
eliotfur
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.
ramapcsx2
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.
refraction
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.
refraction
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 :(
Jake.Stine
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.
Jake.Stine
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).
refraction
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.
Jake.Stine
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.)
Jake.Stine
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).
refraction
Thank you :) will look in to this with you at some point, two brains are better than one :P
ramapcsx2
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
ramapcsx2
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...
refraction
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!
arcum42
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 =)
arcum42
np. Just keep in mind that it's a work in progress, and if you notice any issues, check without the new register code on.
Though at this point, I'm still keeping fairly close to the old code, so I'm not sure how much of a difference you'll see. Unless you pick one of the revisions where I break the handling of a register, and don't happen to notice for a few revisions... :)
wing...
When I comment that line out it won't build on ubuntu:
Building CXX object plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/GLWinX11.cpp.o
Building CXX object plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/GLWin32.cpp.o
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:24: error: ‘define’ does not name a type
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
//usr/include/GL/glew.h:1607: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1608: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1612: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4452: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4453: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4456: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:5363: error: typedef ‘GLintptr’ is initialized (use decltype instead)
//usr/include/GL/glew.h:5363: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ was not declared in this scope
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
//usr/include/GL/glew.h:5706: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5706: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5801: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5875: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5876: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5877: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5878: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5879: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5880: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5881: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5882: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5883: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5884: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5885: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7683: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9515: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9630: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:11932: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:61,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/cstddef:51: error: ‘::ptrdiff_t’ has not been declared
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected type-specifier before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected ‘>’ before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:113: error: ‘_Pointer’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:115: error: ‘_Reference’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:139: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:149: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:69,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator.h:95: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:390: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:474: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:561: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
In file included from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_algobase.h: In static member function ‘static _Tp* std::__copy_move_backward<_IsMove, true, std::random_access_iterator_tag>::__copy_move_b(const _Tp*, const _Tp*, _Tp*)’:
/usr/include/c++/4.4/bits/stl_algobase.h:574: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_algobase.h:575: error: ‘_Num’ was not declared in this scope
In file included from /usr/include/c++/4.4/i686-linux-gnu/bits/c++allocator.h:34,
from /usr/include/c++/4.4/bits/allocator.h:48,
from /usr/include/c++/4.4/vector:62,
--
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/ext/new_allocator.h: At global scope:
/usr/include/c++/4.4/ext/new_allocator.h:40: error: ‘std::ptrdiff_t’ has not been declared
/usr/include/c++/4.4/ext/new_allocator.h:55: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:62,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/allocator.h:68: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/allocator.h:90: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:65,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_vector.h:192: error: ‘ptrdiff_t’ does not name a type
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:24: error: ‘define’ does not name a typeIn file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h:108: error: template argument 3 is invalid
/usr/include/c++/4.4/bits/stl_bvector.h:137: error: ‘ptrdiff_t’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::_Bit_iterator_base::_M_incr(int)’:
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: expected ‘;’ before ‘__n’
/usr/include/c++/4.4/bits/stl_bvector.h:140: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:179: error: expected initializer before ‘operator’
/usr/include/c++/4.4/bits/stl_bvector.h:231: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:231: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:237: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:244: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:245: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:252: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:259: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:248: error: no match for ‘operator+=’ in ‘__tmp += __i’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:255: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: declaration of ‘operator+’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:317: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:317: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:323: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:330: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:331: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:338: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:345: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:334: error: no match for ‘operator+=’ in ‘__tmp += __i’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:341: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: declaration of ‘operator+’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:481: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
--
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:622: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_const_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_const_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:626: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_const_iterator’
In file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘size_t std::vector<bool, _Alloc>::max_size() const’:
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: template argument 1 is invalid
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::vector<bool, _Alloc>::insert(std::_Bit_iterator, const bool&)’:
/usr/include/c++/4.4/bits/stl_bvector.h:775: error: ‘difference_type’ does not name a type
/usr/include/c++/4.4/bits/stl_bvector.h:781: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::resize(size_t, bool)’:
/usr/include/c++/4.4/bits/stl_bvector.h:826: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/stl_bvector.h:826: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::_M_initialize(size_t)’:
/usr/include/c++/4.4/bits/stl_bvector.h:863: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_fill_insert(std::_Bit_iterator, size_t, bool)’:
/usr/include/c++/4.4/bits/vector.tcc:591: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:592: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:593: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:602: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:604: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)’:
/usr/include/c++/4.4/bits/vector.tcc:627: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:629: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
//usr/include/GL/glew.h:1607: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1608: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1612: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4452: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4453: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4456: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:5363: error: typedef ‘GLintptr’ is initialized (use decltype instead)
//usr/include/GL/glew.h:5363: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ was not declared in this scope
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
//usr/include/GL/glew.h:5706: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5706: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLintptr’ has not been declaredIn file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:24: error: ‘define’ does not name a type
In file included from /usr/include/c++/4.4/bits/char_traits.h:42,
from /usr/include/c++/4.4/string:42,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/postypes.h: At global scope:
/usr/include/c++/4.4/bits/postypes.h:98: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/string:46,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/ostream_insert.h:43: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:48: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:49: error: ‘__put’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:55: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:75: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:85: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:86: error: ‘__w’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:117: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:121: error: ‘streamsize’ has not been declared
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
//usr/include/GL/glew.h:1607: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1608: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:1612: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1613: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:1621: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2549: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5801: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5875: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5876: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5877: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5878: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5879: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5880: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5881: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5882: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5883: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5884: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5885: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7683: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9515: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9630: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:11932: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ does not name a type
In file included from /usr/include/c++/4.4/string:56,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
/usr/include/c++/4.4/bits/basic_string.tcc: In function ‘std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, std::basic_string<_CharT, _Traits, _Alloc>&)’:
/usr/include/c++/4.4/bits/basic_string.tcc:1019: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/basic_string.tcc:1020: error: ‘__w’ was not declared in this scope
In file included from /usr/include/c++/4.4/string:53,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/basic_string.h: At global scope:
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1134: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<char>’
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1149: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<wchar_t>’
//usr/include/GL/glew.h:2793: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:2793: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3358: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:3359: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:4284: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:4452: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4453: error: ‘ptrdiff_t’ does not name a type
//usr/include/GL/glew.h:4456: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4457: error: ‘GLsizeiptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLintptrARB’ has not been declared
//usr/include/GL/glew.h:4462: error: ‘GLsizeiptrARB’ has not been declared
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:20:
//usr/include/malloc.h:86: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: expected ‘,’ or ‘;’ before ‘throw’
//usr/include/GL/glew.h:5363: error: typedef ‘GLintptr’ is initialized (use decltype instead)
//usr/include/GL/glew.h:5363: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ was not declared in this scope
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:36,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
//usr/include/GL/glew.h:5706: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5706: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5733: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5756: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5801: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5802: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5803: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:5875: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5876: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5877: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5878: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5879: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5880: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5881: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5882: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5883: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5884: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:5885: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7683: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:7684: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9515: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLintptr’ has not been declared
//usr/include/GL/glew.h:9516: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:9630: error: ‘GLsizeiptr’ has not been declared
//usr/include/GL/glew.h:11932: error: ‘PFNGLGETUNIFORMOFFSETEXTPROC’ does not name a type
In file included from /usr/include/c++/4.4/list:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:28,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:22:
/usr/include/c++/4.4/bits/stl_list.h:118: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:194: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:438: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/map:60,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:30,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GifTransfer.cpp:22:
/usr/include/c++/4.4/bits/stl_tree.h:160: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:232: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:341: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:69,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
--
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const char**, std::vector<const char*, std::allocator<const char*> > >’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:165: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:176: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/vector.tcc:321: error: no match for ‘operator-’ in ‘__position - std::vector<_Tp, _Alloc>::begin [with _Tp = const char*, _Alloc = std::allocator<const char*>]()’
make[3]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/GifTransfer.cpp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:61,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/cstddef:51: error: ‘::ptrdiff_t’ has not been declared
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:61,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/cstddef:51: error: ‘::ptrdiff_t’ has not been declared
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected type-specifier before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected ‘>’ before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:113: error: ‘_Pointer’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:115: error: ‘_Reference’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:139: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected type-specifier before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:102: error: expected ‘>’ before ‘ptrdiff_t’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:113: error: ‘_Pointer’ does not name a type/usr/include/c++/4.4/bits/stl_iterator_base_types.h:149: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:115: error: ‘_Reference’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:139: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:149: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:69,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator.h:95: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:69,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_iterator.h:95: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:390: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:390: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:474: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:561: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
/usr/include/c++/4.4/bits/stl_iterator.h:474: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
In file included from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_algobase.h: In static member function ‘static _Tp* std::__copy_move_backward<_IsMove, true, std::random_access_iterator_tag>::__copy_move_b(const _Tp*, const _Tp*, _Tp*)’:
/usr/include/c++/4.4/bits/stl_algobase.h:574: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_algobase.h:575: error: ‘_Num’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_iterator.h:561: error: wrong number of template arguments (5, should be 3)
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:104: error: provided for ‘template<class _Category, class _Tp, class _Distance> struct std::iterator’
In file included from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_algobase.h: In static member function ‘static _Tp* std::__copy_move_backward<_IsMove, true, std::random_access_iterator_tag>::__copy_move_b(const _Tp*, const _Tp*, _Tp*)’:
/usr/include/c++/4.4/bits/stl_algobase.h:574: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_algobase.h:575: error: ‘_Num’ was not declared in this scope
In file included from /usr/include/c++/4.4/i686-linux-gnu/bits/c++allocator.h:34,
from /usr/include/c++/4.4/bits/allocator.h:48,
from /usr/include/c++/4.4/vector:62,
--
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/ext/new_allocator.h: At global scope:
/usr/include/c++/4.4/ext/new_allocator.h:40: error: ‘std::ptrdiff_t’ has not been declared
/usr/include/c++/4.4/ext/new_allocator.h:55: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:62,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/allocator.h:68: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/allocator.h:90: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/i686-linux-gnu/bits/c++allocator.h:34,
from /usr/include/c++/4.4/bits/allocator.h:48,
from /usr/include/c++/4.4/vector:62,
--
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/ext/new_allocator.h: At global scope:
/usr/include/c++/4.4/ext/new_allocator.h:40: error: ‘std::ptrdiff_t’ has not been declared
/usr/include/c++/4.4/ext/new_allocator.h:55: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:62,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/allocator.h:68: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/allocator.h:90: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:65,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_vector.h:192: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:65,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_vector.h:192: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h:108: error: template argument 3 is invalid
/usr/include/c++/4.4/bits/stl_bvector.h:137: error: ‘ptrdiff_t’ has not been declared
In file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h:108: error: template argument 3 is invalid/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::_Bit_iterator_base::_M_incr(int)’:
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: expected ‘;’ before ‘__n’
/usr/include/c++/4.4/bits/stl_bvector.h:140: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:137: error: ‘ptrdiff_t’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:179: error: expected initializer before ‘operator’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::_Bit_iterator_base::_M_incr(int)’:
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:139: error: expected ‘;’ before ‘__n’/usr/include/c++/4.4/bits/stl_bvector.h:231: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:231: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:237: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:244: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:245: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:252: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:259: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:140: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:248: error: no match for ‘operator+=’ in ‘__tmp += __i’/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:179: error: expected initializer before ‘operator’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:255: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h:231: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:231: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: declaration of ‘operator+’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:237: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:238: error: expected ‘;’ before ‘(’ token/usr/include/c++/4.4/bits/stl_bvector.h:317: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:317: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:323: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:330: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:331: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:338: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:345: error: ‘difference_type’ has not been declared/usr/include/c++/4.4/bits/stl_bvector.h:244: error: expected ‘;’ before ‘iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:245: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:252: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:259: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:248: error: no match for ‘operator+=’ in ‘__tmp += __i’/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:334: error: no match for ‘operator+=’ in ‘__tmp += __i’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:341: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::_Bit_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:255: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: declaration of ‘operator+’ as non-function/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: declaration of ‘operator+’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:264: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:317: error: declaration of ‘operator+=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:317: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:323: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: declaration of ‘operator-=’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:324: error: expected ‘;’ before ‘(’ token
/usr/include/c++/4.4/bits/stl_bvector.h:330: error: expected ‘;’ before ‘const_iterator’
/usr/include/c++/4.4/bits/stl_bvector.h:331: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:338: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:345: error: ‘difference_type’ has not been declared
/usr/include/c++/4.4/bits/stl_bvector.h:481: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator+(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:334: error: no match for ‘operator+=’ in ‘__tmp += __i’
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_const_iterator std::_Bit_const_iterator::operator-(int) const’:
/usr/include/c++/4.4/bits/stl_bvector.h:341: error: no match for ‘operator-=’ in ‘__tmp -= __i’
/usr/include/c++/4.4/bits/stl_bvector.h: At global scope:
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: declaration of ‘operator+’ as non-function
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: ‘ptrdiff_t’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:350: error: expected primary-expression before ‘const’
/usr/include/c++/4.4/bits/stl_bvector.h:481: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
--
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:622: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_const_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_const_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:626: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_const_iterator’
In file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘size_t std::vector<bool, _Alloc>::max_size() const’:
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: template argument 1 is invalid
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::vector<bool, _Alloc>::insert(std::_Bit_iterator, const bool&)’:
/usr/include/c++/4.4/bits/stl_bvector.h:775: error: ‘difference_type’ does not name a type
/usr/include/c++/4.4/bits/stl_bvector.h:781: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::resize(size_t, bool)’:
/usr/include/c++/4.4/bits/stl_bvector.h:826: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/stl_bvector.h:826: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:67,
from /usr/include/c++/4.4/vector:61,
--
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:622: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h: In instantiation of ‘std::iterator_traits<std::_Bit_const_iterator>’:
/usr/include/c++/4.4/bits/stl_iterator.h:103: instantiated from ‘std::reverse_iterator<std::_Bit_const_iterator>’
/usr/include/c++/4.4/bits/stl_bvector.h:626: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:127: error: no type named ‘iterator_category’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:128: error: no type named ‘value_type’ in ‘struct std::_Bit_const_iterator’
/usr/include/c++/4.4/bits/stl_iterator_base_types.h:129: error: no type named ‘difference_type’ in ‘struct std::_Bit_const_iterator’
In file included from /usr/include/c++/4.4/vector:66,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘size_t std::vector<bool, _Alloc>::max_size() const’:
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: ‘difference_type’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h:662: error: template argument 1 is invalid
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘std::_Bit_iterator std::vector<bool, _Alloc>::insert(std::_Bit_iterator, const bool&)’:
/usr/include/c++/4.4/bits/stl_bvector.h:775: error: ‘difference_type’ does not name a type
/usr/include/c++/4.4/bits/stl_bvector.h:781: error: ‘__n’ was not declared in this scope
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::_M_initialize(size_t)’:
/usr/include/c++/4.4/bits/stl_bvector.h:863: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::resize(size_t, bool)’:
/usr/include/c++/4.4/bits/stl_bvector.h:826: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/stl_bvector.h:826: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/usr/include/c++/4.4/bits/stl_bvector.h: In member function ‘void std::vector<bool, _Alloc>::_M_initialize(size_t)’:
/usr/include/c++/4.4/bits/stl_bvector.h:863: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_fill_insert(std::_Bit_iterator, size_t, bool)’:
/usr/include/c++/4.4/bits/vector.tcc:591: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:592: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:593: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:602: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:604: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)’:
/usr/include/c++/4.4/bits/vector.tcc:627: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:629: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_fill_insert(std::_Bit_iterator, size_t, bool)’:
/usr/include/c++/4.4/bits/vector.tcc:591: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:592: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:593: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:602: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:604: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<bool, _Alloc>::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)’:
/usr/include/c++/4.4/bits/vector.tcc:627: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
/usr/include/c++/4.4/bits/vector.tcc:629: error: there are no arguments to ‘difference_type’ that depend on a template parameter, so a declaration of ‘difference_type’ must be available
In file included from /usr/include/c++/4.4/bits/char_traits.h:42,
from /usr/include/c++/4.4/string:42,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/postypes.h: At global scope:
/usr/include/c++/4.4/bits/postypes.h:98: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/bits/char_traits.h:42,
from /usr/include/c++/4.4/string:42,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/postypes.h: At global scope:
/usr/include/c++/4.4/bits/postypes.h:98: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/string:46,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/ostream_insert.h:43: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:48: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:49: error: ‘__put’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:55: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:75: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:85: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:86: error: ‘__w’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:117: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:121: error: ‘streamsize’ has not been declared
In file included from /usr/include/c++/4.4/string:46,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/ostream_insert.h:43: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:48: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:49: error: ‘__put’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:55: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:75: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h: In function ‘std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, int)’:
/usr/include/c++/4.4/bits/ostream_insert.h:85: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/ostream_insert.h:86: error: ‘__w’ was not declared in this scope
/usr/include/c++/4.4/bits/ostream_insert.h: At global scope:
/usr/include/c++/4.4/bits/ostream_insert.h:117: error: ‘streamsize’ has not been declared
/usr/include/c++/4.4/bits/ostream_insert.h:121: error: ‘streamsize’ has not been declared
In file included from /usr/include/c++/4.4/string:56,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
/usr/include/c++/4.4/bits/basic_string.tcc: In function ‘std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, std::basic_string<_CharT, _Traits, _Alloc>&)’:
/usr/include/c++/4.4/bits/basic_string.tcc:1019: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/basic_string.tcc:1020: error: ‘__w’ was not declared in this scope
In file included from /usr/include/c++/4.4/string:53,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/basic_string.h: At global scope:
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1134: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<char>’
In file included from /usr/include/c++/4.4/string:56,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
/usr/include/c++/4.4/bits/basic_string.tcc: In function ‘std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, std::basic_string<_CharT, _Traits, _Alloc>&)’:
/usr/include/c++/4.4/bits/basic_string.tcc:1019: error: ‘streamsize’ does not name a type
/usr/include/c++/4.4/bits/basic_string.tcc:1020: error: ‘__w’ was not declared in this scope
In file included from /usr/include/c++/4.4/string:53,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:58,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/basic_string.h: At global scope:
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<char, std::char_traits<char>, std::allocator<char> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1134: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<char>’
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1149: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<wchar_t>’
/usr/include/c++/4.4/bits/basic_string.h: In instantiation of ‘std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >’:
/usr/include/c++/4.4/bits/basic_string.tcc:1149: instantiated from here
/usr/include/c++/4.4/bits/basic_string.h:114: error: no type named ‘difference_type’ in ‘class std::allocator<wchar_t>’
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:20:
//usr/include/malloc.h:86: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: expected ‘,’ or ‘;’ before ‘throw’
In file included from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:20:
//usr/include/malloc.h:86: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: ‘ptrdiff_t’ was not declared in this scope
//usr/include/malloc.h:89: error: expected ‘,’ or ‘;’ before ‘throw’
In file included from /usr/include/c++/4.4/list:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:28,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:21:
/usr/include/c++/4.4/bits/stl_list.h:118: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:194: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:438: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/list:63,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:28,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:21:
/usr/include/c++/4.4/bits/stl_list.h:118: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/map:60,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:30,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:21:
/usr/include/c++/4.4/bits/stl_tree.h:160: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:194: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:232: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:341: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_list.h:438: error: ‘ptrdiff_t’ does not name a type
In file included from /usr/include/c++/4.4/map:60,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:30,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWin32.cpp:21:
/usr/include/c++/4.4/bits/stl_tree.h:160: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:232: error: ‘ptrdiff_t’ does not name a type
/usr/include/c++/4.4/bits/stl_tree.h:341: error: ‘ptrdiff_t’ does not name a type
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp: In member function ‘void GLWindow::ResizeCheck()’:
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:269: warning: comparison between signed and unsigned integer expressions
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GLWinX11.cpp:269: warning: comparison between signed and unsigned integer expressions
--
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const char**, std::vector<const char*, std::allocator<const char*> > >’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:165: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:176: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/vector.tcc:321: error: no match for ‘operator-’ in ‘__position - std::vector<_Tp, _Alloc>::begin [with _Tp = const char*, _Alloc = std::allocator<const char*>]()’
In file included from /usr/include/c++/4.4/bits/stl_algobase.h:69,
from /usr/include/c++/4.4/vector:61,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
--
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const char**, std::vector<const char*, std::allocator<const char*> > >’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const char**>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:165: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<const unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h: In instantiation of ‘__gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >’:
/usr/include/c++/4.4/bits/vector.tcc:176: instantiated from ‘std::vector<_Tp, _Alloc>& std::vector<_Tp, _Alloc>::operator=(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char, _Alloc = std::allocator<unsigned char>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/zerogs.h:256: instantiated from here
/usr/include/c++/4.4/bits/stl_iterator.h:679: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:730: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:734: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:738: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:742: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
/usr/include/c++/4.4/bits/stl_iterator.h:746: error: no type named ‘difference_type’ in ‘struct std::iterator_traits<unsigned char*>’
In file included from /usr/include/c++/4.4/vector:69,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/Util.h:57,
from /home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/GS.h:26,
--
/usr/include/c++/4.4/bits/vector.tcc: In member function ‘void std::vector<_Tp, _Alloc>::_M_insert_aux(__gnu_cxx::__normal_iterator<typename std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::pointer, std::vector<_Tp, _Alloc> >, const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’:
/usr/include/c++/4.4/bits/stl_vector.h:741: instantiated from ‘void std::vector<_Tp, _Alloc>::push_back(const _Tp&) [with _Tp = const char*, _Alloc = std::allocator<const char*>]’
/home/wingnux/pcsx2-read-only/plugins/zzogl-pg/opengl/ZeroGSShaders/zerogsshaders.h:47: instantiated from here
/usr/include/c++/4.4/bits/vector.tcc:321: error: no match for ‘operator-’ in ‘__position - std::vector<_Tp, _Alloc>::begin [with _Tp = const char*, _Alloc = std::allocator<const char*>]()’
make[3]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/GLWinX11.cpp.o] Error 1
make[3]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/GLWin32.cpp.o] Error 1
make[2]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/all] Error 2
make[1]: *** [plugins/zzogl-pg/opengl/CMakeFiles/zzogl.dir/rule] Error 2
make: *** [zzogl] Error 2
arcum42
"GS.h:24: error: ‘define’ does not name a type"?
Doesn't sound right that it'd be giving an error about a commented out line, since that'd be the line in question...

Revision 3559

ZZOgl-pg: A bunch of work on the Windows dialog. Based off of an rc file given
to me by SonicPCSX2, then hacked on a bunch by me.

Revision 3560

zzogl-pg: A few minor changes to the last commit.

Revision 3561

zzogl-pg: Copy ps2hw.dat into the plugin directory when building.
prison_b...
is it normal that on fatal frame 1 when i am fighting a ghost the fps drop to half?
sorry to ask this here i just didn´t know where else to ask
system.compiler
@prison: you can always ask in the forum.
before making a thread or asking in the forum,search first.

Revision 3562

Memcpy (linux): Use volatile constraint to avoid complete removal of the
function when activating -fdce (dead code elimination).
Actually there is no impact for the moment because the optimization is not
activate by default.
gregory....
Ok, I implement my idea of "sub 1" without the shr. Here the patch.
We gain a register and a move instruction. It also replaces the shr by a sub/jump. Note it is maybe needed to declare qwc as a signed int.
Index: pcsx2.snapshot-3561/common/src/Utilities/x86/MemcpyVibes.cpp
===================================================================
--- pcsx2.snapshot-3561.orig/common/src/Utilities/x86/MemcpyVibes.cpp
+++ pcsx2.snapshot-3561/common/src/Utilities/x86/MemcpyVibes.cpp
@@ -183,11 +183,11 @@
__asm__ __volatile__
(
".intel_syntax noprefix\n"
- "mov eax, %[qwc]\n" // keep a copy of count for looping
- "shr eax, 1\n"
- "jz memcpy_qwc_1\n" // only one 16 byte block to copy?
+ "sub %[qwc], 1\n" // dec the counter to ease the count of 16bytes block later (optimization)
+ // Note after this line, real value of the counter is %[qwc] + 1
+ "jle memcpy_qwc_1\n" // only one 16 byte block to copy? Or nothing.
- "cmp eax, 64\n" // "IN_CACHE_COPY/32"
+ "cmp %[qwc], 127\n" // "IN_CACHE_COPY/16"
"jb memcpy_qwc_loop1\n" // small copies should be cached (definite speedup --air)
"memcpy_qwc_loop2:\n" // 32-byte blocks, uncached copy
@@ -204,8 +204,8 @@
"add %[src],32\n" // update source pointer
"add %[dest],32\n" // update destination pointer
- "sub eax,1\n"
- "jnz memcpy_qwc_loop2\n" // last 64-byte block?
+ "sub %[qwc],2\n"
+ "jg memcpy_qwc_loop2\n" // last 64-byte block?
"sfence\n" // flush the write buffer
"jmp memcpy_qwc_1\n"
@@ -227,12 +227,12 @@
"add %[src],32\n" // update source pointer
"add %[dest],32\n" // update destination pointer
- "sub eax,1\n"
- "jnz memcpy_qwc_loop1\n" // last 64-byte block?
+ "sub %[qwc],2\n"
+ "jg memcpy_qwc_loop2\n" // last 64-byte block?
"memcpy_qwc_1:\n"
- "test %[qwc],1\n"
- "jz memcpy_qwc_final\n"
+ "cmp %[qwc],0\n"
+ "jne memcpy_qwc_final\n"
"movq mm0,[%[src]]\n"
"movq mm1,[%[src]+8]\n"
"movq [%[dest]], mm0\n"
@@ -243,7 +243,7 @@
".att_syntax\n"
: "=&r"(dest), "=&r"(src), "=&r"(qwc)
: [dest]"0"(dest), [src]"1"(src), [qwc]"2"(qwc)
- : "memory", "eax", "mm0", "mm1", "mm2", "mm3"
+ : "memory", "mm0", "mm1", "mm2", "mm3"
);
}
#endif

Revision 3563

Memcpy (linux): Mangle asm label name avoid symbol already defined when inline
the function
Note: the function can be moved into a .h ;)
Note2: %= is replaced by a number so it is a bad idea to put it after a digit
(reason why I put underscore before)

Revision 3564

wiki: update 64bits stuff.

Revision 3565

wiki: properly support the summary flags...

Revision 3566

cmake: Use same variable name for output. Allow easier copy-paste between files.
Do not know why I did not do it earlier.

Revision 3567

cmake: properly separate ldflags from cflags

Revision 3568

Added a threadless state managed IPU. The code is still in it's early stages and
will now be worked on to optimize for speed. The first optimization is to
increase the read size in Vlc.h from 32 bit to 64 bit.
arcum42
+1 for getting rid of coroutine. I did notice somewhat blocky looking videos, but I'm assuming that'll be straightened out eventually...
arcum42
(Said videos were in the opening for Atelier Iris 1, Dragon Quest 8, and Persona 4, incidentally. Since those were the first 3 games I tried, I'm assuming it's more then just those 3...)
doodhwal...
akhtar bhai onboard!! welcome back
tarrag...
Good job :)
Jake.Stine
Disgaea 2 and FF12 vids look fine here. No blocks.
Jake.Stine
Atelier Iris 2 looks fine also (well, its mpegs are especially blocky to begin with, but side-by-side both versions of IPU look right about the same). The only difference is that it runs about 20-30% slower right now, so the standard mpeg artifacts are a lot more visible than they are normally, and animation doesn't feel as smooth. I don't have P4, DQ8, or AI1 to compare against tho, so maybe its something obscurely limited to just them.
(or maybe its a linux/gcc specific problem)
ramapcsx2
Yep, all mentioned games are fine here.
Must be a linux only issue, so I'd check the optimization flags first :p
arcum42
Yeah, it's Linux only. Doesn't even show up in zzogl-pg in Windows.
I hate debugging those...
Jake.Stine
Ok, its likely some kind of type issue with the mpeg decoder, I'd assume. GCC is either truncating something MSVC is not, or vice versa. Verbose warnings on the mpeg/vlc code might help shed some light on the cause.
msakh...
Slowness of the IPU will be fixed. With the coroutines, it was next to impossible to profile IPU and now since that is available I'll go ahead and optimize.
Let me know if you guys see any blocking issues with the new code and I'll be happy to take a look at it (provided you link the blockdump with your bug as well)
tatsuy...
Sky Odyssey dropped 4 FPS, been on a steady decline recently now down from 54 FPS at it's highest quite a while ago to 45 FPS as of now during the intro. No errors, emulation is accurate that I can see.
DX 10 Hardware mode on HD 4870 1GB with i7 920 @ 4GHz.
EE: 100% | GS: 10%~33% | UI: 0%.
zantezuken
Yay, saqib is back!
And he commited his IPU work! At last (i thought we gonna wait for it 'till 2011)
tarrag...
No problem for Kingdom Hearts 2 :p
wing...
Sonic Unleashed FMVs are blocky =/
pcsx2gu...
wingnux: Yes, on _Linux_ as it has been dully noted about 5 times here. Which is a GCC problem it seems and not this commit itself.
Congrats for the breakthough saqib, this has been haunting PCSX2 since day one of IPU
arcum42
"dully noted"? I'll have to find more interesting ways to note it in the future. :)
No obvious compiler warnings, btw, and it looks the same under Debug mode, so it's not looking like a flag issue, either.
And while the problem is specific to compiling in gcc, it did start on this commit. Which was otherwise a much needed commit, and something a number of us have wanted to see for a while...
arcum42
Oh, just for a visual reference, when I say "blocky", this would be what I mean:
http://img37.imageshack.us/img37/5605/screenshot072910025545.png
The blocks go away when the movie stays on the same scene for a minute, but comes back if anything changes much. Looks like some of the poor quality videos you occasionally see floating around.
pcsx2gu...
Yeah iirc it's called macroblocking and was an issue with all videos in the past. Got fixed at some point though...I guess saqib should have an idea
arcum42
Thanks. I knew there was a term for it, but I couldn't place it.
What irritates me is that this code looks fairly compiler neutral, and even eliminates some compiler-specific code. It really shouldn't be breaking only on Linux. And I'm not really fluent enough in how video encoding works to have a good idea where the issue is.
Oh well, hopefully saqib will know. Or it may just vanish as the code gets optimized... ^_^
msakh...
Hmm, I suspect it's the way GCC is compiling the code. From the picture itself it looks like the bitstream is getting misaligned...just my two cents. I hope this goes away with optimization (never been a fan of linux:P )
Jake.Stine
As far as I can figure, the problem with IPU is probably related to a signed/unsigned typecast or a static variable that's being included into multiple modules that MSVC and GCC handles differently (since we've had issues with that in the past). In a worst case there could actually be some real bug in the code that only manifests in gcc due to how it lays out the variables in memory or something.
In any case, GCC's codegen in debug builds is most likely 100% correct, so blaming GCC is probably not a good idea here. We've had lots of problems with GCC optimization breaking thing, but never can I remember have we had issues with codegen bugs in debug builds. >_<
arcum42
Ah, here's something. Comment out line 623 of Mpeg.cpp (in r3585). The graphical corruption you then get in movies in Windows is exactly the same as all Linux builds currently get.
Now for me to play with that function in Linux for a while...
arcum42
Hmmm... val, in fact, usually is 0 at that point in Linux.
arcum42
Think I've got it. I'll test with a clean compile first, though.
This falls under the second of Jakes suggestions for what would cause the issue.
Syst3mSh0ck
Great work Saqib!

Revision 3569

pcsx2: Update the project files to no longer have coroutine. Fix a compiler
warning. (zzogl-pg: Modify comments.)
shadowladyngemu
12>..\..\Ipu\IPU.cpp(978) : error C2059: syntax error : 'bad suffix on number'
12>..\..\Ipu\IPU.cpp(978) : error C2146: syntax error : missing ')' before identifier 'U'
12>..\..\Ipu\IPU.cpp(978) : error C2059: syntax error : ')'
arcum42
Nice. I was wondering if Windows would have any gripes about that. I'll do a workaround.
arcum42
Try r3570. LLU must be gcc specific...
shadowladyngemu
Yep, r3570 builds fine.

Revision 3570

pcsx2: Since Windows didn't like that change, here's a quick workaround.
Jake.Stine
ULL usually works in Windows and GCC.
Jake.Stine
(... note the subtle difference from LLU, lol)
arcum42
I suppose 0xFFFFFFFFFFFFFFFFULL is a bit more entertaining, anyways... :)
arcum42
(It occurred to me that that might work, but I knew ifdeffing would work for sure, and I was having trouble finding anything that stated it'd work definitively in Windows until after the commit...)
Jake.Stine
Also, without the ULL or a (u64) cast, I'm pretty sure MSVC will truncate the value to 32 bits. -_-
You can also use limit.h's definesdefines for these sort of things, which is probably preferred since it eliminates the need to count F's:
INT_MAX
UINT_MAX
LLONG_MAX
ULLONG_MAX
etc. The last one is the one we want in this case.
You can also use STL's, though of course the STL is designed to kill brain cells:
std::numeric_limits<u64>::max() // wtf, my brain just fried.
arcum42
Sounds like a better way to handle it. I'll just add:
#include <limits.h>
In the mix, and use ULLONG_MAX.
arcum42
Lets try it again. r3571...
Jake.Stine
In STL's defense, I'll make note that the brain frying syntax is meant for templates -- you can write type-generic code that feeds the type into the numeric_limits class and returns the type-generic result.
arcum42
Hmmm... Yeah, I can see uses for that.
Of course, one of these things I need to figure out one of these days is how to have a variable be u8, u16, or u32, depending on the value of one of the functions perimeters. (I'm currently using a template, and just passing the variable type.)
But then, that's the mess that is Mem.cpp in ZZOgl...

Revision 3571

pcsx2: Ok, take 3.
arcum42
Of course, I do notice that we aren't even using that function yet... :)
jaens...
c++ style is <climits> not <limits.h>

Revision 3572

Minor log change.

Revision 3573

IPU: Various minor header file, table, and inline function tweakings/cleanups.
Note that I unified several tables into structs and applied __aligned16 to them.
I'm not just being silly: this seems to have a noticeable positive effect on
framerates (~3-4% here).
Jedy.Kni...
2fps increase in GOW menu
refraction
2fps increase? amazing, i don't think it even uses ipu :)

Revision 3574

New gamefix hack that alternates the GIF_STAT flag "OPH" on each register read.
This will be needed until we've figured out how this thing is supposed to work.
Enabling this hack should fix, among others, Growlanser games, Bleach and
Wizardry.
andutrache
+Naruto Uzumaki Chronicles 1 and 2 :)
refraction
I though the Growlanser games were all working after the reverse fifo stuff was fixed? good solution neway :P
ramapcsx2
Yea, no. :p
I had that one thing that breaks Killzone still enabled, so on BUSDIR calls it'd still set OPH high. That fixed most of *my* OPH games.
Next revision reverted that too though, and then nothing worked anymore.
Pseudo is eager to figure it out. Till then we can use this :p
gesielon...
YEA!!
emuk...
thank!
but Venus and Braves
still freeze in op :)
ramapcsx2
It's a bad hack guys. No need for +1's for this :p
atia...
but it's still a hack. better than nothing :p
weimingzhi
this hack also solves FF12 PAL freeze whenever a character makes an attack with supervu most of the time, although it still freezes from time to time.
ramapcsx2
Which FF12 PAL is that? The different countries versions all seem to have unique code ><.
Mine is PAL german and it seems fine.
Dhalai.L...
Naruto works ?? +1 then !
romulux_...
Somewhere between r3541 and this revision which I tested Burnout Dominator started showing flashing textures/SPS and game instability (random crashes). I am using r3540 and it works just fine with no graphical hitch (Skipdraw = 3).
I haven't tested any other games yet because I am only playing this one atm.
romulux_...
I have gamefixes off. I am not sure if it has anything to do with this revision or not but I didn't know where to post :P.
refraction
There has been a lot of changes since r3541 :P can you try some intermediate versions please?
romulux_...
Guess what Refraction? You were right about it being alot of revisions in between those two.
Ok, to my great surprise the problems originates in either one of revisions r3541 or r3542. I did the tests on 3542 (I don't have 3541) and I got dissapearing ground, texture tearing and pscx2 breaking and closing.
I am using MicroVU; VU Cycle stealing speedhack, but I did perform the tests without any speedhacks enabled at all, and the problems are still there; Gsdx 3068; SPU2-X 3117; Linuz Izo 3065 for all the tests.
PS: sometimes my game breaks with a red MicroVU error even using 3540, but it is a much rarer occurance than the later revisions which break alot.
romulux_...
Aah, I have a question.
I noticed that quite for awhile now (after pcsx2 0.9.7 release) savestates are not compatible at all between revisions.
So if I try to load a savestate using a new version of the emulator, it simply doesn't load at all. Is this suppose to happen, or is it happening only to me ?
refraction
Well r3541 doesnt even touch the main branch and r3542 only effects developer builds, not release builds. I would suggest you try doing a complete rebuild.
romulux_...
hmmz weird, cos I've tested 3550 and 3555 and got me the same behaviour. I admit it is a bit weird, and 3541 and 3542 did look like nothing significant happened.
Ok I'll try to sort things out to see what is going on.
Btw, what about my question regarding the uncertainty via the savestates system ?
Thanks for everything!
romulux_...
Ok, I did the rebuild, and the game works fine with r3574, but the only thing I have to state between this revision and r3540, is that this one seems slower (around 6% slower i think).
ramapcsx2
Savestates are a snapshot of the ps2 virtual machine AND a ton of PCSX2 state variables.
If we change anything in the emulator, chances are that the new code doesn't accept the old variables. Some structures may have changed, an alignment may be different, anything like that.
So yea, expect savestates to break a lot when updating PCSX2.
(We do usually try to avoid that though, as it's an annoyance to us as well.)
lemuel2010
Great hack, but I noticed that the game's Heavy Iron (Incredibles, Spongebob-The Movie and other..) freezes after the menu. When fix or Hack?
refraction
Thanks for an unrelated post :) im sure they will get hacked at some point.

Revision 3575

Add an SPU2reset callback to SPU2 plugins, needed to put a stop to SPU2 sound
generation when resetting the PS2 VM. If a plugin doesn't implement it
directly, it automatically falls back on a manual soft reset using the SPU2's
builtin software Core0/1 register writes.
ramapcsx2
// manualized reset that writes core reset registers of the SPU2 plugin:
Man, this is clever. Didn't think of that :p
Jake.Stine
Yeah, probably no plugin needs to have its own, as that's probably 100% sufficient for stopping all sound output ... but I set it up so that they could, just in case.
andutrache
PS: You destroyed savestate compatibility :) .
Jake.Stine
I didn't. Saqib did with his IPU commit :p
gigaherz
Bah savestates are overrated, real men use normal saves!
andutrache
and i use both :P
novasaur
I agree with gigaherz. Definitely overrated.
I find savestates a form of cheating.
Much better to just play the games normally as they were originally intended to be.
andutrache
yes you play them as they are intended to be and when it hangs after a boss battle in a cutscene or something you will be like "FUUUUUUUUUUUUUUUUU!!!" plus i don't have time and don't like going thru puzzles 5 times from begining to end because i made a mistake XD
ramapcsx2
Right, savestates are awesome :D

Revision 3576

debian: minor change, nothing to see

Revision 3577

cmake: Upgrade cmake requierement to 2.8. (there is some incompatible change in
foreach arguments...)

Revision 3578

Savestate version increase.

Revision 3579

GSdx:
Move the dx11 check to GSInit, didn't like it only getting called on renderer
changes in the middle of emulation.
PCSX2:
Report the savestate version as hex if loading an incompatible state. Looks
better than -19793434481 :p
romulux_...
Nice touch with the savestates ;)), keep up the nice work!
Jake.Stine
I had meant for CheckDirectX to do the dx11 check along with DX9 checks, but testing for DX11 became so complicated that it outgrew the GSUtil class -- and then I forgot to add the DX11 calls back to CheckDirectX.

Revision 3580

zzogl-pg: I seem to have overlooked this somewhere along the way.

Revision 3581

zzogl-pg: More minor changes to the Liux config code.
arcum42
Liux? Linux.

Revision 3582

zzogl-pg: Reworked Linux configuration dialog.
arcum42
Basically, the "advanced" section with all the game hacks is its own separate dialog now, which you get to with an Advanced... button. I also removed the Capture avi checkbox and the Wireframe checkbox. The former wasn't coded under Linux, and neither are options you'd want to leave permanently on.
If I get capturing avis working under Linux, I may just have it be a keyboard option only...
arcum42
It looks like this:
http://img186.imageshack.us/img186/2730/screenshot072910173327.png
david.jennes
Offtopic: what background is that? :-P
arcum42
The whole background is covered by a transparent terminal window, so it's darker then normal, but it's a desktop picture I picked up off the web of Glenariff Forest Park in Ireland.
http://www.triskelle.eu/siamsa/wallpapers.php?pos=24
david.jennes
Yeah I realised that :-P Thx for the link though!

Revision 3583

SPU2null, PADNull, CDVDNull: remove useless gtk include

Revision 3584

IPU: Minor tweaks to casts and static vars while looking for potential GCC
issues.
Jake.Stine
As far as I can figure, the problem with IPU is probably related to a signed/unsigned typecast or a static variable that's being included into multiple modules that MSVC and GCC handles differently. In a worst case there's actually some real bug in the code that only manifests in gcc due to how it lays out the variables in memory or something.
GCC's codegen in debug builds is most likely 100% correct, so blaming GCC is probably not a good idea here.
arcum42
Yeah. My main trouble is that it's hard to debug code when you aren't that familiar with the details of what it's supposed to be doing in the first place.
For example, I'm not sure if get_intra_block and get_non_intra_block returning false is something that should be happening frequently or rarely...
I suspect I'll have to play with it in Windows for a while to see how it operates while it's working.
gigaherz
967 966 shift = g_BP.BP & 7;
I think you meant to remove that line too?
gigaherz
Oh nm you did in the next commit.

Revision 3585

Removed some unneeded code from our vu memory handlers (was an attempted
optimization from long ago, but VU memory isn't accessed directly from the EE
enough for it to matter).

Revision 3586

pcsx2: Fix macroblocking in Linux videos.
Jake.Stine
Well that's disturbing. I do that all the time -- pass pointers or handles to static vars to other modules.
something else has to be amiss here. By removing the static qualifier, you also cause the compiler to locate the data in a different location in the exe manifest. I'm more suspect that being the real cause.
Jake.Stine
Also, none of the niq/iq code has changed. I'm really sure this is just fixing things by chance. There's most likely some kind of memory corruption going on in the IPU, and this just re-arranged memory in a way that makes it non-effectual to program execution. The actual corruption may not even have anything to do with iq/niq
Jake.Stine
Ok, yea. There are dozens of places where IPU could be corrupting memory, because it uses raw pointers into macroblock structures and increments/decrements them freely without any sanity checking.
At this point I strongly suspect this bug is the *same* one causing the MSVC PCH bugs; except now its just lucked into popping up in Linux this time. Fortunately with coroutine removed it should be pretty trivial for me to implement complete pointer sanity checking for debug builds. That should pinpoint the corruption quickly.
arcum42
Yeah, you're probably right. I'd just spent a good while poking around at it, and was relieved to find something to fix it.
I found thus because I noticed that quant_matrix[i] was usually 0 in get_intra_block and get_non_intra_block, which was a pointer to a pointer to niq/iq.
So I figured something had to be wrong with niq and iq...

Revision 3587

IPU:
* Savestate mega-fix! Removed all the old direct pointer types from decoder_t,
which should fix the oddball random savestate crashes when IPU is active.
* Moved iq/niq into decoder_t.
* Moved all macroblocks into decoder_t (mb8, mb16, rgb16, rgb32).
* Turned decoder.stride into a constant, since IPU can only decode in strides
of 16 bytes only.
* Added sanity checking to the ipu0_fifo stuff (was formerly g_nIPU0Data, etc).
* Added some SSE moves to the Idct (very minor optimization). There's a
completely SSE from-ground-up implementation provided by newer versions of
libmpeg2 that we should probably look into later, rather than rolling our own.
azte...
seems good, we are getting close to 0.9.7?
Jake.Stine
This revision makes changes to the SSE yuv2rgb code, and I'm not sure if I did the GCC side correctly or not. >_<
wing...
I guess you're right, it won't build on linux:
[ 87%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/ps2/BiosTools.cpp.o
[ 88%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/ps2/GIFpath.cpp.o
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp: In function ‘void yuv2rgb_sse2()’:
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp:261: error: invalid cast from type ‘macroblock_8’ to type ‘u8*’
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp:262: error: invalid cast from type ‘macroblock_rgb32’ to type ‘u8*’
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/IPU/yuv2rgb.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2
trigunflame
+1 for libmpeg2 idea - but which one?
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/libmpeg2/libmpeg2/
http://svn.videolan.org/listing.php?repname=libmpeg2&path=/trunk/libmpeg2/
romulux_...
aztec, you're joking, you mean close to 0.9.8 maybe...
+1 Jake because I did seem to get some crashing after loading savestates in general
Jake.Stine
I'd rather use ffdshow's version, which uses compiler intrinsics:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/codecs/libmpeg2/libmpeg2/idct_sse2.c?revision=3115&view=markup
Don't expect huge speedups -- there are more serious issues hindering the performance of IPU still, but it should help a few %'s.
Jake.Stine
We only need the SSE2 version -- SSE2 and Reference are good enough for me (MMX is bleh, probably barely any faster than reference anyway). If someone gets one up and working, post it as a patch in the Issues section and we'll apply it.
trigunflame
Ah, I see. I recall reading this from their wiki a while back, too.
"Also note that libmpeg2 is faster when compiled with ICL. (+~15%)".
So, that is good to know if/when used ;)
Jake.Stine
Well if all of the mpeg2 lib is made 15% faster, it'll be roughly 2-4% overall increase in PCSX2 movie playback speed. In libMPEG, the video stream is a direct from-disk or from-memory feed. In PCSX2, the feed is a complicated bitstream being fed to it by the EE core, which itself often streams the data through the scratchpad via DMA. ;)

Revision 3588

Minor linux compilation fix to yuv2rgb_sse2
gregory....
Actually it does not fix the linux compilation.
Why can not use somethings like: static const macroblock_8* mb8 = &decoder.mb8 ?
There is another issue with asm constrain. There is 4 r constraint + eax, esi, edi which is too much for x86.
To have the same optimization than windows we can also use, c & d constraint for respectively yuv2rgb_temp and sse2_tableoffset.
wing...
Yeap, as Gregory said above, it didn't help:
[ 87%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/IPU/yuv2rgb.cpp.o
[ 87%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/ps2/BiosTools.cpp.o
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp: In function ‘void yuv2rgb_sse2()’:
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp:261: error: invalid cast from type ‘macroblock_8’ to type ‘u8*’
/home/wingnux/pcsx2-read-only/pcsx2/IPU/yuv2rgb.cpp:262: error: invalid cast from type ‘macroblock_rgb32’ to type ‘u8*’
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/IPU/yuv2rgb.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2
arcum42
Yeah, though the tough part isn't so much that error as the constraints problem...
gregory....
I have an idea. Actually eax it not really needed. We could check edi instead. Here a rough implementation of what I did to compile.
--- pcsx2.snapshot-3589.orig/pcsx2/IPU/yuv2rgb.cpp
+++ pcsx2.snapshot-3589/pcsx2/IPU/yuv2rgb.cpp
@@ -258,12 +258,11 @@
// offset to the middle of the sse2 table, so that we can use 1-byte address displacement
// to access all fields:
static const u8* sse2_tableoffset = ((u8*)&sse2_tables) + 64;
- static const u8* mb8 = (u8*)decoder.mb8;
- static u8* rgb32 = (u8*)decoder.rgb32;
+ static const macroblock_8* mb8 = &decoder.mb8;
+ static macroblock_rgb32* rgb32 = &decoder.rgb32;
__asm__ __volatile__ (
".intel_syntax noprefix\n"
- "mov eax, 1\n"
"xor esi, esi\n"
"xor edi, edi\n"
@@ -382,8 +381,8 @@
"add edi, 16\n"
- "neg eax\n"
- "jl onerow\n" // run twice
+ "cmp edi, 16\n" // in first run edi will be 16
+ "je onerow\n" // run twice
"add esi, 8\n"
"cmp esi, 64\n"
@@ -393,9 +392,9 @@
:[C_BIAS]"i"(C_BIAS), [Y_BIAS]"i"(Y_BIAS), [Y_MASK]"i"(Y_MASK),
[ROUND_1BIT]"i"(ROUND_1BIT), [Y_COEFF]"i"(Y_COEFF), [GCr_COEFF]"i"(GCr_COEFF),
[GCb_COEFF]"i"(GCb_COEFF), [RCr_COEFF]"i"(RCr_COEFF), [BCb_COEFF]"i"(BCb_COEFF),
- [yuv2rgb_temp]"r"(yuv2rgb_temp), [sse2_tables]"r"(sse2_tableoffset),
+ [yuv2rgb_temp]"c"(yuv2rgb_temp), [sse2_tables]"d"(sse2_tableoffset),
[mb8]"r"(mb8), [rgb32]"r"(rgb32)
- : "eax", "esi", "edi", "xmm0", "xmm1", "xmm2", "xmm3", "xmm4", "xmm5", "xmm6", "xmm7", "memory"
+ : "esi", "edi", "xmm0", "xmm1", "xmm2", "xmm3", "xmm4", "xmm5", "xmm6", "xmm7", "memory"
);
#else
# error Unsupported compiler
gregory....
Well, I think I have got a little issue somewhere. I have multiple black row line on video (seem like missing a block on 2).
arcum42
Yeah, I tried it and got the same result... :)
arcum42
In fact, that appears to be what it looks like if onerow never gets called.
gregory....
In fact my code only work the fist time ;)
gregory....
we need to jump for 16, 48, 80 etc...
gregory....
Ok with that it is far better :)
"test edi, 16\n" // in first run edi will be 16
"jnz onerow\n" // run twice
arcum42
Yeah, that looks good. Tried it on a few games (admittedly all by Gust...)
arcum42
I'd say to go ahead and commit it. The changes only affect Linux, anyways, and Jake can always change it later if he spots anything...
gregory....
Hum for the macroblock pointer.
Maybe Jake want to write this (note the &):
static const u8* mb8 = (u8*)&decoder.mb8
It compile, but I can not test it for the moment (I ssh my computer). At least I could commit the asm fix.
arcum42
I was using:
static const u8* mb8 = (u8*)&decoder.mb8;
static u8* rgb32 = (u8*)&decoder.rgb32;
when I was testing, and it seemed to work fine that way...
gregory....
Ok I will go for it then ;)

Revision 3589

cmake: Fix include path issue with gtk > 2.21.3 (ubuntu 10.10)
Note: last gtk version moves the gdk-pixbuf module into another place.
Technically cmake needs an update of the FINDGTK2 module. For the moment I add a
small work-around.

Revision 3590

IPU (linux):
* fix asm constraint. X86 have only 6 registers...
* move some pointer to ecx and edx like windows asm
Jake.Stine
Thanks for fixing all that up. I was afraid of the too-many-registers error; wasn't sure how to fix it so just hoped it wouldn't happen. :p
gregory....
Hopefully for us 16 is a nice number (1 bit). The others solutions will be to use memory access instead of register (performance impact). Note it can probably be done on windows side to save 1 register.

Revision 3591

IPU (linux): fix pointer variable. Linux compilation is now fine.
arcum42
Yep. Compiles, and videos look fine...
Jake.Stine
Yay, and no macroblocking?
I'm still worried that a bug persists somewhere; I'll keep poking around and adding debugging accessors to some of the arrays so that I can try and trap it one of these days.

Revision 3592

IPU (linux): mangle asm label. Need for inlining (if link time optimization
works one day).

Revision 3593

wxWidgets/MSW: Disable validators. We don't use 'em.

Revision 3594

Improved TlsVariable; going to be putting it to good use soon.

Revision 3595

Removed the IOPx2 cycle hack. It's been superseded by the Wait Cycle Detection
hack anyway.
Replaced the empty space with a (imo :p) more useful "Fast CDVD access" hack.
This one will enable users to cut loading times in most games but there
are some incompatibilities as well.
HDLoader compatibility lists will list incompatible games with a "needs MODE 1"
(or similar).
diego...
nice one there as always,and that hack indeed wasnt that good
romulux_...
Wasn't using the IOPx2 hack anyway so a replacement sounds better.
romulux_...
btw, I am not sure about this nor do I pretend to know, but, in SpeedhacksPanels.h at line 214 where it says:
m_check_fastCDVD->SetToolTip( pxE( ".Tooltip:Speedhacks:IOPx2",
shouldn't it be "fastCDVD" in stead of "IOPx2" ?
Sorry if I got confused...
ramapcsx2
You're right, thanks :)
(Will update in a bit)

Revision 3596

Changed the FastFormatString functions into nifty little classes that use TLS
for their buffer workspaces. Result: a fully concurrent printf with zero
malloc/free overhead. Use the pxsFmt macro for them -- which is a fully working
alternative to wxsFormat().
(pxsFmt has been applied to console/logging only for now. Will apply it to more
later, once the code is confirmed stable)
Jake.Stine
Anyone experiencing any problems here? If not, grand. I'll be committing the rest of the console log system changes soon! :)
arcum42
Haven't been able to check, actually. My ISP's acting up, so I'm semi-internet-less at the moment till I get a chance to hassle with their billing dept.
Of course, that didn't stop me from setting up my Nexus One as a wifi hot spot, and surfing the net on my eeePc, but I never got around to putting a wireless card in the computer I program on...
Jake.Stine
Ok. I would like a confirmation that this is compiling and running on Linux. I used some "clever" templating, and I may have left off a "typename" or something that the C++ standard requires for no explicable reason, etc. ;)
(I really need to re-setup my Linux VM for testing GCC)
gregory....
Actually it does not work ;)
common/include/Utilities/SafeArray.h:96,141,166,276,309
In constructor ‘SafeArray<T>::SafeArray(const wxChar*, T*, int)’:
error: ‘Exception’ has not been declared
From the previous TLS rev.
TlsVariable.inl: In destructor ‘virtual Threading::TlsVariable<T>::~TlsVariable()’:
TlsVariable.inl:114: error: ‘m_IsDisposed’ was not declared in this scope
TlsVariable.inl: In member function ‘Threading::TlsVariable<T>& Threading::TlsVariable<T>::operator=(const T&)’:
TlsVariable.inl:119: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
TlsVariable.inl:119: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator==(const T&) const’:
# next error appears each time GetRef is used
TlsVariable.inl:123: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator!=(const T&) const’:
Jake.Stine
For the first one need to turn SafeArray into an h/inl pair to fix it. Damn template dependencies.
The other I think I can fix more quickly.

Revision 3597

SPU2-X:
- Remove the DSound output module hardware buffer option which caused more harm
than good.
Also fixed that IOPx2 hack leftover.
fagoa...
let the dead rest in peace.

Revision 3598

IPU: Fixed bad IPU_CMD handling (using the same memory for read and write
values).
Unlikely to help any games, just spotted this when rama was debugging one with
an unrelated problem.
DanrleiS...
Friends, I look something. Gsdx 0.1.7, one of the most olders plugins, give speed up than gsdx newer versions in my computer, wait helping your.
romulux_...
Well the reasons behind the speed loss in the newer gsdx revisions might be that the complexity of the plugins today is much bigger than is was in the past (gsdx 0.1.7 for example) so you get a slower execution and less speed in emulation.
These new plugins however have greater compatibility, hacks to fix bad graphics and many more image quality settings/options than they ever did in the past.
On a side note, for the best experience with the gsdx plugin (and with pcsx2 in general I think) you should use Windows 7 (Faster than Vista) and a video card that uses directx 10 or directx 11, so if you're still using Win XP and an old video card with only dx9, than you are out of luck!
sudonim1
If we're really going to discuss this here then no, most enhancements should NOT make gsdx slower, but 0.1.7 is in the distant past long before gsdx was even in this repository so we're never going to know why it's faster for you, probably only in one specific game, and if we did know the information would almost certainly be useless for improving the speed today.

Revision 3599

SPU2-X: Communication error. We didn't want to remove the option; just make it
a little more clear that *most* of the time it sucks and shouldn't be enabled.
ramapcsx2
Whops :p

Revision 3600

Minor refactoring; doing this just to help minimize the changelog spam of the
next commit (not that it'll help much)

Revision 3601

Linux fix for TlsVariable.inl (I hope). SafeArray fix will have to come later.
jfre1...
I dont see a massive changelog here
Jake.Stine
I don't see a point to your comment
jfre1...
By Jake in previous commit: Minor refactoring; doing this just to help minimize the changelog spam of the
next commit (not that it'll help much)
Only reason I mentioned it

Revision 3602

Linux: Likely fix for gcc errors compiling SafeArray
wing...
No, it doesn't =/
Building CXX object common/src/Utilities/CMakeFiles/Utilities.dir/Console.cpp.o
In file included from /home/wingnux/pcsx2-read-only/common/src/Utilities/Console.cpp:18:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In destructor ‘virtual Threading::TlsVariable<T>::~TlsVariable()’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:109: error: ‘m_IsDisposed’ was not declared in this scope
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘Threading::TlsVariable<T>& Threading::TlsVariable<T>::operator=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:114: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:114: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator==(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:118: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator!=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:119: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator>(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:120: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator<(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:121: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator>=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:122: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator<=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:123: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘T Threading::TlsVariable<T>::operator+(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:125: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘T Threading::TlsVariable<T>::operator-(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:126: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘void Threading::TlsVariable<T>::operator+=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:128: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘void Threading::TlsVariable<T>::operator-=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:129: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
make[2]: *** [common/src/Utilities/CMakeFiles/Utilities.dir/Console.cpp.o] Error 1
make[1]: *** [common/src/Utilities/CMakeFiles/Utilities.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 4%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/jmp.cpp.o
[ 5%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/legacy.cpp.o
--
[ 7%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/x86emitter.cpp.o
Linking CXX static library libx86emitter.a
[ 7%] Built target x86emitter
make: *** [all] Error 2
Jake.Stine
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In destructor ‘virtual Threading::TlsVariable<T>::~TlsVariable()’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:109: error: ‘m_IsDisposed’ was not declared in this scope
... sigh. I have no earthly idea why GCC can't see the base class. And I won't have my virtual linux box installed and ready for a couple days most likely.

Revision 3603

Dreaded IPU bug FOUND and SQISHED! -- this is the bug that was corrupting
memory for all these years. ;)
Jake.Stine
Special thanks to saqib for making the IPU debuggable. As soon as the crash occured I was able to stacktrace and figure it out. :)
Also, this might fix some FMVs that don't like to play, since the readbits fifo wasn't being cleared properly. Not really sure on that since I'm not totally up on IPU internals; dunno how important that clearing of the buffer might be.
eliotfur
I thought it will fix videos in "The Bard's Tale" and "Baldur's Gate: Dark Alliance", but it didn't... Intros still hang after two seconds of playing...

Revision 3604

GCC/TlsVariable compile fix attempt #4: randomly throwing darts at members of
the C++ standards committee.
aavindraa
"randomly throwing darts at members of
the C++ standards committee"
LOL :P
wing...
Still no good. =(
[ 6%] Building CXX object 3rdparty/SoundTouch/CMakeFiles/pcsx2_SoundTouch.dir/sse_optimized.cpp.o
In file included from /home/wingnux/pcsx2-read-only/common/src/Utilities/Console.cpp:18:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In destructor ‘virtual Threading::TlsVariable<T>::~TlsVariable()’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:109: error: ‘m_IsDisposed’ was not declared in this scope
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘Threading::TlsVariable<T>& Threading::TlsVariable<T>::operator=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:114: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:114: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator==(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:118: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator!=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:119: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator>(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:120: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator<(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:121: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator>=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:122: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘bool Threading::TlsVariable<T>::operator<=(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:123: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘T Threading::TlsVariable<T>::operator+(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:125: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘T Threading::TlsVariable<T>::operator-(const T&) const’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:126: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘void Threading::TlsVariable<T>::operator+=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:128: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl: In member function ‘void Threading::TlsVariable<T>::operator-=(const T&)’:
/home/wingnux/pcsx2-read-only/common/include/Utilities/TlsVariable.inl:129: error: there are no arguments to ‘GetRef’ that depend on a template parameter, so a declaration of ‘GetRef’ must be available
make[2]: *** [common/src/Utilities/CMakeFiles/Utilities.dir/Console.cpp.o] Error 1
make[1]: *** [common/src/Utilities/CMakeFiles/Utilities.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 6%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/legacy_sse.cpp.o
Linking CXX static library libpcsx2_SoundTouch.a
--
[ 7%] Building CXX object common/src/x86emitter/CMakeFiles/x86emitter.dir/x86emitter.cpp.o
Linking CXX static library libx86emitter.a
[ 7%] Built target x86emitter
make: *** [all] Error 2
arcum42
Oh well; I know what's going on with my internet now, so hopefully I'll be back up soon. It depends whether I'm able to reactivate it when I get home or not.
Seems my apartment complex manager called to have internet disconnected from the apartment of someone who was moving, and gave them the wrong apartment number... :(
romulux_...
You would be so lucky arcum, that complex manager was feeling complexed and he played with your broadband - LOL for the second time on the page!
gregory....
Note: I saw that you remove (rev 3603) this previous added line "using BaseTlsVariable<T>::GetRef;". Is there a reason ? The line fix all getref error. The only remaining compilation error deals with m_IsDisposed.
arcum42
It's not all bad - they had to set me up with a new account and transfer everything to it, and it seems that I now have a lower monthly bill for monthly internet. (And, while I'll watch for it, I don't think I was charged any fees - they were pretty apologetic about the whole thing...)
And this comment was written with my main computer, so it's working now. (Which means I can stop abusing my Nexus One's wifi hotspot ability.)
arcum42
I got a few more errors then that, but r3605 should do it. Though I'd better check it in Windows...

Revision 3605

After 4 attempts, I suppose it's my turn...
gregory....
Good. It compiles fine but there are still some linking error at least in cmake.
arcum42
Odd. It seemed to link fine in codeblocks. Hmmm...
arcum42
Well, I've verified that it works in Windows. Now back to Linux to try building a different target...
gregory....
Note the Utilies library is fine. Only PCSX2 have some issues. Just for information:
CMakeFiles/pcsx2.dir/Elfheader.cpp.o: In function `ElfObject::ElfObject(wxString const&, IsoFile)':
Elfheader.cpp:(.text+0x1215): undefined reference to `SafeArray<unsigned char>::SafeArray(int, wchar_t const*)'
CMakeFiles/pcsx2.dir/Elfheader.cpp.o: In function `ElfObject::ElfObject(wxString const&, IsoFile)':
Elfheader.cpp:(.text+0x13d5): undefined reference to `SafeArray<unsigned char>::SafeArray(int, wchar_t const*)'
CMakeFiles/pcsx2.dir/Elfheader.cpp.o: In function `ElfObject::ElfObject(wxString const&, unsigned int)':
Elfheader.cpp:(.text+0x193f): undefined reference to `SafeArray<unsigned char>::SafeArray(int, wchar_t const*)'
CMakeFiles/pcsx2.dir/Elfheader.cpp.o: In function `ElfObject::ElfObject(wxString const&, unsigned int)':
Elfheader.cpp:(.text+0x19ff): undefined reference to `SafeArray<unsigned char>::SafeArray(int, wchar_t const*)'
CMakeFiles/pcsx2.dir/gui/AppCorePlugins.cpp.o: In function `SysExecEvent_SaveSinglePlugin::InvokeEvent()':
AppCorePlugins.cpp:(.text+0xd5b): undefined reference to `SafeArray<unsigned char>::SafeArray(wchar_t const*)'
CMakeFiles/pcsx2.dir/gui/SysState.cpp.o: In function `StateCopy_SaveToFile(wxString const&)':
SysState.cpp:(.text+0x113): undefined reference to `SafeArray<unsigned char>::SafeArray(wchar_t const*)'
CMakeFiles/pcsx2.dir/gui/SysState.cpp.o: In function `SysExecEvent_UnzipFromDisk::InvokeEvent()':
SysState.cpp:(.text._ZN26SysExecEvent_UnzipFromDisk11InvokeEventEv[SysExecEvent_UnzipFromDisk::InvokeEvent()]+0xa4): undefined reference to `SafeArray<unsigned char>::SafeArray(int, wchar_t const*)'
arcum42
Hmmm. I just built a dev build in Linux with cmake without errors. Maybe it needs a clean build?
gregory....
Hum. Well it is also possible that I have a bad flags or stupid patches. I need to recheck.
It is ok with a default build so I thinks the culprit is on my side. Need to dig more
ragnarok2040
I just built this revision and after a few tests, it complained that the GS plugin wasn't configured. Clicked OK, then set the plugin, and it turned out that every file in my PCSX2 folder in my home directory had disappeared. Scared the crap out of me so I reverted.
I was getting X Window system errors more frequently, too. I've been rarely, once a day or so, getting an error like that since revision 3582.
Jake.Stine
This fixes the m_IsDisposed error but interferes with the class's behavior. I really wish I understood why the C++ standard won't allow me to inherit from the parent class. The standard is so retarded.
Jake.Stine
http://gcc.gnu.org/onlinedocs/gcc/Name-lookup.html
"In get_i(), i is not used in a dependent context, so the compiler will look for a name declared at the enclosing namespace scope (which is the global scope here). It will not look into the base class, since that is dependent and you may declare specializations of Base even after declaring Derived, so the compiler can't really know what i would refer to. If there is no global variable i, then you will get an error message.
In order to make it clear that you want the member of the base class, you need to defer lookup until instantiation time, at which the base class is known. For this, you need to access i in a dependent context, by either using this->i (remember that this is of type Derived<T>*, so is obviously dependent), or using Base<T>::i. Alternatively, Base<T>::i might be brought into scope by a using-declaration."
gregory....
In my side, the bad linking are caused by some gcc optimization (not enabled by defaults) -fipa-cp and -finline-small-functions
There is also some cryptic warnings (if it can help finding issues):
common/include/Utilities/SafeArray.h: In member function ‘T* SafeArray<T>::_getPtr(uint) const [with T = char]’:
common/include/Utilities/SafeArray.h:115: instantiated from ‘T* SafeArray<T>::GetPtr(uint) [with T = char]’
common/include/Utilities/StringHelpers.h:157: instantiated from here
common/include/Utilities/SafeArray.h:81: warning: statement has no effect
Jake.Stine
Ok I can fix those.
gregory....
Jake, Arcum,
Looking at LTO visibility constrain (we need to add externally_visible attribute to plugins API), I found somethings interesting about C++ visibility. I do not expect any gains, but a better consistency between linux and windows. Is there any reasons (c++ exceptions issue perhaps!) why plugins do not alredy use it ?
* Here an extract of gcc 4.3 doc
-fvisibility=default|internal|hidden|protected
Set the default ELF image symbol visibility to the specified option---all symbols will be marked with this unless overridden within the code. Using this feature can very substantially improve
linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any
shared objects you distribute.
Despite the nomenclature, "default" always means public ie; available to be linked against from outside the shared object.
A superior solution made possible by this option to marking things hidden when the default is public is to make the default hidden and mark things public. This is the norm with DLL's on Windows and with -fvisibility=hidden and "__attribute__ ((visibility("default")))" instead of "__declspec(dllexport)" you get almost identical semantics with identical syntax. This is a great boon to those working with cross-platform projects.
extern declarations are not affected by -fvisibility, so a lot of code can be recompiled with -fvisibility=hidden with no modifications. However, this means that calls to extern functions with no explicit visibility will use the PLT, so it is more effective to use __attribute ((visibility)) and/or #pragma GCC visibility to tell the compiler which extern declarations should be treated as hidden.
Note that -fvisibility does affect C++ vague linkage entities. This means that, for instance, an exception class that will be thrown between DSOs must be explicitly marked with default visibility so that the type_info nodes will be unified between the DSOs.
An overview of these techniques, their benefits and how to use them is at <http://gcc.gnu.org/wiki/Visibility>.
Jake.Stine
We do not use C++ exceptions across exe->plugin calls, and explicitly forbid plugins from leaking exceptions back into PCSX2. This is because C++ exceptions between different versions of compilers and/or different CRTs are not compatible on Windows.
So that part shouldn't be a concern.

Revision 3606

Yay! TlsVariable fixed properly. >_<
Jake.Stine
Should have Google'd the GCC error sooner; that's usually what I do when I run into pandemic C++ standards headaches like this one. Will add "try some random this->stuff when templates don't compile in GCC" to my list.
For what its worth, here is my list:
* Add 'typename' to typedefs and other stuff sporting <>'s
* Add 'class' to typedefs and other stuff sporting <>'s
* Add full qualifiers, like MyDumbClass<T>::funcname (Which would have also fixed this)
* Add "using MyFullyQualifiedClass<T>::funcname;" to classes even when it seems plainly obvious it shouldn't be needed.
* Extract most or all contents of a template class into an inl file (for header file circular dependencies)
Note that ALL of these annoyances, and several more header file conflicts and circular dependencies, have to do with C++ standard calling for looking up variable names while parsing templates, instead of just doing all lookups (note that there is absolutely *no* objective advantage to doing so).
I really think that the C++ Standards Committee is secretly a bunch of java, python, and ruby lovers who are trying to kill C++ and force us all to another language.
gregory....
Cool.
For my link error, I maybe found the solution: add an include "SafeArray.inl" in some cpp file. What do you thinks ?
Index: pcsx2.snapshot-3606/pcsx2/Elfheader.cpp
===================================================================
--- pcsx2.snapshot-3606.orig/pcsx2/Elfheader.cpp
+++ pcsx2.snapshot-3606/pcsx2/Elfheader.cpp
@@ -18,6 +18,7 @@
#include "GS.h" // for sending game crc to mtgs
#include "Elfheader.h"
+#include "SafeArray.inl"
using namespace std;
Index: pcsx2.snapshot-3606/pcsx2/gui/SysState.cpp
===================================================================
--- pcsx2.snapshot-3606.orig/pcsx2/gui/SysState.cpp
+++ pcsx2.snapshot-3606/pcsx2/gui/SysState.cpp
@@ -21,6 +21,8 @@
#include "ZipTools/ThreadedZipTools.h"
+#include "SafeArray.inl"
+
// Used to hold the current state backup (fullcopy of PS2 memory and plugin states).
//static VmStateBuffer state_buffer( L"Public Savestate Buffer" );
Index: pcsx2.snapshot-3606/pcsx2/gui/AppCorePlugins.cpp
===================================================================
--- pcsx2.snapshot-3606.orig/pcsx2/gui/AppCorePlugins.cpp
+++ pcsx2.snapshot-3606/pcsx2/gui/AppCorePlugins.cpp
@@ -24,6 +24,7 @@
#include "Plugins.h"
#include "GS.h"
#include "AppConfig.h"
+#include "SafeArray.inl"
using namespace Threading;
Jake.Stine
Yeah that works too. It won't conflict with the fix I did, which is useful because it reduces dependency on the inl in general. I can't really decide which is better. C++ is fun, 6 ways to do 1 thing, none of them especially obvious as being better or worse. So throw a dart at a dart board and pick one, is what I usually end up doing.
We could include the inl into our PrecompiledHeader.h file or something, but eh... I don't use the array enough to merit it (and most uses are for u8/char buffers).
gregory....
Well I prefer your fix. It keeps common include into the common library, which I found cleaner.

Revision 3607

More GCC fixes for SafeArray (changes to the BoundsCheck macro fix some
meaningless warnings, not really important otherwise).

Revision 3608

GSdx: bugfix for corrupted titlebar info, and possible crashes, when running
from the legacy gui. (fixes Issue 826 )
thiago_...
you're amazing man ... gsdx returned to work in legacy versions no problems... thank you very much
SNP_Tira...
People still use the legacy GUI?
ramapcsx2
Yea, in some games it's like 5% faster. Also has a lot more surprise crashes :p
Syst3mSh0ck
GSdx fixes are always a good thing! Rama, perhaps you could look into the Hardware Mode graphics corruption in Metal Gear Solid 3 that happens during the intro, that being the computer screens and snakes goggles.
ramapcsx2
Texture cache messups. I long gave up on those.
A fix is planned but it'll take (lots of) time until that's ready.
HarisKur...
@Syst3mSh0ck
I have the same issues in Metal Gear Solid 3, there is also a similar corruption during game play when in 1st person mode in the starting areas of the jungle, just throwing that out there for the devs :]

Revision 3609

Introducing a mostly revamped Tracelog and Console log system. Various console
log sources can now be toggled on/off on the fly, allowing end users to enable
more verbose logging when they encounter problems. Both console and trace
sources can be given automatic prefixing.
DevNotes: DevCon logs are now available in *Release* builds as well as Devel
builds, and can be enabled from the Console window's "Sources" menu. They are
disabled by default in Release builds, and are always enabled regardless of the
ini setting in devel builds. Debug logs are still strictly available in debug
builds only.
Jake.Stine
In other news, PCSX2 works from Suse linux and KDE. Well everything except the GS plugin, since they're a pain to get compiling in general, and I don't think I can test it still via VMware Player.
gregory....
Just in case you did not already know VirtualBox (http://www.virtualbox.org/). It is a GPL project developped by a startup (then bought by Sun, then bought by Oracle) similar to Vmware workstation or player.
After installing some guest addition (linux driver actually), it is possible to have some 3D accelerated by the host. Note it maybe support the vmware HDD format so no need to re-install a virtual machine.
arcum42
Yeah, I've gotten where I like VirtualBox better then Vmware Player, personally, though it's mainly a matter of preference.
Of course, now that Oracle's taken it over, I worry about its future...
Jake.Stine
I forgot to add that I introduced a dark theme console color here.
Jake.Stine
I also fixed a whole slew of cmake warnings while I was at it. :D
ramapcsx2
Now we'll have a bit more responsibility which log to choose, but okay :p
ramapcsx2
I wonder if we can't include optional IOP stdout as well. It's very useful to have..

Revision 3610

GSnull: Work on the GifTransfer functions, to bring them up to date, and
straighten them out. Now enabled by default.
arcum42
Not tested in Windows, and I still have more work to do on it, though I'm not sure if that'll be tonight or not.
refraction
if ((conf.path3) && (index == 2) && path->eop) gs.nPath3Hack = 1;
any reason that went back in? its obsolete code now
arcum42
Mainly since I'd already done most of the cleanup work on ZZOgl, so I copied it from there and locally adapted it. And I never quite got around to deleting that from ZZOgl, it came over with it.
I'll probably get rid of it later.
This does eliminate a crash that used to happen if you enabled the GifTransfer code in GSnull, though.
I was mainly doing this because I was thinking about getting the register code set up in GSnull as well...
arcum42
I'd also been thinking about going in and removing any obsolete GifTransfer code, breaking backwards compatibility for the plugin, but thought I'd save that for a later pass.

Revision 3611

Spu2null, padnull, gsnull, CDVDnull, onepad, spu2x:
Add 2 attributes to the interfaces functions
- externally_visible: avoid gcc to remove the function when lto is enabled
- visibility("default"): default == public... Allow to hide all others symbols:
see http://gcc.gnu.org/wiki/Visibility for details
onepad:
* Remove __cplusplus define, everythings is in C
* define 2 interfaces functions with EXPORT_C_ instead of CALLBACK.
cmake:
* add recent added .h files
* add fvisibility optimization. Plugins size was reduced of ~10% much more than
expected :)

Revision 3612

USBnull, CDVDiso, dev9null and FWnull: Same jobs as previous rev.
Note: zzogl is the only left (well zero plugins also) but I will wait that we
port CALLBACK to EXPORT_C_

Revision 3613

ReorderingMTGS: Posting preliminary DMAC re-implementation (mostly comments and
code outlines at this point).
ramapcsx2
Awesome indeed. This looks very promising :)
refraction
in the new dmac, do you really mean to check vif0 str for sif2? :P
looks tidy tho ;)
Syst3mSh0ck
Nice clean layout, and well received change, the DMAC rewrite has been a long time coming! Good luck :)

Revision 3614

GSnull: Fix compilation errors in Win32 and Debug builds.
arcum42
Thanks. I was planning to check in Windows to see if it built, but I ended up going to sleep...

Revision 3615

ReorderingMTGS: Sync'd with trunk.
gb2985
I know this isn't were I'm supposed to post this but I don't know how long it will be before you look at the thread so I will just mention this here.
While playing Summoner 2 PCSX2 hangs at certain points. The things I noted from the console on r3608 was this:
GIFTAG error, size exceeded VU memory size 3ff (Options type menus)
microVU1 Warning: Branch in Branch delay slot! [0458] (all 3: hero dialogue)
microVU1 Warning: Branch in Branch delay slot! [04d0]
microVU1 Warning: Branch, Branch, Branch! [0218]
Is there anyone actually working on these 2 problems? At the very least the branch needs to be fixed for it to be playable.
ramapcsx2
Can you provide a game dump that gets me to this error?
If so, I can look at it.
gb2985
Okay, I'll do so in a minute, just gotta update to this release first.
gb2985
Just in case you need it here are my system specs from speccy:
https://docs.google.com/leaf?id=0B7XEqelNSvg9YjViY2E0NzEtMGZhYS00NTgwLWJmOTYtYTczMDRjMWI5NDc5&hl=en_GB
Not that I believe this has anything to do with the 2 problems.
ramapcsx2
Okay, I got your dumps and savestates.
Can't see any issue with the game here and the savestates won't load.
Which pcsx2 revision did you use?
gb2985
Savestates + logs came from r3608 as pointed out in the 1st comment and dumps came from r3615 since that was the latest available however in terms of the bugs themselves the release doesn't matter. In terms of the menus the 0.9.2 release apparently is able to produce the screen (albeit ugly) but not the highlight.
ramapcsx2
Hmk, what is "the screen (albeit ugly)" and what is "the highlight".
Can I see some screenshot please or a full error description.
So far all I got was going ingame just fine, beating some enemies just fine and entering the menu, also just fine.
I really don't see an issue with this game.
gb2985
Screenshot are at http://forums.pcsx2.net/Thread-Bug-Report-Summoner-2-PAL-E-SLES-51141 (It's how I know it's ugly) and it was just the hero dialogue and the option type menus that causes problems. If you're not getting problems with these then could you tell me what version and cfg you're using please?
ramapcsx2
Okay, let's continue this in the forum post.. :p

Revision 3616

Enable IOP stdout and Kprintf HLE intercepts in Release mode builds.
ramapcsx2
Ty :)

Revision 3617

GSnull: Add preliminary register code.
arcum42
Real register code would be more convoluted then this, but it sketches the basics out.

Revision 3618

Apply the same visibility flags from CMake to CodeBlocks. GSnull: Remove some
legacy gif code. Hook up the register code.
arcum42
Hope everything went in properly. I had some issues committing this revision...
shadowladyngemu
1>GS.def : error LNK2001: unresolved external symbol GSgifTransfer1
arcum42
Ah. If Windows insists, I suppose I can add it back in...

Revision 3619

GSnull: Add a function back in.

Revision 3620

IOP: Deleted micro-optimisation in what's already not a speed critical
recompiler which was corrupting code in experimental modifications.

Revision 3621

Bugfix: EE and IOP consoles were piping through printf formatting, causing
occasional crashes (introduced in r3609)

Revision 3622

Pseudonym found missing register allocation flushes in our recompiler loads /
stores.
This is fixed now.
(Devil May Cry 1 fixed)
Ragha...
From when is this comment? :"// NOTE: Code incomplete. I'll fix/finish it soon. --air"
gigaherz
When they feel like doing it. Not earlier.
Syst3mSh0ck
Good job, now I can play some DMC :)

Revision 3623

GSdx:
- Few more CRCs

Revision 3624

Refactoring:
* Added __fi and __ri, which are abbreviations for __forceinline and
__releaseinline.
* Added some static qualifiers to functions in mVU, MMI ops, and others where
appropriate.
* Removed some unnecessary __fastcall qualifiers (since GCC gets funny
sometimes when you combine __fastcall and inlining).
* Made _1mb, _16mb, _1gb values common to all emulation code (moved from
newVif/mvu to Common.h) -- they're useful! :)
Jake.Stine
We were getting a lot of lengthy __forceinline crap everywhere, so I figured some compactness was in order. I opted for __fi over _f because its still a #define (and they're prone to namespace pollution), and its easier/more reliable for doing global searches than _f -- while still being considerably more compact than __forceinline.
( also changed more __fi's to __ri's, which just helps improv the stacktrace info when using Devel builds for debugging.

Revision 3625

'static' and 'extern' do not mix.
arcum42
Both of these functions are called in microVU_Branch.inl...

Revision 3626

PCSX2/EEcore:
* Now using SSE for all hardware register reads and writes (mainly MFIFO stuff)
[don't expect a speedup, really -- its more of a code simplification in this
case].
* [refactoring] Changed the EE Memory (vtlb) to use the u128 type instead of
u64 for the 128-bit loads/stores (see mem128_t typedef)
JohnnyKi...
Do you smell what the rock is cooking ? :D
Jake.Stine
I dunno. Do you hear what the water bucket is baking?
cottonvibes
Do you feel, what the tree is toasting?
ramapcsx2
Something smells burned.
The updated code works though, so must be something else :p
gregory....
Well, just for information that break the linux build. Note it is maybe related to my cmake change.
pcsx2/VU0.cpp:91: error: cannot bind packed field ‘VU0.VURegs::VF[((cpuRegs.cpuRegisters::code >> 16) & 31u)].VECTOR::UD’ to ‘u64 (&)[2]’
arcum42
It gets that error on codeblocks, too, so it's not the cmake changes.
romulux_...
GJ. I smell some microwaved crackers coming from the jewelry store :))
gregory....
Here a gcc bug report (on older versions) but seems similiar stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
arcum42
I'll let Jake decide what he wants to do with this one. I managed to get it to compile with the following, though:
Index: pcsx2/VU.h
===================================================================
--- pcsx2/VU.h (revision 3629)
+++ pcsx2/VU.h (working copy)
@@ -58,6 +58,7 @@
float F[4];
+ u128 UX;
u64 UD[2]; //128 bits
s64 SD[2];
u32 UL[4];
Index: pcsx2/VU0.cpp
===================================================================
--- pcsx2/VU0.cpp (revision 3629)
+++ pcsx2/VU0.cpp (working copy)
@@ -88,7 +88,7 @@
void LQC2() {
u32 addr = cpuRegs.GPR.r[_Rs_].UL[0] + (s16)cpuRegs.code;
if (_Ft_) {
- memRead128(addr, VU0.VF[_Ft_].UD);
+ memRead128(addr, &VU0.VF[_Ft_].UX);
} else {
u64 val[2];
memRead128(addr, val);

Revision 3627

zzogl copyright:
* common.h is mostly based on multiple file in ffmpeg. So apply the same licence
as the original files
* Others zerofrog's file: add a note on the missing copyright notice.

Revision 3628

cmake:
* move machine optimization in the global setup. In same time use i686 instead
of i486
* Also build the debug with fvisibility=hidden No reason to use it only on
devel. (actually same as codeblock)

Revision 3629

Added a minor hack to MFIFO interrupt timing. Fixes FF7 DoC.
Long interrupt delays are always bad, no matter how true it is to actual console
behavior.
(Issue with running code in block slices.)
Also removed outdated hacks for Devil May Cry PAL :p
ramapcsx2
Oh, and 0 cycle interrupts are even worse! ;)
konaj...
confirmed working, nice fix I have been waiting for a ff7doc fix for awhile
good work :)
refraction
Ahh interesting.
BTW the 0 cycles was in there as the MFIFO flushes as the SPR sends it, so SPR was kind of controlling the interrupt timing, but yes 0 isnt good ;p
will look in to this tho, i suspect the MFIFO Empty interrupts are being timed badly, causing it to get confused.
refraction
bah looks like i missed a load of stuff with this
CPU_INT(DMAC_MFIFO_VIF, vif1ch->qwc * BIAS); in the second incarnation was wrong neway (as was the first really)
first one should have just been the instant interrupt. the second one should have been
CPU_INT(DMAC_MFIFO_VIF, gVifCycles);
as it may have only transferred 1qwc of 3048 or so, but we'd end up waiting 6094 cycles, instead of 2 >.<
ramapcsx2
Best way to check this is running a few games with a printf in place.
If it says unreasonable amounts of cycles, something's odd :p
refraction
I can bet FF7 is one of those :P
I know what happened. It's remenance from the days i had the dma's reversed so the wait was first, then the data was transferred, only problem is it didnt really help much ;p it just didnt get reverted correctly there when i removed it.

Revision 3630

newdmac: sync with trunk. [actual purpose of the branch has changed, but
renaming it in svn could be problematic for history/merging, so I'm holding off;
but from now on its the newdmac]
Syst3mSh0ck
Well done :)

Revision 3631

newdmac: progress is made in many small increments (well unless you're really
effing awesome, which I'm not)
JohnnyKi...
I smell something.
refraction
don't start that again ;p
ramapcsx2
A ton of ground work here again. This'll become the most feature complete and reproducible dmac PCSX2 ever had.
(Yeah, I know it's the first one.. :p )
JohnnyKi...
One more question......(sorry for my bad english) Will the pcsx2 get on a stage of PERFECT Emulation ? Doesn`t matter when , just it will ?
wing...
Compilation is broken on linux:
[ 62%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/vtlb.cpp.o
[ 62%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/VU0.cpp.o
/home/wingnux/pcsx2-read-only/pcsx2/VU0.cpp: In function ‘void R5900::Interpreter::OpcodeImpl::LQC2()’:
/home/wingnux/pcsx2-read-only/pcsx2/VU0.cpp:91: error: cannot bind packed field ‘VU0.VURegs::VF[((cpuRegs.cpuRegisters::code >> 16) & 31u)].VECTOR::UD’ to ‘u64 (&)[2]’
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/VU0.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2
gregory....
Wingnux, yes we know that linux have a little issue ;)
Look at comment in r3626 to find a basic patch (no guarantee of working).
refraction
eusebiu: I don't think we will ever reach "perfect" emulation, fluke or close emulation is possible :P But some things are too undocumented, cycle rates vary too much and hardware differs too much from PC's to reproduce exact floating point calculations without a lot of work (which will probably make pcsx2 crawl)
JohnnyKi...
Well, after you make a very large compatibility list , like most of the games 90% or i dunno will pe playable , you will try to work on speedup ? :D
arcum42
Said patch was tested by playing a few minutes of ar tonelico 2, incidentally.

Revision 3632

VIF MFIFO:
- Proper fix for FF7 DoC.
- Changed the handlng of .inprogress to be cleared/set with ANDs and ORs (could
probably change this to a structure later), it could have interfered with MFIFO
functionality.
-Un-bool'd a function in MFIFO which really didnt need to be bool'd, causing
pointless passing around of data.
konaj...
this commit broke clock tower 3 ntsc, after you first start a new game and exit the door the screen turns black, didn't do this behavior in r3629
refraction
odd, didnt even think clock tower used mfifo... you 100% sure? i think i have a dump of clocktower 3, so ill check it :)
konaj...
pretty sure, unless the two revisions before this changed something, I personally tested with r3632 and r3629 and it lasted worked right in 3629 :)
refraction
can you try reverting vif1dma.cpp and see if it fixes it? if not, try reverting the changes around 225-230 in vif1_mfifo.cpp
refraction
Refraction is currently sitting in the living room saying "im confuuuuused" repeatedly.
case 1: //Transfer data
mfifo_VIF1chain();
DevCon.Warning("cycles %x", g_vifCycles);
//Sanity check! making sure we always have non-zero values
if(g_vifCycles == 0) g_vifCycles = 4;
CPU_INT(DMAC_MFIFO_VIF, g_vifCycles );
return;
works
case 1: //Transfer data
mfifo_VIF1chain();
//DevCon.Warning("cycles %x", g_vifCycles);
//Sanity check! making sure we always have non-zero values
if(g_vifCycles == 0) g_vifCycles = 4;
CPU_INT(DMAC_MFIFO_VIF, g_vifCycles );
return;
doesnt.
The difference? Yeh it baffled the crap out of me too, why it makes a difference i dont know
konaj...
tried the above change and it didn't help (but i didnt have the dev/verbose log enabled in the console so thats possibly why), also noticed this bug is random sometimes every once in awhile it will work normal (maybe what you saw),
anyways i reverted Vif1_MFIFO.cpp to the r1629 revision and it fixes it so definitely something in the mfifo file, ill try to narrow it down to the line if i can.
konaj...
case 1: //Transfer data
mfifo_VIF1chain();
//Sanity check! making sure we always have non-zero values
CPU_INT(DMAC_MFIFO_VIF, (g_vifCycles == 0 ? 4 : g_vifCycles) );
return;
changing it to
case 1: //Transfer data
mfifo_VIF1chain();
CPU_INT(DMAC_MFIFO_VIF, 1);
//Sanity check! making sure we always have non-zero values
// CPU_INT(DMAC_MFIFO_VIF, (g_vifCycles == 0 ? 4 : g_vifCycles) );
return;
seems to fix it
refraction
yeh it seems to just want "something" in there, i dont know if its a register flushing issue or what, but technically the code is sound, but freaky bugs are happening :P
ramapcsx2
That is register corruption, yea.
Must be needing an additional flush somewhere.
(Regarding the one devcon printf change)
refraction
Hmm its odd, it feels very like cyclevoodoo, but that game seems to do a lot of suspends, i wonder if im missing something..

Revision 3633

Missed a couple of bits :P
Small OPH/APATH clear which shouldn't have been there.

Revision 3634

Im sure this got in there by error back when the OPH stuff revert went on.
romulux_...
Two revisions in one minute, well that's something :P
Good work!
refraction
It's nothing drastic ;p just keep spotting bits i've been meaning to upload.
ramapcsx2
Good, the less of those the happier I am :D
If you meant my revert though, it's completely reverted to what it was before.
Even remember those :p
refraction
nope, it wasn't, cos I checked the code before it was taken out and those weren't there :P but they appeared when the revert was done. I'd taken them out locally, but forgot to commit it lol
ramapcsx2
Crap, I see what's up with that now.
These 2 lines were always commented but on my revert I uncommented them
thinking they were meant to be there..
My fault :p

Revision 3635

pcsx2: Get Linux compiling.
arcum42
It seems to work well enough, but I didn't want to risk some bizarre Visual C++ error, so I sectioned it off till this weekend when I have more time to actually check in Windows.
Also, Jake might want to either a) work around it another way, or b) use the new union members elsewhere in the code.
Either way, I didn't want to see the trunk sitting broken for too long, so...
wing...
Thanks for the workaround, everything seems fine now.

Revision 3636

Re-fix Def Jam Fight for NY.
romulux_...
Thanks Rama, I've been meaning to try this game out.
diego...
great work,now the game seems to work,but it have some other problems,look at my thread on the forums for more info http://forums.pcsx2.net/Thread-Bug-Report-Def-Jam-Fight-For-NY-PAL

Revision 3637

zzogl: update the size of the default advance panels. Avoid resizing every
times.

Revision 3638

Get rid of extraneous line breaks on the console output(Linux).
arcum42
The line breaks were already added before passing the strings to this function if they were needed.

Revision 3639

zzogl-pg: Work on GetRectMemAddress.
arcum42
I'll be interested to know if this breaks anything, since I changed a few things that didn't look right...

Revision 3640

[wiki]: add some note why PCSX2 is not compatible with amd64. Explain a little
virtual machine and co
gb2985
Just out of interest will a 64 bit version of PCSX2 be made after all the problems with the 32 bit version are fixed? I mean it would be great if there was a future possibility of potentially faster and smaller version of PCSX2.
gregory....
1/ There is no evidence that a 64bits port will be faster. Memory word are 2 times bigger, so 2 times slower to transfer and PCSX2 made lots of memory access. The only advantage of 64bits is additional registers.
2/ 64bits will be bigger (binary size) as every 64bits binary.
3/ To obtain a 64bits versions, you need to rewrite most of PCSX2. It will probably take multiples years before somethings usable. For the moment there is lots of issue in the emulation, better fix the 32bits versions. Ask the same question in 2 years ;)
gregory....
Additionnaly, it is only my opinion. It will be better to wait for APU (like AMD fusion). Well not the 2011 version but the 2013-15 version. Avoiding to transfer data from general memory to the video memory will save a lots of time and latency. Moreover advance vector units will help a lots to emulate efficiency the 2 VU (vector unit) of the PS2.
gb2985
I'm not worried about what hardware I have to wait for I just wanted to know if one might be made after the current x86 is finished. It's not like I'd be expecting x64 to be ready to try sooner than 2 years after the current x86 is finished let alone use.
gregory....
Honestly I do not know. It is too far in the futur to plan it. Maybe yes, maybe by others people (it is an open source project), maybe no (futur PC games will be better than the PS2 one).
The point on APU was : no one know how APU will be used. There is no point to plan a amd64 port if it need an APU port on years later.
ramapcsx2
-The 32bit "version" will most likely never be really finished.
-X64 to us is just another option we consider when thinking about
optimizations or maybe new angles to tackle a hard problem.
We certainly won't start rewriting all the recompilers and the emitter just because x64 exists ;)
gb2985
I hope the x86 version gets finished, it would a major disappointment if it didn't. As for x64 (or future x128 or something), it would be nice but as long as one version is finished with no issues then I'm happy. Anyways it's nice to know that x64 might be considered at a later date :)
sunnydra...
/flame
C++
if (maxvarsize()<64bit_max)
define _u64=workaround_class_with*/&<<_ops() /* slow,or memread */
else define _u64=std_compiler_u64
Asm
directives by GNU GAS http://en.wikipedia.org/wiki/GNU_Assembler
Optimization
SSEPlus (and actually can solve size problem)
http://sseplus.sourceforge.net/fntable.html
SSE 2/3/sssE3/4a/4_1/4_2/5 have fallback to reference!! :)!
http://developer.amd.com/cpu/Libraries/SSEPlus/Pages/default.aspx#resources
end flame/
gigaherz
gb2985: There's no such thing as "finished" for a project like this.
Even some of the oldest emulators still have some issues no one has been able to fix, and we are talking about machines many times simpler than the ps2. It's no shame, some things are just not worth the trouble or too impractical. (Would you make a version of the emulator that runs at 1/100th of the current speed just so you can fix one small glitch? Because things like that DO happen.)
gb2985
I would make a hack though that fixes the glitch, that's what I mean when I say complete, it should at least be play every game without problems whether they are hacked or not.
gregory....
In emulation/simulation, you have 2 extremes. Accuracy vs Speed. The difference between the 2 in the quantities of informations. To run fast you must not emulate a maximum of things (for example timing & synchronization). The architecture is created to avoid computing most of the information as possible. The rules is : "computing somethings is slow, compute nothings is fast". Unfortunately some games need more info, sometimes a hack is good, others times PCSX2 architecture is too limited.
Toshiba/Sony have surely cycle accurate (= precision at clock cycle) model. But it takes severals days to emulate 1 second (yes only 60 frames)...
Emulation is a choice between several architecture which give you an accuracy/speed level. Somethings like (number come from my hat but it just to explain the whole idea) 100% games at very slow speed. Or 95% games at slow speed. Or 90% games at reasonable speed. Or 80% at full speed.
ramapcsx2
sunnydrake7:
Feel free to do all that, we'd certainly appreciate a dev willing to port and optimize to x64 ;)
arcum42
And if you want somewhat of an idea of the magnitude of changes that would be necessary, this might give you an idea:
https://code.google.com/p/pcsx2-playground/source/detail?r=542
sunnydra...
ramapcsx2:
i not touched Asm for ages:) and don't have any clue about PS2 IPU/GPU register/purpose/path scheme despite reading your trunk code for some time:)
I can try to work with someone more knowledgble in this area as second hand if someone can seriously decide to transform to multi arch code:)

Revision 3641

Fix a typo in the wait loop detection hack.

Revision 3642

GSdx:
Added Haunting Ground to the list of games that get their post processing
automatically removed.
The game still shows a badly blended fog but is otherwise nicely playable now.
Hacks are from an unknown coder. Thanks for figuring it out! ;)
azte...
haunting ground rules since it's a horror game. ;)
too bad graphics arent perfect yet.
congrats to unknown coder.
gigaherz
... why do ppl like horror games or movies? Getting scared on purpose... it's like being hurt on purpose, xcept I can understand ppl confusing pain with pleasure... not fear. /me shrugs
federico...
Yup ... HG deserves to be one of the best horror games ever made for PS2 and who has tried it knows exactly what i'm saying
Besides the squares above some candles or lights the game seems to be a bit overbrighted but surely it has nothing to be with the previous ingame look, keep up the good work coders :D
azte...
gigaherz - have fear on purpose is fun, just see rollercoasters. ;)
jfre1...
People have loved getting scared for centuries. Games are just the newest in the line of entertainment mediums that deliver it. Personally the Silent Hill games are my favorite of the survival horror series's.
federico...
This game deserves to be fully playable and 100% bug-free (just as what happened with SH and Fatal Frame games as well) :P

Revision 3643

Trace Logging:
* Cleaned up trace logging and switched from C++ initializers to C-style const
arrays. Kinda mixed on which I like better, but decided to go with the general
rule of thumb that a bit less C++ weirdness is probably a good thing.
* Removed __assume() feature from pxFail and pxFailDev, due to the likeliness
of unwanted/unexpected compiler behavior (MSVC only). To hint the compiler that
code should be unreachable, explicitly use pxAssume(false).
JohnnyKi...
I don`t know what this means , but i think its good

Revision 3644

Improved EE/VTLB memory management: Removes various psM/psR/psS/psH pointers and
replaces them with a single unified eeMem pointer. Members of eeMem correspond
to Main, Scratchpad, Hardware, etc. This simplifies the EE's memory allocation,
improves compiler optimization, gets rid of some macro mess, and allows
templated code to deduce the size of memory buffers automatically.
* Includes a minor tweak to DMAC.h - removed tDMA_TADR / tDMA_MADR / etc. and
replaced them with a single tDMAC_ADDR class.
eliotfur
Nice work... Jake adds some order to PCSX2 chaos...
wing...
Here we go again! :P
[ 62%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/vtlb.cpp.o
[ 62%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/VU0.cpp.o
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp: In function ‘void vtlb_ReassignHandler(vtlbHandler, mem8_t (*)(u32), mem16_t (*)(u32), mem32_t (*)(u32), void (*)(u32, mem64_t*), void (*)(u32, mem128_t*), void (*)(u32, mem8_t), void (*)(u32, mem16_t), void (*)(u32, mem32_t), void (*)(u32, const mem64_t*), void (*)(u32, const mem128_t*))’:
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:307: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:308: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:309: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:310: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:311: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:313: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:314: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:315: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:316: error: insufficient contextual information to determine type
/home/wingnux/pcsx2-read-only/pcsx2/vtlb.cpp:317: error: insufficient contextual information to determine type
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/vtlb.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2
Jake.Stine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35398
... great. a GCC bug. >_<

Revision 3645

Found and fixed the issue causing some FFX battles to hang since ~400 revs ago.
The same problem caused the hang in Phantasy Star 4 when pressing pause.
wing...
Great job! =)
curtis.d...
s/timing sensible/timing sensitive/ ?
andutrache
Nice !!! Keep up the good work :)
refraction
This probably kills Flatout 1 & 2 as well, ah well we will need to find another method of fixoring :(
Dhalai.L...
WTF is there a Phantasy Star 4 for the PS2 ??
ramapcsx2
refraction:
I have no doubt that these games can be fixed by changed interrupt timings (good old cycle voodoo).
I'll have to review the current cycles again anyway since Ecco the Dolphin is also broken since that first time it got changed :/
ramapcsx2
Hmm, wait though before doing anything!
I found another fix that could work :p

Revision 3646

GCC/Linux compilation fix for VTLB code modifications made earlier. These
thanks to two apparently separate bugs, one in GCC 4.0-4.4 and another related
one in 4.5. Sigh.
Ragha...
Yes you really shouldn't template that code, it would be bitch to convert into x64 reliably. Imagine all these different bugs in x64 version of GCC.

Revision 3647

Ok the last fix for GCC exploited a bug in MSVC's handling of taking the address
of templated functions (one I've run into before). So I gave up and reverted to
non-template code.
wing...
"[ 99%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/ZipTools/thread_gzip.cpp.o
In file included from /home/wingnux/pcsx2-read-only/pcsx2/x86/microVU.h:241,
from /home/wingnux/pcsx2-read-only/pcsx2/x86/microVU.cpp:20:
/home/wingnux/pcsx2-read-only/pcsx2/x86/microVU_Lower.inl: In function ‘void T.3231(int)’:
/home/wingnux/pcsx2-read-only/pcsx2/x86/microVU_Lower.inl:719: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/x86/microVU.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2"
gcc version 4.4.5 20100813 (Linaro prerelease) [release 2010.08-0] (Ubuntu/Linaro 4.4.4-8ubuntu2)
Jake.Stine
I'd recommend upgrading or downgrading your GCC. I can't fix GCC segmentation faults on code that hasn't been altered; especially if the bug is specific to 4.4.5 (being a pre-release and all).
wing...
It works fine now, apparently it didn't like the -O3 optimization setting.
"export CFLAGS="-march=amdfam10 -O3 -pipe"
"export CXXFLAGS="${CFLAGS}"
Thank you, Jake! =)
Ragha...
Great. Spaghetti code makes porting easier.
Re:wingnux
It's a common knowledge -O3 flag optimizes out critical parts of PCSX2. It should be written in the wiki.
arcum42
Thanks for taking care of the Linux side of things. I hadn't actually had a moment to look at the issue yet, and since you've already taken care of it, I won't have to...

Revision 3648

microVU:
* Removed a DevCon from one of the mVU dispatchers and replaced it with an
assertion (minor speedup for Release builds).
* minor refactoring, encouraging mVU toward using class members and away from
using quite so many macros.
Jake.Stine
the devcon was only a hindrance since I did some new logging features a couple weeks ago.
cottonvibes
hmm i've been wanting to get rid of a lot of mVU's overuse of macros as well.
i don't really like the idea of too much class member functions though, especially because i liked having the main microVU struct as POD.
i guess the ~8 small functions you added aren't too bad to add into microVU{}.
the incPC macro is used a lot though, so i think it should stay as a small macro instead of the member-function.
p.s. I thought the DevCon stuff was already optimized out on release builds?
cottonvibes
oh and the thing i said about incPC, i meant the macro should be kept, but it can still be implemented as the advancePC() member-function.
Jake.Stine
@cotton: It's still a POD. It only becomes non-POD if it uses the 'class' keyword, or inherits from another base class. Having struct/class members does not change its storage type. :)
(and in fact I think 'class' still remains POD if it uses class and a single 'public:' directive for all non-function members; but I'm not sure).
What I'd like to do is eventually have a lot of mVU code in the microVU struct, and as a result *most* of the "mVU->" stuff will be gone (and thus most of the macros related to passing and de-referencing the mVU parameter). In VS2008 anyway, compiler codegen will probably be a little less efficient than the macros overall since it has class optimization problems. But the VS2010 codegen will almost certainly be better in class form, and the same in a worst case.
DevCon stuff is now enabled in dev and release builds, as of a logging commit a few weeks ago. Log window->Sources->Verbose (or something like that). Almost all the devcon stuff is useful in the event pcsx2 has emulation bugs or ui bugs, so its nice to be able to ask users to flip the verbose logging on and provide that log instead. And since almost all the DevCons were in places where it didn't matter for performance anyway, it was fine perf-wise (except for this one mVU case and maybe a couple outhers if I spot any).
cottonvibes
Okay i read up on POD, i thought it also included "no member functions" as a rule; but it just applies to virtual member functions.
class and structs are the same in c++, just class defaults to private; so yeah classes can still be POD.
in my nes emulator i went with the class-approach and made like everything class member functions. it wasn't a good idea as it sucks if you ever need function pointers, passing functions as parameters, or calling functions from the rec.
you also need to have all the member functions have their prototypes unless you define it in the class.
so i don't think its a good idea for mVU.
since passing the struct pointer to a function is defined by specified calling conventions, i prefer that better.
as mVU is now, pretty much every function passes mVU as a parameter; if the class member approach is used, then half of mVU will end up using class member functions, and the other half passing structs to functions (because a lot of code is used in function pointer tables like the opcodes, or called from the recs).
so that doesn't work out well imo, better to just have it all the same.
and yes you can have function pointers to class member functions, but the format isn't nice to work with.
Jake.Stine
There are only a few mVU functions called from the recs, and half of them are already pass-through functions to templated functions. Changing them to be pass-through functions to class members wouldn't be any different.
C++ member function pointers are a bit terse when used raw, but clever use of typedef can make them pretty painless. Besides that, the tables can be replaced with inline switch() dispatchers -- which end up significantly faster than nested tables. So no function pointers would be needed anyway if I ended up going that route.

Revision 3649

GSdx: Minor optimization and some code simplifications relating to
VertexKick/DrawingKick and the Packed register handlers. I also added
preliminary work for a switch-based packed register dispatcher (WIP, doesn't
support frameskipping yet).
eliotfur
Nice to see changes on the GSDX side...
zantezuken
I thought you nevar gonna touch teh GSdx voodoo code mess :P
gabest11
// I assume this was some sort of debugging code? Why intercept and perform
// special handling for the first three entries in the table, and then do
// a LUT for the rest?
Those were the most frequently called entries and that way they are inlined instead of going through the jump table.
Do you check the generated asm?
VertexKick, as it was, was also very optimized to only use registers and move minimal data.
Jake.Stine
>> Those were the most frequently called entries and that way they are inlined instead of going through the jump table.
Fair enough. As you noticed, I think they should all be inlined anyway. That way you wouldn't be causing penalties to the other 13 entries by forcing them to fall through a switch table. All the win of inlining without any loss on the less-called cases (this would be especially true with PGO'd builds, since PGO is really good about auto-ordering switch dispatchers for us based on call patterns).
Jake.Stine
>> Those were the most frequently called entries and that way they are inlined instead of going through the jump table.
Fair enough. As you noticed, I think they should all be inlined anyway. That way you wouldn't be causing penalties to the other 13 entries by forcing them to fall through a switch table. All the win of inlining without any loss on the less-called cases (this would be especially true with PGO'd builds, since PGO is really good about auto-ordering switch dispatchers for us based on call patterns).

Revision 3650

GregMiscellaneous: Create a branches to done some experimentations wihtout
breaking the trunk. (based on rev3649)
gregory....
Note: people are free to commit some stuff or too provide feadback.

Revision 3651

GregMiscellaneous:
* Buffer overflow (32bits unicode)
* Improve asm mem_cpy qwc (little faster)
Jake.Stine
Oh, missing sizeof()'s. Those should be fixed immediately anyway.
gregory....
Yes, I was not sure that others place need some fix. Better to fix all in one pass instead of waiting a crash ^^

Revision 3652

Bugfix for string formatting on some non-MSW platforms.

Revision 3653

GregMiscellaneous: Try to remove blur from some games. Gets the code from GSdx.
note: it is not working for the moment.
Zeydl...
You forget to negate fbm. GSDX and ZZogl bitmask are differ here a little.
gregory....
Arg, I'm stupid. I will try that. Thanks
arcum42
The enum GS_PSM is actually the same as PSM_value, which is already in GS.h, just with slightly different names...
gregory....
Yes I saw. I convert some name first time. Then I do a copy past of the shared stuff... It was just faster the 2nd time to just copy everythings :). It will really need a big clean later.
I'm currently testing the Zeydlitz implementation of shared bits. (me I just did a copy-past like a barbarian ^^)
gregory....
Zeydlitz, I am looking at your implementation and I think there is somethings wrong.
The condition :
(((spb ^ dpb) | ( 1 << (tpsm & 0x1f))) == 0) is always wrongs. "1 << (tpsm & 0x1f)" can not be 0 !
gregory....
Found an others issue. Is missed a '!' Now I can go to sleep ;)
if ( !PSMT_HAS_SHARED_BITS (fpsm, tpsm) ) {
return (((spb ^ dpb)) == 0);
}
else
return false;

Revision 3654

CDVDlinuz:
* move content of version.h into CDVDlinuz.h (avoid a conflict with version.h
located in /usr/include/alsa)
* allow cmake to build it.
wing...
Thanks, gregory!
gregory....
Well, it did not test it...
gregory....
By any chance, can you test it with gcc 4.5
4.4 is ok. With 4.6 snapshot I have got ICE (compiler crash).
Thanks
wing...
I don't have gcc 4.5, my installed version is gcc version 4.4.5 20100813 (Linaro prerelease) [release 2010.08-0] (Ubuntu/Linaro 4.4.4-8ubuntu2)
gregory....
Ok, no problem I was thinking that last ubuntu have 4.5.1, nevermind.
I really need to clean my system (4.6 gcc is install as 4.5 binary & package... I was not clever this day...)

Revision 3655

GregMiscellaneous:
* Fix some parameter
* Use some functions created by Zeydlitz to reduce the code.
Current status: blur effect is removed in FFX with UserHacks_SkipDraw=1 and
various random crashes ;)

Revision 3656

GregMiscellaneous: Forget to clean one structure.

Revision 3657

zzogl: Get a start on abstracting the memory code a bit.
Zeydl...
Integrate r218 -- it's important stuff and could solve mac's issues to.
arcum42
Suppose I should integrate r214-r217, too, then. :)
I'll get on it once I'm able to get svn to cooperate. (I'm having trouble connecting to your server at the moment...)

Revision 3658

GregMiscellaneous: Update the codeblocks project file for ZZOgl.
arcum42
Since greg said people are free to commit to this branch, just setting it up so I can play with it a bit...
arcum42
First thing I noticed is ar tonelico 2 crashing at startup, right when it tries to call GetSkipCount_Handler. I'm trying to debug that right now...
Well, second thing, really. First was changing:
if( (fi.TPSM == PSMT32Z || fi.TPSM == PSMT24Z || fi.TPSM == PSMT16Z || fi.TPSM == PSMT16SZ)
to:
if (PSMT_ISZTEX(fi.TPSM)
GS.h has a bunch of helper functions for common things you need to check on psm...
arcum42
I'm pretty sure the crash is related to the fact that there are games in the list that don't have GSC functions, because I've been using it for ZZOgl hacks.
(ar tonelico 2 being one of them.)
gregory....
Hum, yes code of the GSC_list is probably bad. Not sure the memset (GSmain.cpp line 188) do the good things.
gregory....
I will look to GS.h functions. For the moment it was just a copy fast of GSdx (I'm not sure neither that conditions are the same)
gregory....
I found the issue the size is wrong... GAME_INFO_INDEX is different of the size of the enum games...
arcum42
I'm getting some changes to the list ready. A good deal of the games that have skip draw weren't in the list in ZZOgl...
arcum42
All right, they are in r3660.

Revision 3659

zzogl-pg: Add in changes from zzogl r218. (I'll still need to go through
r214-217 and grab any important changes, though.)
arcum42
I think I got all the important changes from that revision. I'll clean the changes to targets.h later...
Zeydl...
Seems nice, but don't forget to recompile shader's file to made this changes available (you need new ps2hw.dat).
arcum42
Right, forgot that. And I should probably put that GPL2 notice back in. :(
Zeydl...
Well, 214-219 is a SkipDraw realisation, I also do a new CRC code a bit, so you could use Greg's branch.
wing...
zzogl FTW! =)

Revision 3660

GregMiscellaneous: Add in GSdx's crcs. Fix a crash I encountered.
arcum42
Oops. Left the ,-1, -1 off the first entry. Oh well, easily corrected.
gregory....
Thanks to take care.

Revision 3661

zzogl-pg: Copy the modified ps2hw.dat file in as well.
Jake.Stine
ZZOgl in Win32 won't compile, btw. Not sure exactly whcih revision yet, but the error is GL_TEXTURE_RECTANGLE not being defined. (there's a define for it in glew.h, which currently isn't included under win32)
Including glew.h is problematic because it throws "gl.h already included!" errors. I'll turn on msvc include diagramming later when I have time and figure it out if you guys don't beat me to it. :)
(working on getting my newdmac stuff from last weekend merged and uploaded)

Revision 3662

GregMiscellaneous: Fix a typo from the last commit. Add Skipdraw to the
configuration file.
arcum42
And that's about it for me for the night...

Revision 3663

zzogl-pg: Quick Windows fix for an issue introduced in zzogl r218. Fix a typo.
arcum42
And now I'm really going to bed.
Zeydl...
What does it mean? GL_TEXTURE_RECTANGLE are OpenGl standart, it could not be undefined if OpenGL 1.0 is present.

Revision 3664

newdmac: sync with trunk (plus some excessive svn:native props that slipped in
because of a misclick on my part)

Revision 3665

GregMiscellaneous: Various clean
Zeydl...
It seems than somewhere (in GoW), Gabest use FBMSK ~= fbm, but in others (Haunted Ground) FBMSK = fbm!
1 line-by-line comment
/branches/GregMiscellaneous/plugins/zzogl-pg/opengl/ZZoglFlushHack.cpp  
r3665  
line 440:
440: skip = 30;
30 here is bad, 4 or 23 is better.
gregory....
I play a little the game. With 4 or 23 there is some green artifact that appears (around the player). 30 is definitevely wrong. Anyway did you know what effect is skipped ? I did not see any difference with 0.

Revision 3666

GregMiscellaneous:
* Use memset instead of GSC_Null, It saves a function call and I do not thinks
it was related to the previous crash. Arcum can you test it ?
* Tune the GOW value.
gregory....
Note, I change GSC_Null to return true, in the others case it bypass the SkipDraw parameter...
Later I will convert the function into void. There is no reason to return a bool.
arcum42
Yeah, fired up ar tonelico 2 without issues, so the crash is still gone...

Revision 3667

newdmac: lots more progress. most dma controller fundamentals are finished now
(still need to do all the tie-ins via HwRead/HwWrite register handlers, so still
some work to go before new dmac is usable/testable).
arcum42
Issues I encountered when compiling this code on Linux:
In NewDmac.h, in the union tDMA_TAG64, it doesn't like having 'tDMAC_ADDR addr;' in an anonymous struct. I was able to get around that by commenting out the two constructors in tDMAC_ADDR, or by naming the struct.
Line 49 of NewDmac_ChainMode.inl is:
fromSprReg.madr = dmacReg.mfifoWrapAddr(fromSprReg.madr.ADDR);
and the initial fromSprReg.madr should either be fromSprReg.madr.ADDR or fromSprReg.madr._u32. (I'm not sure if it should pass SPR or not.)
There are also several calls to DMAC_LOG in NewDmac.cpp that are not POD-safe. Basically, they just needed .ToUTF8(false) followed up with .data(), as I recall...

Revision 3668

GregMiscellaneous: Implement a Linux dialog box item for skipdraw.

Revision 3669

Small updates to the game database and GSdx CRCs.
abdulhke...
hi i am not quite sure about this but did you fix the problem in the svn-3667 it's when enabling the super vu and start the vm it crash the emu i wont bother you with any thing alse i just want to make sure it have been fixed 'cause i love pcsx2 and want to help by repoting some bugs! thanx

Revision 3670

GregMiscellaneous: Some cleanup. Convert boolean function to bool.
arcum42
Hmmm... As I read it, those tests that are commented out were there to cause it to not skip draw in those particular cases. Maybe you could set skip to 0 if they are true instead?
gregory....
Well, I could but it will change anythings. The test is done when skip is 0. So skip is still 0. The function will return after. Multiple test does not overlap, only one can be true.
Example GSC_Bully: skip = 0;
We will do 2 test
The first check fi.FPSM == PSMCT32 -> return true
* now directly do the 2 test which will be false if the previous first was true
The 2nd fi.FPSM == PSMCT16S -> set skip to 6
arcum42
Hmmm... point. As long as the tests don't overlap, anyways. I forgot that it had already tested to see if it was 0. :(

Revision 3671

common, GSnull, zzogl-pg, SPU2null: add more safety to some fclose functions.
Avoid a bunch of double free and memory corruption.
gregory....
Now, all windows are closing. But I still have a segmentation fault in the end. Maybe related to my ATI drivers...
Run: boot(fast) -> quit (after some times, severals seconds)
ramapcsx2
Nice.
About your segfault, did you try a debug build yet?
It'll prolly give you some info at least.
gregory....
Yes, a backtrace give somethings like that:
(gdb) bt
#0 0xee20ccd2 in ?? ()
#1 0xe942d62a in ?? () from /usr/lib32/dri/fglrx_dri.so
#2 0xe94f1284 in ?? () from /usr/lib32/dri/fglrx_dri.so
#3 0xf7feed36 in ?? () from /lib/ld-linux.so.2
#4 0xf718757f in __run_exit_handlers (status=-314177312, listp=0xf729b304, run_list_atexit=true) at exit.c:78
#5 0xf71875ef in *__GI_exit (status=0) at exit.c:100
#6 0xf716ec7e in __libc_start_main (main=0x81895b5 <main>, argc=1, ubp_av=0xffffd634, init=0x8322080 <__libc_csu_init>, fini=0x8322070 <__libc_csu_fini>, rtld_fini=0xf7feeb50, stack_end=0xffffd62c)
at libc-start.c:260
#7 0x0805c161 in _start ()
There is a great chance, it is a bug in the fglrx (ati) driver. I think I will wait few days to test this month release (the last three broke opengl 2...). If it is only a segfault when closing pcsx2 (people does not need this feature anyway :) )
Zeydl...
Well, you should be warned, than fglrx could segfault per incorrect shader operation or even from some OpenGL calls, that forked inside driver. I have no idea how to debug this evilness.
gregory....
Yes without visibility, there nothings we can do. Better spend the time in others places.
Better wait the open source driver radeon, it will be easier to debug. At least found where is located the issue. For the moment HD2000-HD4000 support openGL 2.1 compliant (enough for PCSX2 if I'm correct) albeit slow. And HD5000 (my card...) probably in a couple of months.
Zeydl...
No chance until they support OpenGL 3.0. We need Alpha32-bit channel.
gregory....
Do you only need Alpha32-bit channel or plenty of others stuff ? Actually it is maybe implemented. What is the opengl extension related to this alpha 32b ?
Zeydl...
I need one of followings formats: RGBA_32F (4 * floating) from OpenGL 3.0, GL_ALPHA_FLOAT32_ATI from ATI_texture_float, GL_ALPHA32F_ARB from ARB_texture_float. If I don't have one of this I could use GL_ALPHA16 form OpenGL 2.0, but picture is pretty ugly.
Zeydl...
O'k. I made r221 than correctly use OpenGL2.0, so it could be usefull for old cards and free drivers.
gregory....
Hum, threre is a great chance that GL_ALPHA32F_ARB is supported (at least in chip before evergreen). Well, the dri code do something like that
./r600/radeon_texture.c: case GL_ALPHA32F_ARB:
./r600/radeon_texture.c- return MESA_FORMAT_ALPHA_FLOAT32;
No guarantee that is hardware accelerated.
The best and easiest solution, we need to find a linux guy with a HD3000-HD4000 that is able to install git mesa and git ddx ;)
Zeydl...
Well, I am with HD4870 and I do it allready. No chance. But I fix OpenGL 2.0 format, so this part could be passed.
gregory....
What is your mesa and ddx version ? I'm afraid that you need the lastest bits. At least it needs mesa 7.9-git, I thinks 7.8 is not yet 2.1 compliant.
Zeydl...
7.7. 7.9 is to unstable even for unstable.
gregory....
Agree.
IMHO, better wait end of year with something usable. Something like mesa 7.9.1
7.7 was release 8 months back.
7.8 was release 5 months back.

Revision 3672

wiki: add a link on the 64 bits status. So user can easily found it.

Revision 3673

Very nasty quick fix for sVU and VU interpreter regression in r3648. I have no
idea why it's desirable to be able to move the VU registers structure after
initialisation and a proper fix allowing for this is going to messy. Needs
Jake's attention.
ramapcsx2
Works :)
We'll have to see what this was all about later.
cottonvibes
I don't get why Jake did the VURegs* changes either.
It complicated code and I can't see a good reason for it.
Why would the location for VURegs ever change after being initialized?
Jake.Stine
I'll likely undo all this anyway. There are good reasons for the memory work I'm doing, but its hard to explain. The less large-page static vars we have, the more likely crap like superVU will be successful at finding virtual memory it needs. At the same time, I'm trying to improve the PCSX2 memory usage in general, and get rid of a number of fairly horrible hacks in how we deal with PS2 memory mapping in general.
But part of the work involved in doing this is having systems that can deal properly with it. And honestly, if you want to place blame, mVU shouldn't be caching the VUregs* value at all (and I could harp on VIFunpack for doing the same to several other values). It's convenient on the short term, sure; and it makes the recompilation 0.0001% faster. But it makes my life a lot harder when I get in the mood to try to improve the PCSX2 memory models.
I considered replacing it with a macro or accessor, but thought this would be less invasive until I could sit down and clear it of all unwarranted value caching at a time, for consistency.

Revision 3674

Geh, forgot to save after writing a comment.

Revision 3675

GregMiscellaneous:
* add a new hack (linux only) to enable the automatic skip draw (ease testing
and probably remove later)
* forget GSC_HauntingGround from my last copy-past....
Zeydl...
Hayunting grounds FBMSK should be reversed: fi.FBMSK = curvb.frame.fbm. Don't know how it's possible in GSDX.

Revision 3676

GregMiscellaneous:
* Fix compilation (PSM_)...
* Invert FBMSK value for haunting ground

Revision 3677

ZZOgl-pg: Catch up with some of the changes in recent revisions of zzogl.
arcum42
Mainly changes from r220-r222 that didn't involve skipdraw...
Zeydl...
Well, change in Regs.cpp remove on crash from DarkCloud1. g_bIsLost is no need in OpenGL, and FFX-2 intro have a biggest screen that supported.
arcum42
Yeah, I wanted to make sure I got the Dark Cloud 1 and FFX-2 changes in, and I'd had g_bIsLost commented out for a good while anyways...
Zeydl...
I plan to remove all hacks from Regs.cpp and move them to FlushHack soon, so you could made it to. Right now I read zerogs.h.
arcum42
Should be quite a feat. ^_^
I probably should add FlushHack. I just don't want to make merging Greg's branch and the main trunk too difficult...
gregory....
I think I could manage to keep the branch clean. Biggest changes are in FlushHack.cpp anyway. By the way, I sync my branch with the trunk. It would limit futur conflicts.

Revision 3678

zzogl: Limit texture supported to 8k
Zeydl...
By the way, I was able to run tunnels test under radeon driver. 3FPS gained.

Revision 3679

GregMiscellaneous: Sync from trunk. Before there are too many conflict

Revision 3680

VU interpreters: removed redundant VU memory masking (this also caused the VU0's
memory map of VU1 regs to fail), and improved inlining a little bit.

Revision 3681

- Warn about disk emulation software on CDVD file access failure. Seems to be a
too common problem people run into.
- Minor log change for SPU2-X.
refraction
Think it was about time this was done tbh ;p
ramapcsx2
Yea, I hope this warning is enough though :p
eliotfur
It's not enough AFAIK... You should include several most common emulation software titles too... Some people just "use computer", they don't know what disk emulation is...
Make sure the iso file is not mounted in any disk emulation software like Daemon Tools, Alcohol 120% or VirtualCD!
ramapcsx2
I kinda don't like mentioning all those commercial tools in PCSX2 though :p
gregory....
IMHO, people that use this kind of tools are not (too) basic users. Anyway, if this situation occurred 90% (do not know) of the time, maybe you could use an affirmative sentence (... is used by another software....).
ramapcsx2
Gregory:
They are exactly that though, basic users :p
It's a common emulation dogma to mount an iso file using a disk emulator, then pointing a cd plugin to that.
kaboo...
but isn't that quite a bit slower
refraction
in no way shape or form is this any slower.
if you are referring to reading the iso directly instead of a mounted drive, if anything, it's faster.
Ragha...
Shouldn't the DVD emulation open file in "r" mode? The same applies for PCSX2, I wonder what was the real problem.
kaboo...
@ refraction:
no I meant it the other way around, mounting with daemon tools and then using a cd/dvd plugin... in my expierience that's way slower
refraction
Raghar: It would be nice, however the file is completely locked out by the DVD Emulation software, which is quite a pain. But i suppose they dont expect you to be mounting the iso in anything else, from their eyes it could be considered a very bad move (in all cases apart from console emulators)

Revision 3682

onepad: implement setLogDir interface

Revision 3683

CDVDiso: Fix the code to compile without -fpermissive
* Add some 'const'
* Add some type cast: FILE* and char*
gregory....
Note: If someone can check that windows still compile fine, I will be glade.
ramapcsx2
It compiles and works under Windows.
Good job :)

Revision 3684

zzogl-pg: Add the updated crc list from r3660.
arcum42
Actually, technically it's not straight from r3660, since I recall I fixed a mistake to it in a later revision.
Just wanted the two versions of the list in sync...
gregory....
Just for information, it seems there are 2 same CRC for 2 different games. The first one takes probably GAME_GUSTHACK as gamefix.
{0x7ACF7E03, ICO, Unknown_Region, 0, -1, -1}
{0x7acf7e03, AtelierIris1, Unknown_Region, GAME_GUSTHACK, -1, -1}
arcum42
Ah. I looked for the duplicate, but I must have had case sensitivity on when I did the search.
One of the two is probably wrong. I don't own Ico at all, though, and my version of Atelier Iris 1 has a different crc. The Ico one is from GSdx, and the other I think was added by Zeydlitz at some point...
Zeydl...
Mine AtelierIris have this CRC 0x7acf7e03. Mine ICO have CRC 0x5c991f4e.
gregory....
Hum do not remember which one, but there are others minor duplicate. It is same games but with a different regions (EU,US...). Probably not important.

Revision 3685

* Redid the VIFunpacker's wrapped memory address detection (a bit more compact
now)
* More VU interpreter cleanups (VU0micro.cpp and VU1micro.cpp are just about
ready for permanent removal now).

Revision 3686

Fix GCC compilation error from prev commit.

Revision 3687

Eh, more VU interpreter cleanups.
gb2985
Whatever works :)
gregory....
Jake, can you look at the following comment. Thanks.
1 line-by-line comment
/trunk/pcsx2/VU0.cpp  
r3687  
line 110:
110: memWrite128(addr, VU0.VF[_Ft_].UD);
Not related to this revision.
In EE interpreter mode I have a segfault. To fix it I replace memWrite128(addr, VU0.VF[_Ft_].UD); by memWrite128(addr, &VU0.VF[_Ft_].UQ); (like few line above with memRead128)

Revision 3688

microVU: Added some logs to dev builds for checking rare cases. (VU programs
that wrap around VU memory, and VU0 micro-programs that access VU1's registers
by its mem-mapping at 0x4xxx)
romulux_...
nice to see some activity from every dev, keep up the nice work!

Revision 3689

A 'nice' fix for GCC's fickle dislike of packed structs. 1) the VU registers
struct no longer needs packed (the unions ensure proper packing); 2)
introduction of 128-bit UQ/SQ members.

Revision 3690

PadNull: safer fclose

Revision 3691

newdmac: Added preliminary support for TTE; refactored code to use some
classes/namespaces.
arcum42
I might have mentioned this before, but in Linux, compiling the newdmac branch errors out with:
/usr/local/src/pcsx2-mgts/pcsx2/ps2/NewDmac.h:130: error: member ‘tDMAC_ADDR EE_DMAC::DMAtag::<anonymous struct>::addr’ with constructor not allowed in anonymous aggregate
/usr/local/src/pcsx2-mgts/pcsx2/ps2/NewDmac.h:130: error: member ‘tDMAC_ADDR EE_DMAC::DMAtag::<anonymous struct>::addr’ with constructor not allowed in union
Easiest way I saw to get around it was to comment out the constructors in tDMAC_ADDR, since they don't seem to be used.
Also, in line 52 of NewDmacChain_Mode.inl:
fromSprReg.madr = dmacReg.mfifoWrapAddr(fromSprReg.madr.ADDR);
You can't assign directly to madr; it'd need to be madr.ADDR or madr._u32...
ramapcsx2
So godofdrive, feel like explaining the -1?
Or just having a bad day?
chuuey
lmao rama ;)
jfre1...
Bet its cause of some game not working that never worked, or was unaffected by this rev.
Jake.Stine
@arcum: yeah you mentioned before. I'll fix them proper at some point, when I'm actually ready to start testing the new code. I have my linux VM box up and running now, so I can just log in and give it the full whirl through GCC and see what it yells at me for. ;)

Revision 3692

General emulator memory work, regarding my new policy that most (or all) cpu and
hardware registers should be standard globals, as it makes our lives a lot
easier in general (and their memory footprint is small so it won't adversely
affect the virtual memory availability of the host operating systems). Details:
* Removed the hacky g_pVU1 pointer, which required VU1 cpu registers to be part
of VU0. Replaced it with a standard VU1 variable (mimics all other CPU
registers, which are standard static vars). We were using translation
functions/tables for all VU0 memory operations anyway, so this was a no-brainer.
* Removed code from microVU that was only there to help deal with the fact that
g_pVU1 was annoying.
* Turned eeMem->HW into a static global array eeHw [64k].
cottonvibes
i don't like separating the microRegAlloc class's methods from its structure.
this cpp principal is something i've grown to hate, and there's no reason to do so in mVU since it all acts as one translation unit during compilation.
the problem i have with separating the methods are:
1) its harder to read since you have to go back and forth between 2 files to view the data members, small inlined methods, method prototypes, and separated methods.
2) harder to manage, takes up more space, and not necessary with mVU since compiles as one translation unit.
3) worsens intellisense. sometimes i go to the function definition, and it instead takes me to the function prototype and then i have to do another search. this gets especially terrible with virtual methods, so hopefully mVU remains forever without virtuals (no reason to have them in mVU anyways).
Jake.Stine
>> this cpp principal is something i've grown to hate, and there's no reason to do so in mVU since it all acts as one translation unit during compilation.
Using .inl files has nothing to do with being one translation unit. I've tried to explain this before. It has to do with inter-dependent class/structure stuff:
1) class microVU needs to have microRegAlloc defined
2) class microRegAlloc needs class microVU defined.
Before, this was circumvented by using lots of static/global functions. I dare argue that defining a lot of static/global functions in .cpp files and then having them prototyped in .h files is NO DIFFERENT than doing h./.inl implementations in classes. In fact, if "consistency" is your kick of the year, by doing h/inl pairs we're actually keeping things MORE consistent between C-style and CPP-style code in pcsx2 (and we'll always have some amount of C code because of the recs and such).
The fact that CPP ever allowed inline class code implementations at all is the problem. We really shouldn't be using them. They were thrown in to make things nice for lazy coders, but the language simply CANNOT SUPPORT THEM ADEQUATELY. (this especially true of anything templated)
And really I have no problem not using them for the short functions either; I just thought that as a general rule most programmers still find that more convenient. Same for static __forceinline functions in headers in traditional C code -- You'd always have to F12 to the prototype first, and then see if its defined inline -- and then jump to the CPP file from there.
I'd love for C++ to allow for inline class definitions to be effective, but honestly it doesn't unless you really screw with your code and turn it into basically C-style code anyway. And even then the code ends up being limited in how it can be extended -- a good example being this. Make some changes, possibly add (even a simple!) template, and suddenly you're forced to use .h/.inl in order to resolve inter-dependent class definitions.
If you want inline function deifnitions, use a language with a proper multi-pass parser. -_-
micove
Hello, I just wanted to say that this revision breaks linux compilation. 3691 worked fine while 3692-3695 (latest) die with 340 lines of:
CMakeFiles/pcsx2.dir/COP2.cpp.o:COP2.cpp:(.text+0x7f0): first defined here
CMakeFiles/pcsx2.dir/x86/sVU_Micro.cpp.o: In function `VURegs::IsVU1() const':
sVU_Micro.cpp:(.text+0x7e0): multiple definition of `VURegs::IsVU1() const'
CMakeFiles/pcsx2.dir/COP2.cpp.o:COP2.cpp:(.text+0x7e0): first defined here
CMakeFiles/pcsx2.dir/x86/sVU_Micro.cpp.o: In function `VURegs::IsVU0() const':
sVU_Micro.cpp:(.text+0x7f0): multiple definition of `VURegs::IsVU0() const'
arcum42
I would think this would work, provided there isn't a reason why idx would be inaccurate (It compiles on Linux, anyways):
--- pcsx2/VU.h (revision 3692)
+++ pcsx2/VU.h (working copy)
@@ -163,9 +163,10 @@
Micro = NULL;
}
- bool IsVU1() const;
- bool IsVU0() const;
+ bool IsVU1() const { return (idx == 1); }
+ bool IsVU0() const { return (idx == 0); }
+
VIFregisters& GetVifRegs() const
{
return IsVU1() ? vif1RegsRef : vif0RegsRef;
@@ -190,8 +191,4 @@
static VURegs& VU0 = vuRegs[0];
static VURegs& VU1 = vuRegs[1];
-__fi bool VURegs::IsVU1() const { return this == &vuRegs[1]; }
-__fi bool VURegs::IsVU0() const { return this == &vuRegs[0]; }
-
extern u32* GET_VU_MEM(VURegs* VU, u32 addr);
gregory....
Hum, I have some doubt that idx is properly set. Actually I did not see any place where it is set. Nothing in constructor and nothing with grep -r "\.idx" pcsx2 ...
As a side note: "idx == 1" could be replaced by "idx != 0" (perhaps a little faster or not)
cottonvibes
"Comment by Jake.Stine, Today (5 hours ago)
It has to do with inter-dependent class/structure stuff:
1) class microVU needs to have microRegAlloc defined
2) class microRegAlloc needs class microVU defined."
okay i see why you did it now. technically microRegAlloc doesn't need a reference to microVU struct though. It just needs an index so that it can reference the proper VUregs structure like microVU currently does. Or just a pointer to a VUregs structure like it initially did.
Since everything will be static-globals by rule now, there will be no problem with keeping an internal pointer to the VUregs.
"If you want inline function deifnitions, use a language with a proper multi-pass parser. -_-"
c++ with multi-pass would be my ideal language. Other languages that currently support multi-pass have their own annoyances and limitations.
gregory....
I suggest to add a constructor parameter to set idx. Here the whole patch (-p1). But I have some segmentation fault (with or without the new constructor)
Index: pcsx2.snapshot-3696/pcsx2/VUmicroMem.cpp
===================================================================
--- pcsx2.snapshot-3696.orig/pcsx2/VUmicroMem.cpp
+++ pcsx2.snapshot-3696/pcsx2/VUmicroMem.cpp
@@ -18,7 +18,7 @@
#include "Common.h"
#include "VUmicro.h"
-__aligned16 VURegs vuRegs[2];
+__aligned16 VURegs vuRegs[2] = {VURegs(0), VURegs(1)};
static u8* m_vuAllMem = NULL;
static const uint m_vuMemSize =
Index: pcsx2.snapshot-3696/pcsx2/VU.h
===================================================================
--- pcsx2.snapshot-3696.orig/pcsx2/VU.h
+++ pcsx2.snapshot-3696/pcsx2/VU.h
@@ -157,14 +157,15 @@
efuPipe efu;
ialuPipe ialu[8];
- VURegs()
+ VURegs(uint idx)
{
Mem = NULL;
Micro = NULL;
+ this->idx = idx;
}
- bool IsVU1() const;
- bool IsVU0() const;
+ bool IsVU1() const { return (idx != 0); }
+ bool IsVU0() const { return (idx == 0); }
VIFregisters& GetVifRegs() const
{
@@ -190,8 +191,5 @@
static VURegs& VU0 = vuRegs[0];
static VURegs& VU1 = vuRegs[1];
-__fi bool VURegs::IsVU1() const { return this == &vuRegs[1]; }
-__fi bool VURegs::IsVU0() const { return this == &vuRegs[0]; }
-
extern u32* GET_VU_MEM(VURegs* VU, u32 addr);
arcum42
That last patch seems like it works under Windows, in a bit of brief testing.
I'm definitely getting consistent segfaults under Linux, though, or I'd probably have committed it already.[1] Easiest crashes to reproduce are starting up the bios, and loading a saved game from the memory card in Kingdom Hearts...
[1] That and I've been somewhat preoccupied the last few days anyways.
Jake.Stine
@arcum42: I'm *pretty* sure you can fix that warning of multiple definitions by moving the __fi to the definition of the function (its currently on the implementation).
It can also be fixed by removing __fi.
Both of these are preferable to using Idx, because testing the "this" pointer is a constant compare (more efficient).
I try to remember not to put __fi on implementations of functions; gcc always gets muldefs that way. But sometimes I forget. >_<
arcum42
Actually, neither one of those suggestions works in this case, unfortunately. Usually what I do is make functions in headers static to avoid problems with multiple definitions. But, of course, I can't do that with those functions...
arcum42
Though if we really want to keep not using idx, the function implementations could be moved out of the headers somewhere else, like VU0.cpp. That does work; it just looks odd.
gregory....
In my case I have segfault on mVU execute (interpreter seems ok) on various games (if not all). Do not know if it pick up the wrong index somewhere or if there is somethings bad.
gregory....
Hum, tryed to move function to VU0.cpp to compile and unfortunately is still segfault. I guess some changes was not gcc friendly.
Jake.Stine
Bah, evil GCC. Maybe using "inline" fixes it? I know there's something I figured out with the emitter that fixed the muldefs.
gregory....
Yeap, just inline is a good idea :)
gregory....
Hum I maybe found the reason of the segfault on linux. Well just a hint.
VU crash on the following instruction:
=> 0xf565e01f: movaps 0xa221d7c,%xmm0 (with 0xa221d7c <vuRegs+2348>)
But 0xa221d7c is not 16bytes aligned !!! Maybe vuRegs need some alignement tunning.
gregory....
Actually. vuRegs[0] is 16 bytes aligned not vuRegs[1]
gregory....
Here a patch that fix the alignement and inline issue. Could someone test it on windows ?
Index: pcsx2.snapshot-3696/pcsx2/VU.h
===================================================================
--- pcsx2.snapshot-3696.orig/pcsx2/VU.h
+++ pcsx2.snapshot-3696/pcsx2/VU.h
@@ -116,7 +116,7 @@
u32 Cycle;
};
-struct VURegs {
+struct __aligned16 VURegs {
VECTOR VF[32]; // VF and VI need to be first in this struct for proper mapping
REG_VI VI[32]; // needs to be 128bit x 32 (cottonvibes)
@@ -190,8 +190,8 @@
static VURegs& VU0 = vuRegs[0];
static VURegs& VU1 = vuRegs[1];
-__fi bool VURegs::IsVU1() const { return this == &vuRegs[1]; }
-__fi bool VURegs::IsVU0() const { return this == &vuRegs[0]; }
+inline bool VURegs::IsVU1() const { return this == &vuRegs[1]; }
+inline bool VURegs::IsVU0() const { return this == &vuRegs[0]; }
extern u32* GET_VU_MEM(VURegs* VU, u32 addr);
Jake.Stine
Yeah, that's fine. go ahead and commit it. :)

Revision 3693

GSdx:
Another round of configuration dialog renovations.
Fixes the leftover "Skipdraw" text when hacks are disabled.
Group the options a bit nicer. Group hardware Anti Aliasing with hacks.
eliotfur
Some ideas:
We better group "Native resolution" checkbox and "Scaler" dropdown list into one and make it smarter... Something like this:
Internal Resolution:
--Native (Recommended)
--2x (Safe)
--3x (Heavy)
--4x (Very heavy)
--5x (Extremely heavy)
--6x (!!!)
--Custom (Not recommended)
Custom X and Y fields should be activated ONLY when "Custom" mode is selected... That's because a lot of people think that they should enter their screen resolution here... All they get is messy graphics and slow performance (A-ha, 1680x1050 and 1920x1080 is not very good for internal resolution)
Maybe "Offset Hack" checkbox should become visible/active if the user selects anything except "Native" and "Custom", because it doesn't work with them... This is quite safe hack anyway...
ramapcsx2
Sounds good.
I'll try that :p
ramapcsx2
Bah, sorry. That's a lot of new code and changes to the configuration.
Seeing how i *hate* working with dialogs, I choose to opt out.
Maybe some other time, since the idea is fine :p
andutrache
the dialog looks nice and more organized now :)
tek...
eliotfur: if one is using a monitor with a native resolution of 1680x1050 what resolution would be a good alternative? 1680x1680?
eliotfur
tekkuu:
Consider the most common Native PS2 resolution - 512x448... So, to have a good looking picture you should use the resolution as close to your screen resolution as possible... So, 3x scaler is fine, it'll give you 1536px horizontal... 4x will give you anti-aliasing effect, but it'll be too slow... Anything inbetween (I mean custom resolution) will probably give you misalignment artifacts...
Frankly speaking, even 2x looks good on high-res screens... It's like watching 720p movie on a FullHD screen (1080p)... Sharp enough, I say...
ramapcsx2
eliotfur / tekkuu:
The "internal resolution" has absolutely nothing to do with the monitor resolution.
It's completely unrelated and should never have been called "resolution" :p

Revision 3694

newdmac: sync with trunk. (r3663-r3693)
jadjkor...
awesome job!
you guys rock! ^^

Revision 3695

pcsx2: Fix tons of warning (no return statement)
azte...
warning fixes always good, keep on greg. ;)
gregory....
Especially in .h, when the compiler prints the warning for every files that you compile, just in case you did not notice the fist time...

Revision 3696

pcsx2 MMI: u16 -> u32 for src parameter of PMFHL_CLAMP.
gregory....
It makes more sense like that. The function is called with 32bits src value and comparaison with 32bits value will be correct (the 2nd was always false).

Revision 3697

mVU, VU interpreter: fix arc the lad, freakstyle (VU1 register mapping / memory
wrapping)
ramapcsx2
Eventhough we're not sure yet if this kind of mapping is correct, it's certainly better than what we had before :)
http://www.imagebanana.com/view/ablp60oj/Unbenannt.jpg
marius.h...
Even if it's not right that way, see it as some kind of workaround of some compatibility issues^^.
ramapcsx2
Also fixed: Soul Calibur 3 slight SPS. :)
refraction
I think this only applies to VU0? VU1 has several mirrored addresses after it (activision games are a nice test, possibly the jak and daxter games too)
sudonim1
Our assumption is that VU1 is mirrored infinitely, refraction. That hasn't changed.
ivicamar...
Breaks God of War 2 ntsc
after logo this shows
GIFTAG error, size exceeded VU memory size 3ff
989 ERROR 53 84000002 11040 0 0
But i'll stay neutral for now.
ramapcsx2
leviatan-b:
You missed the small, yet slightly related fact that it only breaks on super VU.
So false alarm there, we know sVU is broken.
ramapcsx2
Also sVU didn't break in this revision, it broke way earlier.
ivicamar...
Sorry. I though it was mVU. Don't know how this happened.
Jake.Stine
Excellent, the memory ops look much better now. :)
(and fixes my own typo from earlier changes, but I guess it worked out since it inspired some closer looks at the operations)
frost....
What is fixed in Soul Calibur 3 ?
frost....
Oh,hair fix with recompiler.Finaly!
Hefra...
+10000 for the SC3 hair fix! It was very annoying in such a beautiful game.

Revision 3698

pcsx2 MMI: another fix for PMFHL_CLAMP.
The dst param was never being modified since it was being passed by value
instead of by reference. This leads me to believe the rest of MMI.cpp is
probably riddled with errors too.
SNP_Tira...
Heh.
Is PMFHL_CLAMP ever called if dynamic recompilation is being used for the EE?
gregory....
Hum, I kinda see it. But I did not tilt. Anyway, I agree with you it is probably not well tested.
cottonvibes
[email protected]: i don't think so
Nne...
Here's an MMI test program that tests every opcode (predefined checks, nothing complex). At the time I tested both the interpreter and recompiler and got no errors. Weird.
http://www.mediafire.com/?hg9xx9041kbdf1s
ramapcsx2
Awesome elf :p
And yeah, it gets this now:
error! mfhl.sh 45677ffe_f0008001_7fff7fff_80008000 (not 4567_7ffe_8000_13579bdf)
Jake.Stine
The original code was correct, except that it had been turned from a macro into a __fi function somewhere along the way, which broke it from returning a value (think Arcum did that refactoring job).
The new code is incorrect because the second conditional probably fails without an explicit (int) typecast, because it becomes a signed compare against an unsigned 64 bit value when what we really want is a signed compare against -0x8000. The "clean" fix should look like this:
if (src > 0x7fff) dst = 0x7fff;
else if (src < -0x8000) dst = 0x8000;
else dst = (u16)src;
Some people don't like negative hex numbers, but I think they make loads more sense than manually typecasting unsigned hex to (int).
I'd do the fix here but all my trunks are brutally butchered at the moment :p

Revision 3699

GregMiscellaneous: Add a FRAME_RECORDING_ON define to record skipped frame based
on Zeydlitz version.
Note: it dumps some .tga picture in current folder.

Revision 3700

sVU: same address translation fix as in r3697

Revision 3701

debian: Refresh and clean. Thanks Micove.

Revision 3702

PCSX2 VU: Linux compilation fix and force 16 bytes alignement for VURegs
Spu2x: Use a standard destructor (POD safe stuff). Fix various segmentation
faults ( Issue 846 )

Revision 3703

* Added subdivided content to the u128 type (changed it from a struct to a
union, added _u32[4], _u16[8], etc).
* Added ToString methods to the u128 type.
* Bugfixes for the FastFormat string utilities, namely when writing UTF8 content
via the UTF16 formatter.
* MSVC: Removed obsolete disabling of unsigned/signed mismatch warning (4018)

Revision 3704

MAJOR: All new hwRead and hwWrite handlers (expect regressions). Details:
* Writes via 16 and 8 bit ops now use 32-bit read/modify/write operations by
default; which should enable nearly complete support for all such operations
(instead of the formerly spotty coverage before).
* Eliminated almost all former 8/16-bit specific register operations. All code
shares the same 32 bit handlers now.
* Completely revamped the developer trace logs for hardware registers! *ALL*
registers are logged now, complete with address, name, and value being
read/written (and nicely formatted!).
* Handlers are now fully page-based using templated functions (minor speedup)
Jake.Stine
... and I'll have the linux/gcc fixes up shortly.
eve...
So big work.Thanks Jake.
gregory....
FFXII (NTSC-U) is a little "broken" with these changes. I really do not know about the impact of the assertion.
Ok on 3702
Ko on 3706
Condition: (mem & 0x03) == 0 (the last 2 bits are 01)
Stacktrace:
[00] void hwWrite8<9u>(unsigned int, unsigned char) pcsx2/HwWrite.cpp:218
[01] 0x201f8b8d
[02] 0xa360095
[03] recExecute pcsx2/x86/ix86-32/iR5900-32.cpp:779
[04] 0x8239204 pcsx2/System/SysCoreThread.cpp:232
[05] 0x8184f9d pcsx2/gui/AppCoreThread.cpp:436
[06] 0x8239255 pcsx2/System/SysCoreThread.cpp:242
gregory....
Looking in more details, this assertion does not make sense.
gregory....
As far as I understand, it seems more logical this way. Any thought Jake ?
--- pcsx2.snapshot-3719.orig/pcsx2/HwWrite.cpp
+++ pcsx2.snapshot-3719/pcsx2/HwWrite.cpp
@@ -175,8 +175,6 @@
template< uint page >
void __fastcall _hwWrite8(u32 mem, u8 value)
{
- pxAssert( (mem & 0x03) == 0 );
-
iswitch (mem)
icase(SIO_TXFIFO)
{
@@ -204,7 +202,7 @@
return;
}
- u32 merged = _hwRead32<page,false>(mem);
+ u32 merged = _hwRead32<page,false>(mem & ~0x03);
((u8*)&merged)[mem & 0x3] = value;
_hwWrite32<page>(mem & ~0x03, merged);

Revision 3705

Linux/GCC fixes. :)
arcum42
Thanks. After the previous commit, I figured I'd have a bunch of work to do when I got home... ^_^
arcum42
Though it still does error out:
/usr/local/src/pcsx2-2/pcsx2/Memory.cpp:615: error: insufficient contextual information to determine type
/usr/local/src/pcsx2-2/pcsx2/Memory.cpp:616: error: insufficient contextual information to determine type
Which I think is another case of gcc's weak ?: handling...
arcum42
Yeah, it is, because this compiles:
void memBindConditionalHandlers()
{
if( hw_by_page[0xf] == -1 ) return;
if (EmuConfig.Speedhacks.IntcStat)
{
vtlbMemR16FP* page0F16(hwRead16_page_0F_INTC_HACK);
vtlbMemR32FP* page0F32(hwRead32_page_0F_INTC_HACK);
//vtlbMemR64FP* page0F64(hwRead64_generic_INTC_HACK);
vtlb_ReassignHandler( hw_by_page[0xf],
hwRead8<0x0f>, page0F16, page0F32, hwRead64<0x0f>, hwRead128<0x0f>,
hwWrite8<0x0f>, hwWrite16<0x0f>, hwWrite32<0x0f>, hwWrite64<0x0f>, hwWrite128<0x0f>
);
}
else
{
vtlbMemR16FP* page0F16(hwRead16<0x0f>);
vtlbMemR32FP* page0F32(hwRead32<0x0f>);
//vtlbMemR64FP* page0F64(hwRead64<0x0f>);
vtlb_ReassignHandler( hw_by_page[0xf],
hwRead8<0x0f>, page0F16, page0F32, hwRead64<0x0f>, hwRead128<0x0f>,
hwWrite8<0x0f>, hwWrite16<0x0f>, hwWrite32<0x0f>, hwWrite64<0x0f>, hwWrite128<0x0f>
);
}
}
Though I'm sure there's a shorter way to write that...
gregory....
Thread hijacking ;)
I found a potential issue with valgrind tools (unfortunately not really compatible with PCSX2). Anyway in some situtation (static void __concall ConsoleToWindow_Newline() for example)
1/ void Threading::ScopedLock::AssignAndLock is called with a null pointer (through some constructor)
-> this function does nothings and so m_IsLocked is left unaffected.
2/ Then a little later, void Threading::ScopedLock::Release()
-> This function check the uninitialized value of m_IsLocked
As far as I understand, m_IsLocked must be set in the AssignAndLock function.
Index: pcsx2.snapshot-3705/common/src/Utilities/Mutex.cpp
===================================================================
--- pcsx2.snapshot-3705.orig/common/src/Utilities/Mutex.cpp
+++ pcsx2.snapshot-3705/common/src/Utilities/Mutex.cpp
@@ -269,10 +269,12 @@
void Threading::ScopedLock::AssignAndLock( const Mutex* locker )
{
m_lock = const_cast<Mutex*>(locker);
- if( !m_lock ) return;
-
- m_IsLocked = true;
- m_lock->Acquire();
+ if( m_lock ) {
+ m_IsLocked = true;
+ m_lock->Acquire();
+ } else {
+ m_IsLocked = false;
+ }
}
void Threading::ScopedLock::Assign( const Mutex& locker )
Jake.Stine
Ok. Actually the value of IsLocked doesn't matter at that point, so no harm in not initializing it anyway. I throw an initializer for it into the constructor; which is the preferred location I think.
Zeni...
Need a new fix (r4988).
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/FPU.cpp.o
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/Gif.cpp.o
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/Gif_Logger.cpp.o
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/Gif_Unit.cpp.o
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/GS.cpp.o
[ 37%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/GSState.cpp.o
[ 38%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/Hw.cpp.o
[ 38%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/HwRead.cpp.o
[ 38%] Building CXX object pcsx2/CMakeFiles/pcsx2-dev.dir/HwWrite.cpp.o
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 0u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 0u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:402: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 8u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 8u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:402: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 1u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 1u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:403: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 9u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 9u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:403: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 2u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 2u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:404: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 10u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 10u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:404: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 3u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 3u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:405: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 11u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 11u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:405: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 4u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 4u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:406: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 12u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 12u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:406: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 5u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 5u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:407: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 13u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 13u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:407: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 6u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 6u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:408: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 14u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 14u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:408: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 7u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 7u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:409: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp: In function ‘void _hwWrite32(u32, u32) [with unsigned int page = 15u]’:
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:206: instantiated from ‘void hwWrite32(u32, mem32_t) [with unsigned int page = 15u]’
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:409: instantiated from here
/home/kanotix/pcsx2-read-only/trunk/pcsx2/HwWrite.cpp:72: error: no matching function for call to ‘_hwWrite128(unsigned int, u128*)’
make[2]: *** [pcsx2/CMakeFiles/pcsx2-dev.dir/HwWrite.cpp.o] Error 1
make[1]: *** [pcsx2/CMakeFiles/pcsx2-dev.dir/all] Error 2
make: *** [all] Error 2
[email protected]:~/pcsx2-read-only/trunk$

Revision 3706

Fix Linux compilation, fix a potential crash, and add a build target I find
useful occassionally.
arcum42
There probably is a better way to do the Memory.cpp change, but I didn't feel like fiddling with it. That change was because gcc doesn't support templates in the ?: construct, as I recall.
The new build target is just Devel with debugging symbols turned on, because I've had a few times where the error goes away with a real debug build, and I still need to figure it out.
And the ConsoleLogger thing is because it was possible for that routine to be called before g_Conf is initialized, which would crash pcsx2.
Jake.Stine
>> There probably is a better way to do the Memory.cpp change, but I didn't feel like fiddling with it. That change was because gcc doesn't support templates in the ?: construct, as I recall.
Oh, right. That's the bug fixed in 4.5 (though another bug which is related was introduced, heh). So annoying. Templates can be so nice sometimes. The hwRead/hwWrite functions are a lot more sane than they used to be.
arcum42
Yeah, haven't looked through all of the changes, but what I did look through was saner. Which is something, because that was saner then what it replaced, IIRC...
And my Linux distribution hasn't brought gcc 4.5 in yet, so I'm still testing everything with 4.4. It can take a bit to get new versions of gcc in to a source-based distribution sometimes, because everything has to be tested against it. ^_^
gregory....
Most distribution uses 4.4 by default.
On debian I can install both 4.4 & 4.5. But for the moment I hijack the 4.5 package to put in the middle a 4.6 snapshot (4.5 was too broken for LTO test, 4.6 is a little better). Anyway I will probably reinstall 4.5 in severals day.
Jake.Stine
Yeah no doubt we need to retain support for 4.4, and really 4.2/4.3 too if possible. If 4.6 is good then we can probably phase out supporting anything prior to 4.3 (meaning if anyone complains it doesn't work, we'll ignore the issue -- since obviously none of us are going to bother maintaining a compiler of that version for testing).
micove
Hello:
When building a deb package with gcc 4.4.3 (like Ubuntu 10.04) everything works fine but when using 4.4.5 from Debian/Ubuntu 10.10 I get a bunch of:
Linking CXX executable ../bin/pcsx2
CMakeFiles/pcsx2.dir/HwWrite.cpp.o: In function `void hwWrite16<14u>(unsigned int, unsigned short)':
HwWrite.cpp:(.text._Z9hwWrite16ILj14EEvjt[void hwWrite16<14u>(unsigned int, unsigned short)]+0xd): undefined reference to `unsigned int _hwRead32<14u, false>(unsigned int)'
CMakeFiles/pcsx2.dir/HwWrite.cpp.o: In function `void hwWrite8<14u>(unsigned int, unsigned char)':
HwWrite.cpp:(.text._Z8hwWrite8ILj14EEvjh[void hwWrite8<14u>(unsigned int, unsigned char)]+0xd): undefined reference to `unsigned int _hwRead32<14u, false>(unsigned int)'
I played with it a little and if I don't include the -O2 flag which gets applied by default everything compiles in all version that I tried.
gregory....
Hum, I want to point 2 things in the linux eco-system. First I do not know why but people tends to use latest versions of sofware (and complain it does not work, sigh...). I will not be suprised if ubuntu 10.10 (alpha/beta status) is more used than ubuntu 9.10...
Second, compilation is done by distribution for users (which is one goal of my packaging stuff). The distribution can make a local patch to support a previous versions of GCC. Without the constrain to support others GCC versions and MS compiler.
So from my point of view 4.4 & 4.5 is enough. 4.6 is too buggy for the moment.
@micove, remove the 02 flags for the moment. I have same issue on my system (4.4.5 with 02). I will give it a look.
gregory....
For information, the bad flags is finline-small-functions
Maybe the fastcall stuff. For the moment is time to work :)
arcum42
I'd personally be all right with as far back as gcc 4.3. Anything older, I wouldn't really feel like supporting...
gregory....
Need some free times, but I could manage to automate the testing of gcc 4.{3,4,5} in my computer. Need to think about it.
arcum42
I actually have both gcc 4.3.3 and 4.4.3 installed. I just rarely switch between them.
(And I'm debugging an interesting ZZOgl crash right now. It's reproducible by starting a game in pcsx2, then exiting. ^_^)
gregory....
;) Good luck.
Do you have a nvidia or an ati card ?
arcum42
Nvidia. And if you've ever noticed that the last message pcsx2 prints when closing is "Killed", that's what this crash is.
Looks like it's this code in particular from GLWinX11 that's killing it:
if (!glXMakeCurrent(glDisplay, None, NULL))
{
ZZLog::Error_Log("Could not release drawing context.");
}
I'm leaning towards just commenting it out for the moment...
arcum42
Or, actually, you know, it might help if glDisplay wasn't NULL at the time. ^_^
gregory....
Ok I found the issue with the template. Need to instantiate it. Either we instantiate all. Either just _hwRead32<idx, false>
Here the minimal patch.
+++ pcsx2/HwRead.cpp 2010-09-01 18:49:59.000000000 +0200
@@ -287,7 +287,8 @@
template mem16_t __fastcall hwRead16<pageidx>(u32 mem); \
template mem32_t __fastcall hwRead32<pageidx>(u32 mem); \
template void __fastcall hwRead64<pageidx>(u32 mem, mem64_t* result ); \
- template void __fastcall hwRead128<pageidx>(u32 mem, mem128_t* result );
+ template void __fastcall hwRead128<pageidx>(u32 mem, mem128_t* result ); \
+ template mem32_t __fastcall _hwRead32<pageidx, false>(u32 mem);
InstantizeHwRead(0x00); InstantizeHwRead(0x08);
InstantizeHwRead(0x01); InstantizeHwRead(0x09);

Revision 3707

Changed a few more -> to . for consistency.

Revision 3708

Uninitialized variable fix in ScopedLock as found by Gregory, and a few more
minor -> to . conversions.

Revision 3709

debian: Use english word & grammar...
Jake.Stine
Yay for professional look! :)

Revision 3710

Remove some code from DMAC.h and into LegacyDmac.cpp (these changes are mostly
related to the new dmac prep on the other branch, but I'm doing them here to
help keep major refactoring differences and merge conflicts to a minimum between
the two branches).

Revision 3711

newdmac: sync with trunk.

Revision 3712

pcsx2 mmi: apparently msvc does an unsigned compare jump when you have:
int src; if (src < 0xffff8000) {}
so solution is either use (int)0xffff8000 or -0x8000...
it also doesn't seem to print out warnings about this either D:
gigaherz
I don't know if it's anything standard but, at least in msvc, any hex constant with the high bit set to 1 is assumed to be unsigned, since that bit is taken as part of the number, and not as sign.
gabest11
If either one is unsigned the comparision is too. I also burn myself with this once a year :)

Revision 3713

microVU:
- Code refactoring (mostly changing macros to functions/constants...)
- Made it so the disable-regAlloc option flushes every 32bit instruction,
instead of every 64bit instruction (upper+lower instruction pair)

Revision 3714

ZZOgl-pg: Rework the GLX11Win.cpp code a bunch. Fix a bug leading to crashes.
arcum42
Err, that's the "GLWinX11.cpp" code, rather. I'm trying to straighten it out a bit so I have a better understanding of it (and can roll a replacement. It'd be nice to get GSOpen2 working one of these days.)
arcum42
This revision does, however, fix a crashing issue that's been around for a good while...
gregory....
Good catch. Agree GSOpen2 will be vey nice :)
arcum42
Thanks. There actually is another crashing bug still present somewhere in GLWinX11.cpp, btw, but I was too tired to hunt it down, and it was here before this revision, too.
To encounter it, turn on fullscreen, and hit escape while pcsx2 is running.
And I was thinking of writing a version of GLWinX11 that uses gtk+ as practice towards getting GSOpen2 working. Of course, I've been planning on doing that for a good long while now, so who knows when I'll get to it...
gregory....
Ah yes, I already saw this one. I thought fullscreen was not supported and forgot about it...
Well for the moment it is compilation fix.
arcum42
Well, it's not a particularly high priority, since I don't use fullscreen, and I'm not even sure whether it'll stay in once we go GSOpen2, but I noticed it, so I should probably follow up on it.
It's just difficult to debug when the GS window is taking up the full screen... ^_^
gregory....
Believe or not. I still have my segfault in the end :( Well, I think this one is related to my 32bits libraries (some are old, some are recent).
Anyway for the full screen stuff, I'm currently working on it to create 2 nice functions: SetFullscreenMode and SetDesktopMode. In the end it will be possible to easily switch between the 2 modes and also clean a little GLWinX11
arcum42
Well, that's certainly irritating. The work on full screen sounds good, though. (And if you happen to spot whatever the issue with ResizeCheck is, feel free to mess with that, too... ^_^)
gregory....
Ok, I play with X11 stuff. Actually there are 2 fullscreen mode.
The first and current one complety bypass the WM. override_redirect control this state. In this mode you must grabe keyboard/mouse, it is a real mess. To change the window behavior, the window must be unmap unfortunately the window is still used (pcsx2, zzogl thread) and so crash...
The other fullscreen is control by the WM. You can test it by rigth-click on the title bar -> fullscreen (xfce at least). Do not know how to leave it properly ;) change desktop or kill it. It get a better integration with the WM and do not need a mode change. If I'm correct this is the method of windows/GSopen2. Moreover I think it is still possible to grab some key (for example F1..12) but it needs a confirmation.
-> code will be easier.
-> drop the X11_Xxf86vm_LIB dependency
I can implement the 2nd one. What do you thinks about it ?
x and y position does not work as expected because the WM is free to place the window based on this preference.
What is exactly the purpose of ResizeCheck. The only method I found to change the window size is the zzogl parameter which closed / open so no need for it.
arcum42
I'd say to go ahead and try the second method, because that sounds like the proper method of doing things. We'll want to make sure it works properly, and that the function keys, pad plugin, etc, work properly, though.
The window manager is partially the problem on the x/y position, but I was playing with it, and a lot of it looks like that call to XGetGeometry. That and maintaining two separate copies of x, y, width, and height for no apparent reason. (A lot of this is just legacy code that never got deleted or reworked, as far as I can tell...)
As far as ResizeCheck, the window is actually re-sizable, and can actually be maximized. Which goes against having that drop down menu in the config window, really.

Revision 3715

Minor cleanup from the last commit.

Revision 3716

Hack around Linux compilation issues for the moment.
arcum42
All right, I was feeling a bit too coded out to deal with gcc's restrictions on packed structs right now, so I just ifdeffed it for the moment...

Revision 3717

microVU:
* Remove need for packed structs through use of unions.
* Streamlined the microBlockManager's linked list (less heap allocs and simpler
interations).
* Use two 32 bit compares for fast block compares, instead of 6-7 individual u8
compares.
tigerfis...
Replacing the 7 u8 comparisons with 2 u32 comparisons causes one to compare (extra) 1 u8's worth of uninitialized padding, something which should not be intended.
Jake.Stine
Yes, already known -- and the old code had similar problems on the full compare. It'll be resolved shortly.
cottonvibes
the code never had those problems as mentioned in my comment in r3720
the 'u8 r' data member should be added to the simple32[2] union so that it becomes 8 u8's and unions evenly ('r' is always 0 between block-linkings, so its fine to put there)
konaj...
not sure what exact revision broke these games (but it was in-between r3705 - r3717)
games like Radiata Stories, Star Ocean 2 get minor SPS syndrome
maybe others but they are what i tested so far.
will try to narrow down the exact revision when i get time.

Revision 3718

microVU: bugfix for prev revision (.r and .flag member mixup); and removed an
unneeded check against exactMatch.

Revision 3719

pcsx2 Hw read/write: Instantiate _hwread32 template because it is used in
HwWrite.cpp. It avoids link error when compiler inline template.
Note: inline the _hwread & _hwwrite functions could be a good idea.
Jake.Stine
Don't inline them. Only _hwRead32 should be inlined. All the others are use in such a way that either they're not called often enough, or they're called as part of "return" statements with matching or nearly-matching parameters. When called as part of return statements, most compilers will do the following:
compiled_HwWrite64:
[.. EBP setup ..]
[.. check switch options ..]
@handleFallthrough: // this is the hwWrite32 case
mov edx, [writeValue]
jmp @_hwWrite32_0xx
What happens here is that the compiler knows it can skip the EBP setup, since it was already set up by hwWrite64, and its a __fastcall where ecx has been preserved -- so it doesn't need to do anything there. It just loads edx with the value and then jumps directly into _hwWrite32. _hwWrite32 will then restore the stackframe and return to the code that called _hwWrite64.
So the end result is code that's just one direct jump statement away from acting like an inlined function. (yes its pretty clever!)
It doesn't *always* work out, of course. Sometimes there are stackframe issues that prevent the trick from being implemented; but the compilers seem to manage to use it pretty often in general.
If we forceinline such functions, we'll actually disable the compiler's use of that optimization.
gregory....
Hum ok. Thanks for the explanation
Jake.Stine
I had considered inlining at least _hwRead32, since it is used from all 8 and 16 bit writes; but on the other hand those are still used *very* infrequently; even when being spammed (they max out at like a few dozen calls a frame in the very few games that spam them, and in PCSX2 terms that's pretty insignificant).
Anyway, try this for me if you would:
HwInternal.h:
template< uint page, bool intcstathack >
mem32_t __fastcall _hwRead32(u32 mem);
Add an 'extern':
template< uint page, bool intcstathack >
extern mem32_t __fastcall _hwRead32(u32 mem);
Remove the code added in this change and see if that fixes GCC's linker errors in release builds. My hunch is that it will. It doesn't really matter, and we can keep the explicit instantiation anyways (no harm); but I like to dissect what the compilers are doing to us out of curiosity ;)
Jake.Stine
As a follow-up, I *always* try to add extern to all .h defines; I just forgot to add that one there. >_<
MSVC seems to rely on it for some reason in order to properly inline __forceinline functions (via link-time code gen). If it also fixes the GCC error here, then that would be yet another good reason for always using 'extern' on stuff defined in headers. :)
gregory....
In fact, I previously try the extern. But it did not work. Note to trigger the error, you must pass O2 to gcc (default build is ok).
I'm not sure but I think by default everything in .h are declared extern (maybe C actually). But it is better to give too much than too few to the compiler.
Concerning the issue. When enabling more optimization (well inlining small function), some pages index template does not exist. For example _hwwrite32
(list symbol of the binary): nm -C pcsx2/CMakeFiles/pcsx2.dir/HwWrite.cpp.o|grep -i _hwwrite32
00000000 W void _hwWrite32<15u>(unsigned int, unsigned int)
00000000 W void _hwWrite32<4u>(unsigned int, unsigned int)
00000000 W void _hwWrite32<5u>(unsigned int, unsigned int)
00000000 W void _hwWrite32<6u>(unsigned int, unsigned int)
00000000 W void _hwWrite32<7u>(unsigned int, unsigned int)
Looking at the binary code of hwWrite32<0u> which call _hwWrite32<0u>, the function was inlined by the compiler and so _hwWrite32<0u> did not exists.
Dump with small inline on:
00000000 <void hwWrite32<0u>(unsigned int, unsigned int)>:
_Z9hwWrite32ILj0EEvjj():
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 53 push %ebx
4: 89 cb mov %ecx,%ebx
6: 83 ec 24 sub $0x24,%esp
9: 8d 45 f4 lea -0xc(%ebp),%eax
c: 89 55 f4 mov %edx,-0xc(%ebp)
f: 89 44 24 04 mov %eax,0x4(%esp)
13: 89 0c 24 mov %ecx,(%esp)
16: e8 fc ff ff ff call 17 <void hwWrite32<0u>(unsigned int, unsigned int)+0x17> 17: R_386_PC32 bool rcntWrite32<0u>(unsigned int, unsigned int&)
1b: 84 c0 test %al,%al
1d: 74 0f je 2e <void hwWrite32<0u>(unsigned int, unsigned int)+0x2e>
1f: 8b 45 f4 mov -0xc(%ebp),%eax
22: 81 e3 ff ff 00 00 and $0xffff,%ebx
28: 89 83 00 00 00 00 mov %eax,0x0(%ebx) 2a: R_386_32 eeHw
2e: 83 c4 24 add $0x24,%esp
31: 5b pop %ebx
32: 5d pop %ebp
33: c3 ret
Dump without small inline:
00000000 <void hwWrite32<0u>(unsigned int, unsigned int)>:
_Z9hwWrite32ILj0EEvjj():
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: c9 leave
7: e9 fc ff ff ff jmp 8 <void hwWrite32<0u>(unsigned int, unsigned int)+0x8> 8: R_386_PC32 void _hwWrite32<0u>(unsigned int, unsigned int)
And _hwWrite32<0u> have same code as hwWrite32<0u> so in this case GCC does a good job ;)
gregory....
In last sentence, I wanted to say that _hwWrite32<0u> code (without inline) == hwWrite32<0u> code (with inline)
Jake.Stine
Yeah, MSVC just automatically generates instances for anything that's referenced and puts them in the global manifest. The linker then removes unused functions. It's a case of GCC trying to optimize linker stages by removing stuff that 'might not' be needed (ie its only to do with improving link speeds, wouldn't affect resultant exe).
Don't think the C++ standard makes any promises about stuff being available unless explicitly instantiated, so its not a bug or rule break.

Revision 3720

microVU: clear contents of microBlock on creation to avoid false cache misses.
cottonvibes
this doesn't do anything since the memcpy_const under it overwrites the entire block that was cleared out.
but it doesn't matter about clearing data since the only blocks added with that function are from mVU->prog.IRinfo.block, which is cleared on mVUinit().
It never has bad data...
Jake.Stine
Crap. Ah well. >_<

Revision 3721

debian:
* remove personal rule target: has not worked since last change...
* Some fix to control. Update package std version
micove
Awesome :D, the "diff -Naur" I do is getting smaller. Also not sure if you saw the Readme.Debian edits.
Anyway I will resync the changes and update the changelog.
gregory....
Yes but it seems I forget to add it...

Revision 3722

debian: forgot 1 file
micove
That was quick. Anyway I re-synced and uploaded.

Revision 3723

microVU:
- Fixed xmm reg corruption when calling console print functions from recompiler
(win-vista+ clobber some xmm regs)
- Tweaked and commented regalloc class
konaj...
seems to help the sps in Radiata Stories and star ocean
pcsx2gu...
Star Ocean 3 had SPS? Care to elaborate a bit more (like where the bugs were located) and how much this helped?
kaboo...
this fixed Wild Arms - Alter code F (the geometry bug)
it was fixed some time ago but broke slightly different (geometry was not all the time invisible)
kaboo...
also somewhere in the last 10 revisions the corrupted shadow problem of Persona 4 got fixed nice work <3
konaj...
pcsx2guide, just get r3217 and you can see what i was talking about, in star ocean 3 exit outside of a town and you will get random spikes on the screen as you run around, this revision seems to fix it, I also noticed it happened in alot of games like ff12 international, radiata stories, star ocean 3..etc maybe just been a fluke bug from all the latest updates,
anyways from what I have tested this revision seems to have fixed it.
pcsx2gu...
Oh what you're reporting has probably nothing to do with this revision. There were tons of bugs like that introduced in r3717 and quickly got fixed in r3718.
gladiato...
Pirates of the Caribbean - The Legend of Jack Sparrow is fixed in this svn.
Great.
LDM...
Cottonvibes (Others too if you are willing to help). I hate to have to ask, but since VS2k10 is a bit retarded, I have no choice. Would it be possible for you guys to do one of the following?
1) Cottonvibes: could you update your old site @ http://www.4shared.com/dir/7426412/ed9ca216/re4rainbow4sharedcom.html with new archives. I don't think updating the available beta one the regular site once every 4 weeks is a bad idea.
2) Since the compilation directions on the wiki don't work. Perhaps someone could update them? I was hoping to play with the code some and maybe commit if I find anything useful to improve. Of course, I also want to rifle through the revisions more and enjoy some games at better speed and stability.
I've been reading all the comments since 3119 and seeing what you all are up to. Great work. I'm very interested to see that 1.2x to 1.5x speedup as described in the comments.
FYI: If any one knows why VS is giving me the trouble. Here are the symptoms. It will claim that it can't find files that are already there. I specify as many ways possible for it to include the headers, source, libs, etc, but it can't find them. "Resources/ConfigIcon_Cpu.h" and "zlib.h" are some examples. For the zlib case, if I moved the file to where it was looking for it, that part would pass, but the same was not true with the other example and some modules that depended on zlib.
To make it more worth your (all of you) while, I'll write a graphical guide or video showing how to get enough of it compiled. That way, you won't have to say it twice. I'm not sure what other incentives I could give since I'm not familiar with the source.
cottonvibes
LDMtwo: I never hosted that site, rainbow on ngemu did.
If you are following the compilation guide we have here:
https://code.google.com/p/pcsx2/wiki/CompilationGuideForWindows
It should work.
We don't fully support vs2010 yet so that may be why you're having problems.
The easiest way to compile pcsx2 is to get the vs2008 team suite trial, install it, check-out pcsx2's svn, open up the vs2008 project file, set the build to "Release" and then build it.

Revision 3724

* Move the GIF register handlers from dmac to hwRead/hwWrite (like the VIF
registers they aren't actually DMA-related).
* Minor cleanups to trace logging and FastFormat string stuff.

Revision 3725

newdmac: more progress and trunk synchronizations.
Jake.Stine
Mostly I've added handlers for the DMAC register writes (dmacWrite32), and started adding DMAC changeover/replacement spots where needed.
andrea.c...
just a question for my low knowledge...
problems in booting (especially certain jap games, which show only black at the beginning) are related to dma or to the dvd plugin in general?
pardon me if the question has nothing to do with your work
gregory....
In case we did not see my previous comment on rev 3704.
One assertion fail with final fantasy XII US. I do not see any reason to align 8 bits access. Or did I miss somethings ?
However the 32 bit read must be aligned. This one I'm sure ;)
--- pcsx2.snapshot-3719.orig/pcsx2/HwWrite.cpp
+++ pcsx2.snapshot-3719/pcsx2/HwWrite.cpp
@@ -175,8 +175,6 @@
template< uint page >
void __fastcall _hwWrite8(u32 mem, u8 value)
{
- pxAssert( (mem & 0x03) == 0 );
-
iswitch (mem)
icase(SIO_TXFIFO)
{
@@ -204,7 +202,7 @@
return;
}
- u32 merged = _hwRead32<page,false>(mem);
+ u32 merged = _hwRead32<page,false>(mem & ~0x03);
((u8*)&merged)[mem & 0x3] = value;
_hwWrite32<page>(mem & ~0x03, merged);
Jake.Stine
Yeah that's a copy-paste error. Your patch is correct, and the hwWrite16 should mask with ~0x01 in case I missed it there as well.

Revision 3726

IPU: Split IPU DMA stuff out into its own file, and add missing region info (got
left out AGAIN >_<) and a potentially important bit of IPU information to the
savestate.

Revision 3727

Changed SIF and IPU macros for hw register mappings into references. (-> into
.)
gregory....
Hum, is there a reason why *write128/*read128 are called with mem and not with mem & ~0xF.
Jake.Stine
nope, it's a 'woops'

Revision 3728

Simplified CPU-level exception behavior:
* Both INTC and DMAC exceptions are now issued together when possible (0x400 |
0x800 to the CAUSE register, respectively)
* CPU exceptions are checked on every event now, instead of using scheduled
interrupts on bits 30/31. This removes the need to constantly reschedule events
during interrupt-disabled states.
* CPU exception test is moved to the top of the EE event test.

Revision 3729

GregMiscellaneous: sync from trunk (3679:3727)

Revision 3730

* Rename cpuBranch[...] functions and vars to cpuEvent[...], which should be
more clear and consistent as to their true purpose. (to clarify: events
typically run during cpu branch instructions, but most branches don't actually
have anything to do with whether or not there are events pending or events being
run).
* Add some missing & ~0x0f address alignment stuff to odd-size FIFO
reads/writes (thanks gregory)

Revision 3731

GregMiscellaneous: zzogl: rework fullscreen (to be friend with the WM). Note: it
is not crash free for the moment.
* use alt-enter to toggle the fullscreen mode. (toggle quickly multiple time to
crash it...) I suspect need of XLockDisplay & XUnlockDisplay
* escape: will quit for both mode
Not yet done:
* good support of fullscreen conf flag. Which is wrong for the moment. (actually
may be a source of crash)
* Better support of widescreen screen

Revision 3732

GregMiscellaneous: zzogl: add some locking. Work far better.
The trick was to call XInitThreads in the beginning.
Jake.Stine
Yeah that should help stability in general given the multithread nature of all of pcsx2.

Revision 3733

newdmac: sync with trunk (3726-3730), and removed early-stage code comments
(subplanted by newer more accurate info)
Jake.Stine
Hopefulyl this will be the last trunk sync for a while. I kept running into refactoring jobs that I knew would make my life a merging hell if I didn't put them into trunk and then merge them over to the branch. >_<

Revision 3734

GregMiscellaneous: zzogl: Fix fullscreen setting & remove useless library
Major issue left: widescreen.
arcum42
Seems mostly good. Crashes when I hit escape, but so did the old version. The text on the window for messages doesn't seem like it clears properly. I'll have to look at that...
gregory....
Hum, I do not think you can make shutdown properly. When the thread is closing the display and co. PCSX2 still send some others cmd/data.
I'm in favour to drop the fullscreen configuration. (just keep a start in fullscreen). To exit user can just go back to windows mode (fast and do not crash) then exit.
The real issue is how handle fullscreen on widescreen (keep 4/3 ratio). For the moment it takes all the screen. Well for the moment it glitches. Explanation follow.
GLWindow::ResizeCheck() call ZeroGS::ChangeWindowSize(max width, max height). This function does not update conf.width/height in fullscreen (only the buffer). And ZeroGS::AdjustTransToAspect does some computations based on conf.width/height. I think it will be better to use glwin.width/heigh which is the real size of the window.
Hum, previous fullscreen shrinked the desktop to the window. Now it enlarges the window to the desktop. It is still possible to update properly conf.width/heigh in resize check function in my opinion to avoid conflict with MS behavior.
Note: when leaving fullscreen, WM restore previous window size and position
arcum42
And then there's nBackBufferwidth & nBackBufferheight, which seem to be used in a few places, too. Too many places with width & height, really.
And yeah, we should either use the real width/height, or make conf have the real width & height. Or both.
Dropping the fullscreen configuration in favor of doing it on the fly, and getting rid of escape (or making it just drop out of fullscreen) isn't a bad idea. (And restoring the previous window size/position is probably what it should do...)

Revision 3735

GregMiscellaneous: zzogl: Got rid x & y in GLWin. Make sure nBackBuffer gets set
to the right width and height.
arcum42
Sorry, should either be Got->Get or Make->Made in the description...

Revision 3736

Remove fullscreen from the configuration dialog, and make esc go back to
windowed mode.
arcum42
Should have been tagged "GregMiscellaneous: zzogl: ". Also, I left conf.fullScreen in for the moment, just to make things simple.
gregory....
Arcum, I think that the window size parameter can be dropped.
Just set a default value (let's said 800x600) if the config file is empty. Otherwise restore the previous value.
User can still resize the window anyway.
arcum42
Not a bad idea. And I can always change it back later if there's enough demand.
I suspect I'll have to bring Windows into sync with Linux after a bit, too. I'll probably do that in a few days...
(Eventually, we'll want to bring the fullscreen changes back into the trunk from this branch, but that can wait till we're done fiddling with them for a bit. For that matter, we might want to bring the skipframe changes back in, too.)
arcum42
skipframe->skipdraw
gregory....
I think the code is in pretty good shape now. I do not plane any further change for the moment. Except the flash border in full screen mode (wide screen enabled). Probably located somewhere in gl rendering call.
arcum42
Yeah, it seems like it is. And while the border issue is irritating, I can live with it in trunk for a while. I'll plan to bring the changes to zzogl in this branch back into trunk sometime in the next few days.
Before I do that, I'll probably tweak the dialog box a bit more, though...

Revision 3737

GregMiscellaneous: Minor clean

Revision 3738

Minor fix from yesterday's IPU refactoring (fixes some homebrew stuffs)

Revision 3739

GregMiscellaneous: zzogl:
* add more locking to X11. Never too safe.
* Free the visual (memory leak)
* Only search event of the current window
* force 4:3 in fullscreen mode (will need a toggle box to enable/disable it)
* do not grab cursor on debug (this one will need more test)
gregory....
Hum last big step is to print a big black frame when going fullscreen to obtain nice black border.

Revision 3740

GregMiscellaneous: zzogl:
* restore widescreen option. Force a 4/3 mode when disabled.
* Also force 4/3 in window mode. In widescreen and fullscreen uses all the
screen.
* Clean

Revision 3741

Remove some obsolete code relating to VIF/GIF FIFOs (hwRead/Write handlers
always intercept them now, so saving values back to the eeHw register mirror is
ineffective).
suluh.le...
I think you missed putting a (u64*) in FiFo.cpp line 56; it wouldn't compile under a clean build.
SAMuham...
Compiler generating
1>..\..\FiFo.cpp(56) : error C2664: 'void (u64 *)' : cannot convert parameter 1 from 'mem128_t *' to 'u64 *'
1> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Please give a second look..
suluh.le...
Just add (u64*) before 'out' so that it becomes...
GSreadFIFO((u64*)out);
...and then it'd compile fine.
Though I don't know if that's the intended parameter type or not.

Revision 3742

GregMiscellaneous: zzogl: Remove screen size settings from the configuration
dialog. (The window can be resized normally, and the startup size can be changed
in the ini file still...)
arcum42
This will still need to be cleaned up later. And, if need be, I can always add this back in again later...
gregory....
Little question on Anti-aliasing. There are some functions to do negative AA : the top one is ProcessNegAASetting which is never called.
In case the code is really useless (no plan to use in the future), RH and RW functions could be reduce to only a register shift. It can give a small boost. Any opinion ?
Note: I have the patch if needed.
arcum42
Zeydlitz put that in and mapped it to the F7 key at one point, and then later removed it. It's not currently used. Not sure if there's any reason to bring it back or not.
Of course, it might be interesting to do aa the way GSdx does at some point. (set the width & height rather then 2x, 4x, etc...)
(And if you want to see something ugly involving anti-aliasing, take a look at ZeroGS::KickSprite() in zerogs.cpp. Specifically the lines involving s_AAx & s_AAy... )

Revision 3743

GregMiscellaneous: zzogl: Restore the good size when quit fullscreen.

Revision 3744

(u64*) [compilation error fix]

Revision 3745

Fix for some major slowdowns present in dev/debug modes when using trace logging
features.

Revision 3746

* Simplified VIFunpack's C-based interpreters (removed ODD size handlers and
unused data)
* Fixed V2/V3 unpacks to behave same as the SSE unpacks (matches undefined PS2
behaviors)
* Removed legacy vifUnpacker (haven't needed it for any regression testing in
forever).
* Move some VIF MARK console spam to DevCon (Ape Escape 3)
cottonvibes
Nice
godofdr...
i have a problam in god of war 2 pal after killing the barbarian king in some place its loading forever i wonder if you can fix it if yes type it in your new revision r3747 and thanks your emulator is great work really
refraction
Hmm wont this bugger up split unpacks? the point in the whole offset checking was it could break on the Y offset then when it comes back it resumes on Z, but this will just go from X again if i read it right?
if not, well done :P X-Men is a good game to check this.
Jake.Stine
Split-packet unpacks are merged together using a 1mb buffer, so the packets the actual unpackers receive are always complete (no partial offsets to worry with). The old vif stuff didn't do that, of course, so it needed the 'ODD' size stuff.
I'm contemplating the removal of the 1mb buffer and replacing it with a 128-bit buffer instead (enough to concatenate any single split unpack); I think I can do so without making th code any more complicated.
Jake.Stine
Actually, no. Trying to process partial packets really is just more work than it's worth (its doable for skipping writes without undue complication, but filling writes throw monkey wrenches in all over the place as usual). Looks like the 1mb buffers will stay.
cottonvibes
Yeh handling partial packets with the dynarec makes it a lot more ugly (and slow) which is why i used the 1mb buffer for the full list of unpacks.
(it makes it slower because you also have to include partial-packet size information into the cached dynarec blocks)

Revision 3747

GregMiscellaneous: zzogl: Clean up the configuration dialog code a bit. Make the
experimental skipdraw option only exposed on devel builds.

Revision 3748

Lets go ahead and bring the changes to zzogl-pg in the GregMiscellaneous branch
into trunk.
arcum42
I still need to bring the Windows version in line with Linux on the GLWin changes, and I saw at least one bug in the fullscreen implementation[1], but I figure those can be ironed out in the main trunk...
[1] For me, at least, I saw the width and height change for the ZZOgl window after switching back and forth between fullscreen a few times.
gregory....
Could you try this patch
Index: pcsx2.snapshot-3746/plugins/zzogl-pg/opengl/GLWinX11.cpp
===================================================================
--- pcsx2.snapshot-3746.orig/plugins/zzogl-pg/opengl/GLWinX11.cpp
+++ pcsx2.snapshot-3746/plugins/zzogl-pg/opengl/GLWinX11.cpp
@@ -227,7 +227,7 @@
XUnlockDisplay(glDisplay);
// Apply the change
- XSync(glDisplay, False);
+ XFlush(glDisplay);
// update info structure
GetWindowSize();
arcum42
Aside from artifacts during the transition from fullscreen to windowed mode, looks good. (Mainly it looks like it redraws with the new width & height in fullscreen mode before going to a window...)
gregory....
Hum, I do not really see them (or they are very short). Not sure it can be fixed.
The issue is multi-thread. ZZogl keep drawing during the resize. So in the middle of a frame rendering, you change buffer and window size... Hopefully few frame later it return to a stable state.
You can resize the back buffer with false value (800x600) before the transition, perhaps that will reduce these artifacts but it is clearly a hack.
arcum42
It's short enough that I'm not going to worry about it too much. Especially since it looks like Zeydlitz has been doing some major work that I should probably bring in...

Revision 3749

zzogl-pg: Add the new files to the Windows project.

Revision 3750

zzogl-pg: Sketch out some dialog box changes in Windows for later.

Revision 3751

zzogl: Misc cleanup.

Revision 3752

zzogl: Not sure how these didn't get copied in properly. :(

Revision 3753

zzogl: flush instead of sync to be sure the size is correct

Revision 3754

ZZogl-pg: Commit some of the work Zeydlitz did in r226 with separating out
shader code.
arcum42
And, yes, I know that there are 7 more revisions or so of shader work I haven't added in. I figured I'd be better off adding this in first rather then tackling it all at once...
arcum42
(And I did manage to get all the shader work copied in, but neither shader works in that copy of the trunk, so I'll set it aside for a bit...)
Zeydl...
Well, you must be aware, that GLSL shaders are not work properly yet, but Cg ones should be o'k.
arcum42
I figured the GLSL shaders wouldn't work yet. The Cg ones weren't working for me either for some reason. I ended up with a black screen that occasionally changed colors. :(
It was a pretty complex merge, though, so I may have botched something in it at some point...
gregory....
It is really a good things for linux package. Cg is not truly open-source.
Anyway, Zeydlitz did you use OpenGL 3 functionality ?
Zeydl...
Yes, I do. First at storage format: OpenGL 2.0 variant store picture in GL_ALPHA16 (u16) format, new cards use RGBA_32F (float single precission) that's more accurate. Second, in GLSL shaders I use OpenGL 3.0 manual (first I try 4.2, it have program pipeline, that's stuff I really want to use, right now I do two much relinking, but ATI don't support 4.2 yet).

Revision 3755

zzogl-pg: Search and replace on a few things.

Revision 3756

zzogl-pg: remove negative AA. Save some cpu cycles.

Revision 3757

debian:
* drop libxxf86vm-dev dependency
* do not twice the link

Revision 3758

zzogl-pg: Remove some remanents of negAA. Mess with the aa code a bit. Add a
function for a commonly done operation. Increment the version, since I haven't
done that in a long time.
arcum42
Oh and I noticed something that had been accidentally committed and reverted it...

Revision 3759

zzogl-pg: Lets remove the xf86vm library dependency from the codeblocks project
while I'm thinking of it...

Revision 3760

zzogl-pg: Having two functions with the same name, one of which is in a
namespace, and one of which isn't, strikes me as a bad idea.
gregory....
One question about -fno-regmove on zzogl. Was it a crash everywhere or crash in special game scenes ?
I think it will worth to test without. I fixed some asm constrains. I bet that was the main issue.

Revision 3761

cmake:
* Link zz with libjpeg. Well it seems to get the library from another place, but
better be safe for the future.
* Use -pthread as a default option (again to be safer)
* Warn about breaking of strict aliasing rule

Revision 3762

Significant VIFunpack retooling. Interpreters are considerably more efficient,
and Recompilers are slightly more efficient. Details:
* All remaining code for handling partial/fragmented unpacks removed.
* vifRegs.NUM is now accurately simulated when queuing data from fragmented
unpacks.
* Reduced the VIFunpack fragment buffer from 1MB to 4KB (max size of an unpack
due to NUM being limited to 8 bits).
* Removed vif/vifRegs globals formally used by VIF interpreters (everything
relies on the templated vifIdx now -- simpler and faster!)
* g_vifMask vars are integrated into vifStruct.
* All VIF mask register stuff uses the SSE-friendly vifStruct.MaskRow/Col vars
now.
shadowladyngemu
bugged "Buffy: Chaos bleeds" which is Vif problematic as far as I know
r3746: http://img412.imageshack.us/img412/9647/92375626.jpg
r3762: http://img638.imageshack.us/img638/7435/25501036.jpg
I'll check other games.
Jake.Stine
Tri-ace also having issues. I should have them resolved shortly.

Revision 3763

GCC compilation fixes.
(note to devs: a sure-fire fix for GCC's templated function problems is to
typecast the templated function to itself explicitly -- works nicely for all
versions of GCC and the ?: operator as well).

Revision 3764

... and update the savestate version, since I changed all the vif containers
around.

Revision 3765

Bugfix for Tri-ace games and possibly others (bug introduced in r3762, caused by
missing 'vifRegs.num is actually 256' checks)
shadowladyngemu
Fixed buffy too.
ramapcsx2
Quick test with SotC and VP2 shows a speedup due to the retooling.
72 vs 68FPS in VP2, 52 vs 50FPS in SotC.
:)
Jake.Stine
Yay, FOR ONCE! lol
I'm surprised it made that much of a diff on the recompilers enabled. That gives me new hope for my DMAC overhaul, since it cuts the overhead of dispatching Unpacks by half or more.
system.compiler
I know nothing about the code but if it give more speed(even only 0,5 FPS) or more compatibility or even easier to manage code or whatever else which is better for pcsx2 development... an end user like me would be really happy.
Bravo PCSX2 Team.
HarisKur...
Resident Evil Outbreak Casefile 2 works almost perfectly now, thanks team! <3

Revision 3766

zzogl-pg:
* Allow to load the plugin without log (better but not mandatory)
* Only reload the log file when it was open in the first place

Revision 3767

zzogl-pg: fix a potential issue when logging is disabled
arcum42
Given that those particular logging messages only come up if you uncomment a define, and it's one you would never uncomment if you were turning off logging, it's unlikely. It *could* happen, though... ^_^
godofdr...
whin you allredy fix the bug in god of war 2 pal loading problam and saving game bug
gregory....
Yes, actually I do not know how to activate it ;) I just check the code after my previous commit and saw it.

Revision 3768

zzogl-pg: Work on getting the ZZoglShaders header a bit closer to what is in the
current zzogl trunk.
arcum42
I decided to approach adding the new shader stuff a bit slower this time. I'll add the glsl stuff after most of the other changes are made...
gregory....
Yes it is a good idea. GLSL is a very big update.
Zeydl...
LoadEffects are no need to be in headers -- it's call inside just an ZZShaders.cpp. And I rename LoadShadeEffect, because Flush use it to properly set a fragments shader for texture (with depth test, repeat mode and so on include).
arcum42
I saw that; I just hadn't applied that change yet...
On a related note, I've been thinking about entirely getting rid of the ZeroGS namespace. It doesn't seem needed, or that coherent about what's included in it and what isn't.
I figure anything that needs to be grouped together afterwards can get it's own namespace or class...

Revision 3769

GregMiscellaneous: sync and refresh the branch (3728:3768)

Revision 3770

GregMiscellaneous: zzogp-pg:
* Replace some macro by basic functions. Use a switch to emulate the ##.
* merge similar functions
gregory....
My idea was to play with template stuff. But it is overkill for this simple code.
gregory....
Note: I did not inline the function because they are only call at startup. So better keeps place in the cache.
arcum42
One of my goals for a while had been to get all the macros out of Mem.cpp, and that was pretty much the remaining chunk that was left. Good work...
gregory....
Thanks.
Now, I am playing with RESOLVE_32_BIT (much more difficult than this one ;))
arcum42
Yeah, that was another one that I've been putting off for a good while because of how complex it was. (and you'd be surprised how many macros have already been removed from the code. Zerofrog was a little macro happy...)
Note that I simplified it; the #if 0'ed code below it is what used to be there. I just removed part of it that had been disabled at some point...
arcum42
But then, come to think of it, I noted that in the code. ^_^
gregory....
Yes seem to be a macro man. Actually I just saw x86.cpp and got an heart attack ;)
arcum42
Yeah, those were pretty bad, too, I just never got to them.
And the reason for most of the templates in the Mem area is because of removed macros. Some time, look at the same area of code in ZeroGS if you want to get an idea. (Or the non-pg version of ZZogl; I don't think Zeydlitz has brought that over yet...)

Revision 3771

IPU optimizations -- use SSE for FIFO reads/writes, and streamlined IPUdma0
/IPUdma1 feeds a bit.
ramapcsx2
5% speedup in Ys :)

Revision 3772

GregMiscellaneous: zzogl-pg:
* Remplace RESOLVE_32_BIT with a nice template (only a 8bytes format for the
moment, the others part is not used anyway)
* copy the function RGBA32to16 due to 'missing external linkage' ???
* Remove trailling space
gigaherz
hmm wouldn't "missing external linkage" refer to the functio not being declared as "extern" everywhere?
also you don't NEED to tell you removed a space in the logs XD
gregory....
Well, it just to said to filter white space when doing the diff (not sure it can be done on windows).
Thanks for the tips.

Revision 3773

GregMiscellaneous: zzogl-pg:
* Properly fix the 'missing external linkage' thanks to Gigaherz.

Revision 3774

GregMiscellaneous: zzogl-pg: Mega clean of zerogsmath.h (1000 lines to 80...)
which is good because the file does not have a clear copyright status.
It remains mostly trivial things and basic vector operations.
ramapcsx2
Oh my gosh.
#define PI ((dReal)3.141592654) << warez'd PI! xD
arcum42
You know, that's about how many digits I usually remember of pi off the top of my head, too...
gregory....
I'm sure they are lots of patent to compute PI decimal ;)
arcum42
I think what is left is trivial enough not to worry about it. Though you could always reimplement, or copy the equivalent code from GSdx (in GSVector.h).
Oh, and that "SetColor" function didn't used to be in zerogsmath, so it's GPL'ed. ^_^ (The code came from zerogs.cpp...)
arcum42
For that matter, you could practically drop this code in:
http://bartipan.net/vmath/doc/vmath_8h-source.html

Revision 3775

GregMiscellaneous: zzogl-pg: Expand out the swizzle defines in x86.cpp.
arcum42
I'm sure this code could be shrunk, but I figured the first thing was to get rid of the defines. Though noticing the first two functions were identical was useful...
arcum42
Actually, it just occurred to me that the only code that uses those functions is commented out anyways. Oh well.

Revision 3776

GregMiscellaneous: zzogl-pg: #if 0 this code out, so I don't forget that it's
currently not called again.

Revision 3777

IPU fix for GUST games
frost....
What are GUST games?
arcum42
Games by Gust. Atelier Iris 1-3, ar tonelico 1-2, Mana Khemia 1-2, etc...
ramapcsx2
Games that use a specific IPU feature that's rarely used anywhere else.
It often breaks due to general IPU issues ;)
gregory....
I love rama description :)
ramapcsx2
Lol, thanks :D
I guess it's my talent for not saying anything _specific_ ever :p
serban.a...
sometime after revision 3771 the movies of shin megami tensei devil summoner 1 & 2 and digital devil saga 2 are hanging.i guess it has to do with your revusuib jake since the other revision are connected to nothingelse than ogl

Revision 3778

GregMiscellaneous: zzogl-pg:
* Remove support of 16bits pixel. Very slow and same quality that 8 bits.
* Fix a compilation error on debug...
Zeydl...
well, TextureRect(4, fbw, fbh, GL_RGBA, GL_UNSIGNED_BYTE, NULL) -- it's a bad code. 4 is GL_RGBA enumerator value, and why Zerofrog use number (and no one is guaranted, that 4 would be always GL_RGBA.
Also you should kill RFT_byte8 value to -- it's enumerator for GL_UNSIGNED_BYTE enumerator. Completely useless.
gregory....
Ok. Honestly I look into the 2.1 SDK but I did not found the correct value. I will update them.
But did not understand the 2nd parts. There are no more RTF_byte8 things except one enum I have forgotten.
gregory....
Now that I'am in the mood to remove everything ;)
Did glprocs.c and glprocs.h have any utilities ?
arcum42
I was able to compile without them in codeblocks...
It appears to be some Mesa source code generated by glprocs.py, but I'm not really sure what it's used for.
gregory....
Not sure why I did not see before... Anyways, the .h is include in some files (ZZGl.h and Util.h) but windows only.
arcum42
All right, so we'd better keep it for the moment, then, until we can see if it can be untangled from Windows...

Revision 3779

GregMiscellaneous: zzogl-pg:
* #if 0 some codes that are not called anymore.

Revision 3780

GregMiscellaneous: zzogl-pg: 'Transfer error, width exceeded.' spams a little
too often for me. I'm making it Debug build only.

Revision 3781

GregMiscellaneous: zzogl-pg:
* replace magic number with a symbolic name
* Remove 16 bits texture survivors.

Revision 3782

Minor compilation fix.
arcum42
Gcc gets cranky if both arguments of min aren't the exact same type. Though I would have thought OFC would have already been considered a uint...

Revision 3783

zzogl-pg: Bring a few of the changes in the GregMiscellaneous branch into the
trunk.
arcum42
Namely, I brought in the #if 0'ed swizzle code, the ZeroGSMath changes, and the "Transfer error, width exceeded." change.
I'll wait on the other changes until they've settled down a bit and have gotten some testing...

Revision 3784

zzogl-pg: Majorly revise the Windows config dialog box. (May still need more
work.)
arcum42
I need to look at the code for setting window dimensions a bit more...

Revision 3785

zzogl-pg: Mess around with the Windows code a bit more.

Revision 3786

zzogl-pg: Renamed Vector to float4 & renamed zerogsmath.h to ZZoglMath.h.
(Continuing to work on bringing zzogl-pg in sync with recent revisions of
zzogl.)

Revision 3787

zzogl-pg: More sync changes. (See r3768 & r3786)
arcum42
Some of this was pretty much copying and pasting, which is why occasional grammar fixes and formatting changes may have gotten reverted...
suluh.le...
MSVC had errors compiling ZZOgl in this rev; was fine in 3786.
Both were compiled under a clean build.
..\ZZoglShaders.cpp(190) : error C2065: 'hInst' : undeclared identifier
..\ZZoglShaders.cpp(190) : error C2065: 'IDR_SHADERS' : undeclared identifier
..\ZZoglShaders.cpp(192) : error C2065: 'hInst' : undeclared identifier
Maybe something got 'mispasted'...?
Sorry about the negative if it's already being looked at.
arcum42
Actually, it's mainly just that I only tested it in Linux, and not Windows.
ZZoglShaders.cpp is a fairly new file, and the includes it has are probably enough to bring everything in in zzogl, but I've spent some time pruning down headers in zzogl-pg.
Both hInst & IDR_SHADERS are Windows-specific, so I wouldn't have noticed them till the next time I went into Windows...
arcum42
I haven't tested it yet, but r3794 probably takes care of it...

Revision 3788

IPU : Removed the MPEG internal 32 bit buffer and all associated logic for
"rewinding" bits out of the buffer and back into the IPU's internal 2QWC buffer.
Simplifies IPU's bitstreaming code quite a bit, but isn't really much faster
(yet).
(savestate version upgraded)
arcum42
Hmmm... looks like gcc doesn't honor the aligned attribute if you write " __aligned16 struct tIPU_BP", and wants it written as "struct __aligned16 tIPU_BP". Just a warning, but I'm assuming we want that structure aligned...
Jake.Stine
Yeah and it doesn't matter. The strust is only used once, and the global var is aligned as well. I was just feeling paranoid at that moment before I committed, for some reason. :p
arcum42
A little paranoia is a good thing...
Jake.Stine
Ok, thanks. I'll check it out.
konaj...
I can also confirm the Haunting Ground cut scene skips.
Jake.Stine
I checked all the intro and game starting cutscenes in Haunting Grounds [NTSC is my copy], everything worked fine. Is it only cutscenes further in-game or something?
Jake.Stine
ok I figured it out -- first in-game cutscene where she gets her clothes. This isn't even an IPU cutscene -- it's using the in-game graphics engine -- have no idea yet how its being affects so bizarrely.

Revision 3789

newdmac: lots more work. Things are getting heated now. (and no, nothing works
yet so don't even bother trying to compile/run it)
arcum42
NewVif.cpp is a totally blank file? I take it it's a placeholder of some sort?
Jake.Stine
Oh, woops. I added it but then I ended up adding everything into Vif.cpp instead. I'll have to back and remove it again :p

Revision 3790

newdmac: sync with trunk.

Revision 3791

newdmac: giving the branch a proper svn name.
Jake.Stine
Hopefully this works. If not I can always continue using the old branch.
SNP_Tira...
Not sure where I'm supposed to post this, so I'll just post it here.
From Pcsx2Types.h:
bool operator!=( const u128& right ) const
{
return (lo != right.lo) && (hi != right.hi);
}
Shouldn't it be '(lo != right.lo) || (hi != right.hi)'?
Same for s128, for that matter.
Ragha...
(a != b) && (c != d) = 1 -> a = b
00 00 0e -> 0
00 01 0e -> 0
10 01 10 -> 0
10 11 11 -> 1
if(00 != 01){ never happens
}

Revision 3792

GregMiscellaneous: zzogl-pg:
* Update f_0(a) function to call f(a,0).
* Add a dbg message on Resolve_32_Bit to track some slowness.
Zeydl...
Yes, Resolve_32 is sensationally slow. I was not able to find a reason, but maybe you be lucky.
gregory....
My opinion, the 500x500 double loop. And the worst lots of IO memory and probably dst read/write access which are random (not n,n+1,n+2...) if I'm correct.
gregory....
Hum I have maybe some idea to reduce cpu usage. Need to find how benchmark it properly (I thinks I will add some time info).
One question : could some of these hypothesis be valid ?
fbw %64 = 0
fbh,maxfbh %32 = 0 (32 bits) or %64 = 0 (64bits)
The idea will be to test a quad loop.
gregory....
Ok I tune some stuff in r3799. No real impact but cannot be slower.
I thinks most of the slowness come from cache miss and co. Anyway I still have 2 others ideas to reduce computing of dst address.
dst = (u32*)pPageOffset + (u32)Basepage(x,y,bw) + (u32)g_page_table(x,y).
Idea 1/ precompute a table of u32* lut_table(x,y) = (u32*) + (u32)g_page_table(x,y)
It can be done with sse2 instructions. So it can be done fast enough. Gain expected 1 instruction in core loop (but not guarantee), but will impact memory transfer.
Idea2/ Unroll the inner loop. And compute 4,8 or 16 dst (depends fbw%n =0)
Advantage: Basepage will be computed once for n values. Basepage is around 30% of the instruction of the inner loop. Moreover it will reduces the inner loop overhead (which is called ~400 times).
Any opinion ? I will probably do some testing with the 2nd idea.
gregory....
Hum, one things to check is that g_page_table(x,y) is access in continuous memomy.
arcum42
Just to note, GSLocalMemory.h appears to be where GSdx keeps it's equivalent of all the getPixelAddress stuff. It looks like it creates lookup tables in GSLocalMemory.cpp when initialized, and then uses them:
static __forceinline uint32 PixelAddress32(int x, int y, uint32 bp, uint32 bw)
{
uint32 page = (bp >> 5) + (y >> 5) * bw + (x >> 6);
uint32 word = (page << 11) + pageOffset32[bp & 0x1f][y & 0x1f][x & 0x3f];
return word;
}

Revision 3793

GregMiscellaneous: zzogl-pg: try to fix automatic hack that dissapears
* Force the setting of the auto hack after GS was closed
* Always enable path3 hack
gregory....
For path3, the hack does not appears in the gui so you can not enable it. And the gui set hack to 0 and add hack that are enable (so not this one).
Also a side effect: automatic hack can not be removed (maybe on the fly with keyboard).
Zeydl...
Path3 hack is not need from a half-year ago, when transfer was slightly redone. I not sure if this hack have at lease a bit of code.
arcum42
It still does have a line left in GifTransfer, as I recall. Just every time I think about it, I'm usually in the middle of something else, and forget about it...
arcum42
OTOH, the "No Color Clamp" hack doesn't do anything. The only line I saw using it was removed in r3778.

Revision 3794

zzogl-pg: Add some includes in ZZoglShaders for Windows.

Revision 3795

Compilation fix.
suluh.le...
Yup, this fixes compilation in Windows; thanks. =)

Revision 3796

GregMiscellaneous: zzogl-pg(Linux): Revise hack config dialog not to include
options that don't do anything. Clean up the descriptions a bit. Add comments
indicating what hacks aren't in the dialog, and whether they are implemented or
not.
arcum42
The hacks that have games listed by them really should be tested with those games to see if they do any good any more.
(Resolve Hack #1 may speed Kingdom Hearts up, but also causes visual glitches, IIRC. Which is why it isn't on by default. And I haven't seen an issue with Gradius 3 with no hacks on, so I wonder what Interlace x2 is all about...)
The option I removed from the list was 'no color clamp', incidentally.
And the texa hack, the path 3 hack, and the vss hack are all implemented but can't be chosen, so either the hack should be added to the list, or the implementation removed.
I'm leaning towards the latter.
arcum42
Oh, "Partial Pointers" was also removed.
arcum42
Never mind the comment on Gradius 3. I spaced on the fact that I have Gradius 5, not 3. :(
gregory....
In the end path3 useful or not ^^ If not, the auto enable that I set in setcrc must be removed.
arcum42
Looking through GSdx, the path3 code there has been mostly removed, and would no longer do anything. So I think we're probably best off removing it.
arcum42
Since I've just been looking at that code, I'll go ahead and remove it...
arcum42
See r3798.

Revision 3797

GregMiscellaneous: zzogl-pg: Tweak the hack list controlled by F9 not to have
unimplemented hacks, as well.
arcum42
Note that the ones not in the dialog box are still in this list. I left them in because it'll be easier to determine if they do any good if there's still an easy way to turn them on.

Revision 3798

GregMiscellaneous: zzogl-pg: Remove path3 hack.
serban.a...
i think too much attention for zzogl and for gsdx nothing too important since gabest forgot us
arcum42
Well, if you'll look at who's doing most of the work on zzogl, you'll notice that it's mainly me and gregory. And you'll note that the two of us are the two developers using Linux, thus, the two developers who do not use GSdx.
You can also see it as indicative that zzogl needs a lot more work then GSdx. ^_^
Besides, we've been missing zerofrog a lot longer then GSdx has been missing gabest...
serban.a...
i understand .maybe zzogl in the future will be better than gsdx ..who knows..since gsdx its kind of forgotten by his "father" gabest:))

Revision 3799

GregMiscellaneous: zzogl-pg:
* Some boost tuning: do big loop in reverse order.
* Add a function to get ns timing. Could be useful for benchmark.
gregory....
I also inline SET_VERTEX function. It was in the top5 in my oprofile report (time spent). The function is not big, so it was probably lots of time.
arcum42
I think that function may have been a macro at some point, so it probably should have been inlined anyways.
And that is where the texa hack code is, and that was on my list of hacks which you couldn't choose from the dialog. So we could probably justify commenting out the "if (conf.settings().texa)" section...
Zeydl...
SET_VERTEX was not an macro, it's real boy, that translate PS2 vertex into Zerofrog's VertexGPU. Don't touch it without consulting an manual, it could be dangerous,
p.S. TEXA is emulated on part of PS2, that really weird - alpha value correction.
arcum42
Actually, it was at one point. (From ZeroGS r382):
#define MOVZ(p, gsz) p.z = curvb.zprimmask==0xffff?min((u32)0xffff, gsz):gsz;
#define MOVFOG(p, gsf) p.f = ((s16)(gsf).f<<7)|0x7f;
#define SET_VERTEX(p, Index) { \
int index = Index; \
p.x = (((int)gs.gsvertex[index].x - curvb.offset.x)>>1)&0xffff; \
p.y = (((int)gs.gsvertex[index].y - curvb.offset.y)>>1)&0xffff; \
/*x = ((int)gs.gsvertex[index].x - curvb.offset.x); \
y = ((int)gs.gsvertex[index].y - curvb.offset.y); \
p.x = (x&0x7fff) | (x < 0 ? 0x8000 : 0); \
p.y = (y&0x7fff) | (y < 0 ? 0x8000 : 0);*/ \
p.f = ((s16)gs.gsvertex[index].f<<7)|0x7f; \
MOVZ(p, gs.gsvertex[index].z); \
p.rgba = prim->iip ? gs.gsvertex[index].rgba : gs.rgba; \
if( (g_GameSettings & GAME_TEXAHACK) && !(p.rgba&0xffffff) ) \
p.rgba = 0; \
if( prim->tme ) { \
if( prim->fst ) { \
p.s = (float)gs.gsvertex[index].u * fiTexWidth[prim->ctxt]; \
p.t = (float)gs.gsvertex[index].v * fiTexHeight[prim->ctxt]; \
p.q = 1; \
} \
else { \
p.s = gs.gsvertex[index].s; \
p.t = gs.gsvertex[index].t; \
p.q = gs.gsvertex[index].q; \
} \
} \
} \

Revision 3800

GregMiscellaneous: zzogl-pg: Use _aligned_malloc in GetMemoryTarget.
Zeydl...
I am deeply sorry, but no chance. malloc lead to heavy slow down. As I hear, Linux start swapped something with this malloc.
arcum42
All right, I'll revert and remove the suggestion about _aligned_malloc, then...

Revision 3801

GregMiscellaneous: zzogl-pg (Linux): Bilinear has 3 states, and therefore should
probably not be represented by a checkbox in the configuration dialog box.
arcum42
I was noticing that it could be set to off, normal, or forced, but in the dialog box, it was only off or on. Before, you had to use shift-F5 to access all three states...

Revision 3802

GregMiscellaneous: zzogl-pg:
* Fix my previous stupid limit...

Revision 3803

GregMiscellaneous: zzogl-pg: Revert r3800.
Zeydl...
Well, probably I know the reason of swaping -- we do malloc, but does not do proper free. So if made free for MemoryTargets destructor, it may be o'k.
arcum42
I suppose we could add a pointer into the struct for it, use that pointer, and do an _aligned_free on it when the target is destroyed...
Zeydl...
ptexdata should not be keep in memory after it was bind to texture (OpenGL copy it itself).
You should to trick like:
ptexdata = (u8*)_aligned_malloc(4 * targ->texW * targ->texH, 16);
was_allocated = true;
and before return
if (was_allocated) _aligned_free(ptexdata);
You should keep in mind, that not every branch have allocation and this function have 2 exit points after allocation (end of the function -- return targ and return NULL).
arcum42
That, and the other thing that threw me, I think, was sometimes it gets passed ptex->memptr, which we shouldn't deallocate in that function.
I'll try approaching it that way. For some reason, I was thinking that when it was bound to a texture, that opengl was grabbing a pointer to it rather then copying it...
arcum42
All right, this looks better. I recommitted in r3809. (And this time I did some monitoring in top of memory usage while testing it...)
arcum42
And now that I just looked at your recent commits to zzogl, it looks pretty similar to what you committed earlier, so it should be safe enough. ^_^
Shame I didn't check that first...

Revision 3804

GregMiscellaneous: zzogl-pg: Test and benchmark the code ;)
* speed resolve 32bits functions
Note0: I restore a positive counting in the inner loop (was simpler for a first
try)
Note1: I need to update the template to support 16bits textures.
Note2: If someone can nicely template the update_pixel macro feel free to do it
;)
gregory....
Ah and I add a define to switch between the 2 versions.
arcum42
Hmmm... There's definately an issue with this somewhere. It crashes near the beginning of Mana Khemia unless I comment out the define. I'll look into it a bit...
arcum42
Grr. It also doesn't crash if I run it with gdb. :(
arcum42
It's difficult to narrow it down, but it seems to be crashing inside update_pixel, usually when RW = 1020 on line 'u32 dsrc_tmp = convfn(src[RW((j<<6)+(x))]);'.
gregory....
If fbw = 1020. It will crash because it can be divide by 64 !!! I made a pretty big assumption.
gregory....
actually an assert in this one will be a good idea ;)
arcum42
Yeah, it probably would be.
The spot I was running into the crash was at the beginning of Mana Khemia, when it tells you you don't have any saved games, and you hit 'x' to continue. Trouble is that it's intermittent...
Of course, I don't know if you have Mana Khemia 1 to test with. (I tend to test with Gust games a lot.)
gregory....
Unfortunately not. I really need to find good second-hand buy place :)
See r3806, I had an assert and also port the template for 16bits texture. So it will be easier to test it. Hum with more testing, I propably add others bugs :)
arcum42
I've been using being on the dev team to justify tossing a ps2 game or two in when buying other things for a while. Unfortunately, now it's hard for me to find ps2 games I don't have that I'm interested in. (Though, if it's in a bargain bin for cheap, I may justify it just for testing...)
Oh well, maybe I should see if Grandia III crashes, since I know you have that game...
gregory....
Actually I have a stange issue with Gow with the 16bits texture. Its seems like the Mana Khemia. I will try to debug this one first.
arcum42
Ah, that's good. I was hoping it wouldn't be some weird thing Gust does.
(Gust games do funky IPU things, and have some issues that are hacked around in zzogl. That's one reason why it's good to have at least one of them for testing. After a while you get to know games by emulation issues, really...)
arcum42
Oh, and Grandia III hangs on startup, btw.
gregory....
I found the issue. I play to much with undo/redo I miss somethings in the end ^^
arcum42
I always hate issues like that. It's always something silly...

Revision 3805

GregMiscellaneous: Sync against trunk. (3768:3804)
arcum42
Hopefully everything went properly with that sync. This one was a bit of a tricky one.
The last sync seems to have messed up pcsx2 compilation in this branch. I fixed that with this sync. Syncing zzogl-pg with the changes in both trunk and the branch was tricky, though, which is one of the reasons I wanted to get it out of the way...
gregory....
Good idea, it was needed.
arcum42
Thanks. I ended up running a merge several times, and eventually ended up just directly copying 3 files in the pcsx2 folder over manually.
I'm assuming all the changes in the branch were to zzogl-pg, basically. Given our recent change history, it seemed logical. ^_^
gregory....
Lol, yes. The bad things was the renaming stuff.

Revision 3806

GregMiscellaneous: zzogl-pg:
* port resolve32 to 16bits texture
* add an assert to help debug
arcum42
Well, it doesn't assert. It does, however, crash at the same spot (line 3133, which is why I hate macros).
0xeea25348 in ZeroGS::Resolve_32b<32u, &g_pageTable32, unsigned int, &(unsigned int ZeroGS::dummy_return<unsigned int, unsigned int>(unsigned int))> (psrc=0xe6da2010,
fbp=0, fbw=640, fbh=448, fbm=4278190080) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3133
3133 update_pixel(62);
(gdb) bt
#0 0xeea25348 in ZeroGS::Resolve_32b<32u, &g_pageTable32, unsigned int, &(unsigned int ZeroGS::dummy_return<unsigned int, unsigned int>(unsigned int))> (psrc=0xe6da2010,
fbp=0, fbw=640, fbh=448, fbm=4278190080) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3133
#1 0xeea2063c in ZeroGS::_Resolve (psrc=0xe6da2010, fbp=0, fbw=640, fbh=448, psm=1, fbm=4278190080, mode=true)
at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3167
#2 0xeea18e4c in ZeroGS::CRenderTarget::Resolve (this=0xa867158) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:308
#3 0xeea20001 in ZeroGS::ResolveInRange (start=0, end=1024) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:2743
#4 0xee9bdad8 in ZeroGS::InitTransferLocalHost () at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/HostMemory.cpp:282
#5 0xee9d70eb in GIFRegHandlerTRXDIR (data=0x99a4490) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/Regs.cpp:997
#6 0xee9d58ff in GIFPackedRegHandlerA_D (data=0x99a4490) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/Regs.cpp:206
#7 0xee9bb1ee in _GSgifTransfer<1> (pMem=0x99a4490, size=0) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/GifTransfer.cpp:120
#8 0xee9bad68 in GSgifTransfer2 (pMem=0x99a4440, size=6) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/GifTransfer.cpp:258
#9 0x08108655 in SysMtgsThread::ExecuteTaskInThread (this=0x9da6f60) at /usr/local/src/pcsx2-greg/pcsx2/MTGS.cpp:368
#10 0x083069f9 in Threading::pxThread::_try_virtual_invoke (this=0x9da6f60, method=&virtual table offset 48)
at /usr/local/src/pcsx2-greg/common/src/Utilities/ThreadTools.cpp:546
#11 0x08306e64 in Threading::pxThread::_internal_execute (this=0x9da6f60) at /usr/local/src/pcsx2-greg/common/src/Utilities/ThreadTools.cpp:645
#12 0x08306fba in Threading::pxThread::_internal_callback (itsme=0x9da6f60) at /usr/local/src/pcsx2-greg/common/src/Utilities/ThreadTools.cpp:685
#13 0xf79166de in start_thread () from /lib/libpthread.so.0
#14 0xf789988e in clone () from /lib/libc.so.6

Revision 3807

GregMiscellaneous: zzogl-pg:
* Lost a -1 somewhere...
arcum42
It works fine with the change. [I just have to remember to watch what directory I run svn up from :( ]
gregory....
Cool.
Now times to see if they any improvement vs the others vesions. Ah, I did not inline the resolve_32b to ease dissablembling but function are only call once so it wont impact the code size.
Then replace macro with template. And try to find a way to improve RGBA32to16 function which count for 50% of the update_pixel macro.
arcum42
Well, if it helps, basically what it is doing is the 32 bit integer passed to it is actually 4 8 bit numbers representing the red, green, blue, and alpha values. It chops the last 5 bits off the first 3 integers, then grabs the last bit of the alpha value, and shoves them all into a 16 bit value.
I'm not sure if that's actually the proper way to convert a 32 bit rgba value to 16 bits, but that's what the code is doing...
gregory....
Yeah, but I did not find any way to improve it. SSE ?? Duno if some lookup table could help. I need to read the intel instruction set.
gregory....
Note: to investigate if the alpha bit is useful or not. Well what is meaning.
arcum42
Whether it's transparent or opaque, presumably...
arcum42
And, yeah, SSE is probably the way to do it. (Pity I don't know SSE. All the SSE instructions you see in the code would have been by Jake or one of the others...)
gregory....
Do not know much about SSE. But actually I'm not sure you can use them. SSE is efficient to handle vector of either 4*int, 4*float, or 2*double. (we need 8bits scale). The worst things is the src array is not continous due to AA scaling. But I have an intel guide with SIMD stuff. (I sent you a copy by mail in case you does not have it)
arcum42
Thanks. I'll look at it later. GSdx builds a ton of SSE commands into its equivalent of the Vector (now float4) class, and I've been meaning to decipher that.
For the moment, I've got to get to bed, though, since I have to work tomorrow... :(
gregory....
Ok I maybe find a way to do it.
Here the idea: transform a 4 pixels to a 4x4 matrix pixel component (alpha,R,G,B) with 1 component by register.
For instruction details look the following link: http://www.intel.com/products/processor/manuals/ (in particular the instruction set reference)
Step 1/
Play with PSHUFHW/LW, PAND, POR, (also some mask value). There is 1 instruction for byte shuffle: PSHUFB but it is intel SSSE3 (this one could save +10 instructions... not supported by my cpu)
x0: A1R1G1B1 A2R2G2B2 ..... to A1A2A3A4 R1R2R3R4 .....
Step 2/
Use various unpack to transform the 8bits component to 32 bits
x0: A1A2A3A4
x1: ...
Step3/
shift and or'ed everyone. Use the result :)
In the end it will cost around 35 (25 SSSE3) instructions to convert 4 pixels. Basic C is 15 to convert 1.
Hopefully I better understand SSE now. And yes vector loves SSE that why we call them vector unit sometimes ;)

Revision 3808

GregMiscellaneous: zzogl-pg:
* replace previous macro with a template. (could be improve with some template
recursion, but no important for the moment)

Revision 3809

GregMiscellaneous: zzogl-pg: Switch to _aligned_malloc in GetMemoryTarget, take
2. (If at first you don't succeed...)

Revision 3810

GregMiscellaneous: zzogl-pg: Apply Zeydlitz's changes from r237 of zzogl.
Improves code readability, and gives a slight speedup.
arcum42
I probably could have applied this directly to the trunk, but I figure it goes along with the _aligned_malloc changes. I might pull both into trunk later, though.

Revision 3811

GregMiscellaneous: zzogl-pg:
* Use sse2 instruction to convert pixel from 32bits to 16bits.
Note: Seem slower than basic C. I need to opmitize some memory access...
Zeydl...
You code look little strange. You do to many shuffles to obtain distinct colour's, and than to set it to constant again.
But why you don't want to do folowing trick xmm1 = xmm0 && mask1, xmm2 = xmm0 && mask2, xmm3 && mask3, xmm4 = xmm0 && mask4, where mask's are the same mask, that use in RGBA32to16, but put in all 4 words of register. Than
use psrld xmm1 3; psrld xmm2 6; psrld xmm3 9; pssrw xmm4 16. psrld made shift made 4 separate shifts, as I read, so after than if you wrote xmm0 == xmm1 || xmm2 || xmm3 || xmm4, you'v got 4 words, in each of that upper 16 bit are zeros, and lower 16 is RGA5_A1 colour, so 3 shuffles would be enough.
gregory....
Hum yes seem to be better. I will improve that. Sometimes I search too complicated solutions :)

Revision 3812

Made some minor tweaks to SIF to test some theories and fix some broken-looking
code -- please report any regressions. Also commented some of SIF and IPU
stuff. :)
ramapcsx2
So far no regressions spotted..

Revision 3813

GregMiscellaneous: zzogl-pg: Rewrote ZZoglMath.h.
arcum42
I may rework this to borrow a bunch of code from GSdx later on. I didn't right now because it's all using SSE, and I'd have to puzzle through it.

Revision 3814

GregMiscellaneous: zzogl-pg:
* Rework sse2 with somethings easier ans smaler ;)
* do fbm mask with sse2
gregory....
Ok last things is to improve the first sse2 loading.
arcum42
That and we'll need a Windows version of the assembly. (Or to not use the assembly in Windows). I've had to convert the other way before, so I'm guessing it'll look about like this:
__asm
{
movdqa xmm0, dsrc_tmp // load 4 pixel
movdqa xmm1, xmm0
movdqa xmm2, xmm0
movdqa xmm3, xmm0
// keep 1 color and shift it
pand xmm0, pixel_Amask
psrld xmm0, 15
pand xmm1, pixel_Rmask
pslld xmm1, 9
pand xmm2, pixel_Gmask
pslld xmm2, 6
pand xmm3, pixel_Bmask
pslld xmm2, 3
// Rebuild a full 16bits pixel
por xmm0, xmm1
por xmm0, xmm2
por xmm0, xmm3
// Apply the fbm mask
movdqa xmm1,mask
pand xmm0, xmm1
// save the result
movdqa dsrc_tmp, xmm0 // load 4 pixel
};
But I haven't had a chance to actually try it in Windows yet...
gregory....
Well, somethings like that seem fine. Anyway I do not find any good method to setup dsrc_tmp ? We do 32b memory(load) -> 32b register(save) -> 32b memory(big load) -> 128 xmm ...
In SSE4.1 there is an instruction to load a 32b memory to 1 of the 4 position in the xmm register.
Anyway most of time is probably spend with the random read/write of the dst memory.
Better spend time to improve the float4 struct with sse2. It will probably increase a lots performance (if compiler does not use sse2 in first place)
Zeydl...
Forth shift is erroneous -- you twice shifted xmm2, and no shift for xmm3. Then you shift left? Are you sure about it? I usually mistake right and left.
Anout memory. Well, source data are elements of array: src[X], src[X + 1 * AA_x], src[X + 2*AA_x], src[X + 3 * AA_x], where AA_x is 1, 2 or 4. So if AA_x = 1, you could store this data directly. On other cases ... Well, you could you that src[X] == src[X + AA_x-1], src[X + 2 * AA_x] = src [X + 3 * AA_x - 1], so you have 2 double worlds to load: (u64*)src[X + AA_x - 1] and (u64*)src[X + 2 * AA_x - 1].
gregory....
... I probably copy past the last third from the wrong line ...
THe issue when AA_x is one : I have no guarantee that src is 16bits aligned.
The last part does it works for both AA_x = 2 and = 4 ?
Zeydl...
yes, there are colours that in x1 are 1 2 3 4, x2: 1 1 2 2 3 3 4 4, x4: 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4. When we put this texture onscreen, we do some mixing (picture look better), but only on fragment shader stage.
arcum42
Just to mention, when I went to test this out on Windows, I found that Windows doesn't particularly like passing "dummy_function". It gave this error:
Error C2563: mismatch in formal parameter list
I was able to get it to compile by defining:
u32 dummy_return32(u32 d) { return d; }
u16 dummy_return16(u32 d) { return d; }
And passing them instead of dummy_return...
gregory....
Hum, actually this parameter can be removed. I really need to clean all this stuff.
You have 2 cases:
basic conversions: parameter do_conversion == false
RGBA32tp16: parameter do_conversion == true.
arcum42
Yeah, when you are revising one section of code a bunch, that can end up happening...

Revision 3815

GregMiscellaneous: zzogl-pg:
* fix shift direction in sse2.
* Reduce memory transfter to load pixel.
arcum42
Interesting. It builds the devel target, but if I try to build a debug target, it gets these errors:
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp: Assembler messages:
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3133: Error: bad expression
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3133: Error: missing ')'
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3135: Error: bad expression
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3135: Error: missing ')'
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3137: Error: bad expression
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3137: Error: missing ')'
/usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/targets.cpp:3139: Error: bad expression
I'm assuming the difference is the lack of optimization...
arcum42
(And there were 50 errors. I just cut them off a bit...)
gregory....
Arg, forgot to test the debug build.
gregory....
Hum, it works on my side.
Can you check that you have a clean file (just a missing comma can generate tons of error).
Which gcc versions ? And for information, my debug flags (note fno-omit-frame-pointer was to play with oprofile)
CXX_FLAGS = -g -O0 -fno-omit-frame-pointer -m32 -msse -msse2 -march=i686 -pthread -fno-strict-aliasing
CXX_DEFINES = -Dzzogl_EXPORTS -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -DZEROGS_SSE2 -D_DEBUG
arcum42
gcc version 4.4.3. Oh, and I figured out that is was specifically the 4 lines with the pixel masks causing the error:
"pand xmm0, [%[pixel_Amask]]\n"
and that it only happens if they are set to "m". I experimentally changed all 4 to "r" and it compiled.
gregory....
Hum, arg. Silly tool ! I need to read more about memory constraint...
gregory....
Is it working with "g" instead of "m" ?
gregory....
Could you also try somethings like that
// keep 1 color and shift it
- "pand xmm0, [%[pixel_Amask]]\n"
+ "pand xmm0, [%2]\n"
"psrld xmm0, 15\n"
- "pand xmm1, [%[pixel_Rmask]]\n"
+ "pand xmm1, [%3]\n"
"psrld xmm1, 9\n"
- "pand xmm2, [%[pixel_Gmask]]\n"
+ "pand xmm2, [%5]\n"
"psrld xmm2, 6\n"
- "pand xmm3, [%[pixel_Bmask]]\n"
+ "pand xmm3, [%4]\n"
"psrld xmm3, 3\n"
gregory....
Also add __volatile__ (it is needed anyway to avoid gcc moving the block before the loading of pixel)
arcum42
Labels verses numbers didn't make a difference, and the error continued with __volatile__. It does compile with "g" rather then "m", though.
gregory....
Ok I found a solution. I did not understand why change u32 to int is better...
1/ Test 1
-static const __aligned16 u32 pixel_Amask[4] = {0x80000000, 0x80000000, 0x80000000, 0x80000000};
-static const __aligned16 u32 pixel_Rmask[4] = {0x00F80000, 0x00F80000, 0x00F80000, 0x00F80000};
-static const __aligned16 u32 pixel_Gmask[4] = {0x0000F800, 0x0000F800, 0x0000F800, 0x0000F800};
-static const __aligned16 u32 pixel_Bmask[4] = {0x000000F8, 0x000000F8, 0x000000F8, 0x000000F8};
+static const __aligned16 int pixel_Amask[4] = {0x80000000, 0x80000000, 0x80000000, 0x80000000};
+static const __aligned16 int pixel_Rmask[4] = {0x00F80000, 0x00F80000, 0x00F80000, 0x00F80000};
+static const __aligned16 int pixel_Gmask[4] = {0x0000F800, 0x0000F800, 0x0000F800, 0x0000F800};
+static const __aligned16 int pixel_Bmask[4] = {0x000000F8, 0x000000F8, 0x000000F8, 0x000000F8};
2/ Test 2 with the previous patch it is possible to do the following. On my side the code generated is the same. The code is like the one in x86.cpp so it must be compile on your side.
"movdqa xmm3, xmm0\n"
// keep 1 color and shift it
- "pand xmm0, [%[pixel_Amask]]\n"
+ "pand xmm0, %[pixel_Amask]\n"
"psrld xmm0, 15\n"
- "pand xmm1, [%[pixel_Rmask]]\n"
+ "pand xmm1, %[pixel_Rmask]\n"
"psrld xmm1, 9\n"
- "pand xmm2, [%[pixel_Gmask]]\n"
+ "pand xmm2, %[pixel_Gmask]\n"
"psrld xmm2, 6\n"
- "pand xmm3, [%[pixel_Bmask]]\n"
+ "pand xmm3, %[pixel_Bmask]\n"
"psrld xmm3, 3\n"
// Rebuild a full 16bits pixel
arcum42
It compiles with the first patch.
It will compile with the second if I also apply the first...
gregory....
Great. Yes the second need the first... It is stange, it works with int but not with int32_t. Perhaps GAS only support standard int definition.
arcum42
Yeah, just tried a few tests. It works with int or unsigned int, but if I add in:
typedef unsigned int u_32;
And switch the four variables to use u_32, compilation fails. It must not like anything that isn't a standard type.

Revision 3816

GregMiscellaneous: zzogl-pg:
* remove convfn parameter template. Use instead a boolean (easier & fix windows)
* Protect asm statement with __LINUX__ for the moment
* apply the fbm mask in SSE2 also for 32bits texture. Reduce stack activity.
wing...
I can't wait to try those new changes when they hit the trunk =) Good work, guys!
arcum42
Yeah, it'll be nice when these changes hit the trunk. We're going to want it working properly in both Linux and Windows first, though, and I'd imagine do some more testing and refinement.
zzogl does feel faster in this branch to me, though.
gregory....
You know, it is allowed to build the branch ;) And test it.
Actually if you are lucky it will compile otherwise it will complain on asm stuff :(
arcum42
Yeah, it's just that instead of checking out the trunk like this:
svn checkout http://pcsx2.googlecode.com/svn/trunk/ pcsx2-read-only
You'd do something more like:
svn checkout http://pcsx2.googlecode.com/svn/branches/GregMiscellaneous pcsx2-greg
And, as greg said, if you did it this revision, you'd probably get a compilation error. Since branches are used to test especially experimental changes, they break a lot...
gregory....
@Wingnux.
The branch is now in better shape (well I'm nearly sure that I introduce a bug somewhere in my last commit r3860 ;) ). It will need some advance testing. If you have some free time, feel free to play with this branch.

Revision 3817

GregMiscellaneous: zzogl-pg:
* GAS seem only support standard C type
Jake.Stine
Ugh, GAS. Have you guys considered using intrinsics instead maybe? Since GCC is known to have a pretty good xmm optimizer, it would probably be a win/win.
I'd especially recommend it, because using xmm regs across multiple asm blocks separated by C code (the if() blocks, etc) is pretty well breaking the "rules." The compiler -- and with GCC being a typically aggressive XMM optimizer this is especially pertinent -- may decide to use an XMM register for something in between. It is extremely unlikely, of course, but possible none-the-less.
The one section modified here would look something like this in intrinsics:
// (xmm0 defined and assigned above)
__m128i xmm1 = xmm0;
__m128i xmm2 = xmm0;
__m128i xmm3 = xmm0;
_mm_and_si128( xmm0, _mm_load_si128((__m128*)pixel_Amask) );
_mm_srli_si128( xmm0, 15);
_mm_and_si128( xmm1, _mm_load_si128((__m128*)pixel_Rmask) );
_mm_srli_si128( xmm1, 9);
_mm_and_si128( xmm2, _mm_load_si128((__m128*)pixel_Gmask) );
_mm_srli_si128( xmm2, 6);
_mm_and_si128( xmm3, _mm_load_si128((__m128*)pixel_Bmask) );
_mm_srli_si128( xmm3, 3);
_mm_or_si128( xmm0, xmm1 );
_mm_or_si128( xmm0, xmm2 );
_mm_or_si128( xmm0, xmm3 );
_mm_and_si128(xmm0, _mm_load_si128((__m128*)mask) );
_mm_store_si128( (__m128*)src_tmp, xmm0 );
.. if we start using intrinsics alot, we could probably do some macro/inline function replacements for them; since intel's naming scheme selection pretty well sucks. ;)
(I've been using them more in PCSX2 proper as well, lately)
Jake.Stine
By the way, I use intel's instruction manuals for translating SSE to intrinsic form, dowloaded from here:
http://www.intel.com/products/processor/manuals/
Specifically these two:
http://www.intel.com/Assets/PDF/manual/253666.pdf
http://www.intel.com/Assets/PDF/manual/253667.pdf
arcum42
I really need to learn intrinsics. And that does look like that'd be a lot cleaner for our purposes, especially when you factor in that we'll need to add Windows versions of all the assembly still...
Jake.Stine
Yeah. Basic summary:
* it'd be safe across the mix of C and ASM
* cross-platform and x64 compat
* GAS sucks
;)
Jake.Stine
And yea, you could change the names above to something more meaningful, like:
__m128i rpart = xmm0;
__m128i gpart = xmm0;
__m128i bpart = xmm0;
... etc. But initially its usually not too hard to do direct instruction/register-to-intrinsic conversions, using some PDF searches above (search by instruction name, and the instruction details will have the intrinsic equiv).
gregory....
Actually it is on my TODO list ;) For the moment I used GAS because I know how it work.

Revision 3818

GregMiscellaneous: zzogl-pg: Try out using modifications of some of GSdx's code
for ZZoglMath.h.
Zeydl...
Aren't you aware, that this code is not C99 standard compatible? First, size of float is not guaranteed to be 32-bit, it could be anything. Second you use union fields x, y, z, w and m without proper recast, and nobody guaranteed, that they will be placed in right order.
gregory....
Zeydlitz,
I found an interesting heuristic to speed resolve32b.
* When fbm = 0, the function write directly new value (so no need to read previous value, will save lots of memory access)
* When fbm = 0xFFFF, the function does nothings (if I'm correct). Just read and write same value... (propably never occurs this one actually)
I done a quick test on God of war. And fbm = 0 seems to appears 1/3 of the time.
gregory....
Any opinion, how likely is going to happen.
Zeydl...
Correct place to test resolving is Whale region of Kigdom Hears 1. At this location resolve create pretty observable picture (sports in wall are moving with correct resolving).

Revision 3819

GregMiscellaneous: zzogl-pg:
* init completely the mask array...
* fix the offset (count is byte not double word)

Revision 3820

GregMiscellaneous: zzogl-pg:
* port ASM GAS to intrinsic.
gregory....
Note: to test SSE2 windows compilation, you must remove "&& defined(__LINUX__)".
Note2: not sure of the new include files (do not the difference between emm and xmm)
gregory....
Ah, Jake thanks for the example.
arcum42
If I remove the "&& defined(__LINUX__)", it compiles in Windows with SSE2. It does give a lot of warnings about converting from u64 to an int in each line with _mm_cvtsi32_si128(*(u64*)(base_ptr...)) in it, though.
(As far as the includes go, if it helps, all the functions in ZZoglMath.h only needed the second of those two includes.)
Jake.Stine
_mm_cvtsi32_si128() takes a 32 bit parameter as a source (hence the 32 part of its name). So yeah, technically it should be cast to s32 or u32.
Jake.Stine
Ok, looking at the diff, the conversion is wrong anyway -- _mm_cvtsi32_si128 is MOVD, not MOVQ. The code should be using _mm_cvtsi64_si128 instead. :)
gregory....
ooups
gregory....
Arg, _mm_cvtsi64_si128 is only 64bits (at least on gcc)...
gregory....
Ok I found the solution. See r3822.

Revision 3821

newdmac: One brand new SIF, and several fixes to the core chain mode handlers,
as I had made a fundamental mistake in the way destination chain mode works.
(Only IPU and some GIF tweaks left now)
ramapcsx2
Congrats :)

Revision 3822

GregMiscellaneous: zzogl-pg:
* Fix wrong integer size.
* Enable sse2 version on windows too.
Zeydl...
By the way, nice place to check resolve function is at very start of FFX-1, in first battle with overdrives.
gregory....
Good this one will be easier to test on my side.

Revision 3823

newdmac: remove some unused files.

Revision 3824

IPU Fix for Haunting Grounds (in-game cinemas skipped after 1 second). Bug was
caused by the internal buffer of the IPU (2 QWC) not being refilled properly in
rare circumstances.
konaj...
nice fix, btw maybe you can take a look at clock tower 3 if you get a chance it was broken way back in r3632 and never fixed, game screen turns black when you exit through a door
refraction
Ive looked at that, its some freaky timing thing (from what i can tell so far)
making Vif MFIFO quicker seems to sort it..

Revision 3825

GregMiscellaneous: zzogl-pg:
* Port more ASM to intrinsics. Note use non-cacheable store instead to reduce
cache pollution
gregory....
I plan to port also the WriteCLUT_T16_I4_CSM1_sse2 function (in x86.cpp).
The last ASM block (in zerogs.cpp) will wait longer because of the extra complexity (with no C code to understand easily what it is done).
arcum42
Hmmm... Something's not quite right here. When I start a new game in Kingdom Hearts 1, it crashes at the very beginning of the opening movie as of this revision.
The crash seems to happen at the first call to TextureRect after the NEW_INTRINSIC_VERSION codeblock is executed. (Which makes sense, because that's when opengl gets the texture that code just swizzled.)
arcum42
The actual error I get is:
pcsx2-dev: malloc.c:3074: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.
But, as you can tell, that's fairly unenlightening...
arcum42
Think I got it. Change:
for (int i = targ->height * GPU_TEXWIDTH/16 ; i >=0 ; --i)
to:
for (int i = targ->height * GPU_TEXWIDTH/16 ; i > 0 ; --i)
and it doesn't crash.
gregory....
yes it is better this way.

Revision 3826

Converted IOP to use a static/global hardware register allocation. (same as I
did for the EE a few weeks ago).
serban.a...
the movies of shin megami tensei devil summoner 1 & 2 and digital devil saga 2 are working again
refraction
you will probably find that was r3824, not this one.
serban.a...
ok:)..anyway now clock tower 3 is working again...it showed lots of errors when changing rooms
konaj...
still same errors for me in ct3, if you re-enter the first room screen goes black, or if you go up stairs to the fireplace scene.
anyways I don't think these commits have anything to do with ct3, since it's the MFIFO breaking that game :p

Revision 3827

newdmac: sync with trunk (r3794-r3826)

Revision 3828

newdmac: VIF / GIF work. Enabled the new microVU code for breaking execution on
stalled XGKICKs (still have to implement the resume points).

Revision 3829

GregMiscellaneous: zzogl-pg:
* ASM port round 3 + add some comment to understand the algorithm.
arcum42
I decided to try compiling r3863 on this branch in Windows, and found some errors it runs into in this code.
In WriteCLUT_T16_I4_CSM1_sse2, in this line:
vm0 = (__m128i)_mm_shuffle_ps((__m128)vm0, (__m128)vm1, 0x88); // 14 12 10 8 6 4 2 0
It doesn't like converting (_m128i) to (_m128). Same goes for the second usage of _mm_shuffle_ps a bit later.
gregory....
Hum, the prototype of the function is __m128 _mm_shuffle_ps(__m128 a , __m128 b , int i );
Gcc complains if there is no cast... I see no point to differentiate int packet from float one for shuffle instruction...
Anyway, could you try this form: vm0 = (__m128i)_mm_shuffle_ps((__m128 &)vm0, (__m128 &)vm1, 0x88);
Not sure how cast the return...
Another solutions will be an union.
arcum42
It seems to compile if I do it this way:
vm0 = (__m128i &)_mm_shuffle_ps((__m128 &)vm0, (__m128 &)vm1, 0x88);
It then gives a lot of warnings along this line:
warning C4799: function 'ZeroGS::update_4pixels_sse2_bis<64,&g_pageTable16SZ,0,1,2>' has no EMMS instruction
for update_4pixels_sse2_bis and Resolve32_b...
gregory....
With more search, in c++ there is a reinterpret_cast feature. Do not know how it is working.
gregory....
Could you try this one.
vm0 = reinterpret_cast<__m128i>(_mm_shuffle_ps(reinterpret_cast<__m128>(vm0), reinterpret_cast<__m128>(vm1), 0x88));
arcum42
1>..\x86.cpp(666) : error C2440: 'reinterpret_cast' : cannot convert from '__m128i' to '__m128'
1> Conversion requires a constructor or user-defined-conversion operator, which can't be used by const_cast or reinterpret_cast
gregory....
Snif, reinterpret_cast works on gcc.
vm0 = (__m128i &)_mm_shuffle_ps((__m128 &)vm0, (__m128 &)vm1, 0x88);
This one does not work on gcc. Maybe create a pseudo __m128 variable and then cast it.
warning C4799: function 'ZeroGS::update_4pixels_sse2_bis<64,&g_pageTable16SZ,0,1,2>' has no EMMS instruction
I guess the compiler uses some MMX registers for some 64bits transfers... Do not know if there is a way to disassemble the code to check what it is doing. Anyway we could still call _mm_empty() in windows world
gregory....
This one is good with gcc.
__m128 vm0_f = (_mm_shuffle_ps((__m128&)vm0, (__m128&)vm1, 0x88)); // 14 12 10 8 6 4 2 0
vm0 = (__m128i&)vm0_f;
arcum42
I'm back in Linux right now, but I suspect that'd work in Windows. I decided to test more games in Zeydlitz's latest revision after seeing what happened to Yuna's eyebrows... ^_^
gregory....
:)
arcum42
It does in fact work in Windows. Of course, it has to be done to both _mm_shuffle_ps lines in that function...

Revision 3830

newdmac: Mostly finished VU/XGKICK features and SIGNAL/IMR support, implemented
SPR transfers, and started on the IPU interface.
azte...
good to see things not zzogl related, this is something we can relate. ;)
kaboo...
I'm a windows user myself but I used OGL back then with 0.9.4
and I test it from time to time and the last time I tried it was way behind GSDX.
so it's more like damn about time XD
gregory....
Yes, OGL needs loves specially for linux users ;)

Revision 3831

IPU: Cleanups and simplifications, and removed a whole lot of code that was
force-setting ipu0dma's STR to 0 and/or flushing the FIFO for no reason. Tested
tons of games, couldn't find any regressions.

Revision 3832

GregMiscellaneous: zzogl-pg: Let's use _mm_setzero_si128 to zero the register.
gregory....
good I did not find it

Revision 3833

IPU:
* Fix a potentially obscure bug in ipuCSC (color space conversion) which would
have caused PCSX2 to hang on certain types of rare partial transfers.
* Remove some more dead code and structure data from the mpeg library.
gregory....
I notice some wrong color in FFX-1 in games movies. Except an outside border I get gray scale macro block. The issue probably appears with recent IPU changes.
Jake.Stine
Ok, thanks. I'll try to figure it out later. If you can figure out which revision number in the meantime, that'll be helpful. If not I'll find it myself when I have time.
gregory....
Sorry bad configuration on my side (forgot the gamefix...)
Jake.Stine
Ah, no problem. Is good news for me. ^_^

Revision 3834

GregMiscellaneous: zzogl-pg: Split out some code into a separate function.

Revision 3835

GregMiscellaneous: zzogl-pg: Fix for a bug in the new intrinsic code.

Revision 3836

GregMiscellaneous: zzogl-pg: Move a few functions into CMemoryTargetMngr.

Revision 3837

GregMiscellaneous: zzogl-pg:
* Finish GAS removal. I use SSE2 instead of mmx because it was easier to write
(faster anyway).
Code seems equivalent between GAS & intrinsics but control flow will need a good
testing (and some explanation)
Note: I also add a basic C version for reference/debug (not tested yet)
arcum42
Sounds good. Of course, we still have x86.S, but I'm glad to have all the GAS code on the verge of being out of zzogl...
gregory....
Yes I saw. Pretty big one. I thinks this one will wait a long moment. At least it is pure asm, so no strange constraint or no support of typedef...
Intrinsic are quite a good things actually. You can keep the control flow in C (better optimization by the compiler). Moreover it is portable linux/windows and it will be amd 64 friendly (in a very very long future).
Anyway, now the difficult part. Test that all changes work then merge to the trunk.
arcum42
Yeah, that'll be the fun part...
arcum42
Found a crash. It's in Final Fantasy X-2, after the completion of the first mission, right after the pan-over of the ship. (After Yuna's "My body started dancing by itself..." line).
Here's a backtrace. The crash is in WriteCLUT_T16_I4_CSM1_sse2:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xead7db70 (LWP 11854)]
0xeedd4366 in _mm_load_si128 (vm=0xec81d100, clut=0xa94b1c2) at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:679
679 return *__P;
(gdb) bt
#0 0xeedd4366 in _mm_load_si128 (vm=0xec81d100, clut=0xa94b1c2) at /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/emmintrin.h:679
#1 WriteCLUT_T16_I4_CSM1_sse2 (vm=0xec81d100, clut=0xa94b1c2) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/x86.cpp:732
#2 0xeedd8b66 in ZeroGS::texClutWrite (ctx=0) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/zerogs.cpp:1213
#3 0xeed5cd2e in ZeroGS::CluttingForFlushedTex (tex0=0xeee7f018, Data=1045978026, ictx=0) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/zerogs.h:525
#4 0xeed7ffa1 in ZeroGS::VB::FlushTexData (this=0xeee7f000) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/ZZoglVB.cpp:500
#5 0xeed5acd9 in tex0Write (i=0, data=0x96fb820) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/Regs.cpp:238
#6 0xeed5b423 in GIFRegHandlerTEX0_1 (data=0x96fb820) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/Regs.cpp:455
#7 0xeed5ac1b in GIFPackedRegHandlerA_D (data=0x96fb820) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/Regs.cpp:206
#8 0xeed406bf in _GSgifTransfer<2> (pMem=0x96fb820, size=4) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/GifTransfer.cpp:131
#9 0xeed3ff74 in GSgifTransfer3 (pMem=0x96fb820, size=4) at /usr/local/src/pcsx2-greg/plugins/zzogl-pg/opengl/GifTransfer.cpp:267
arcum42
There's a crash in Kingdom Hearts 1 as well, but I haven't done a backtrace on it yet. It might be the same issue. It's after the opening movie, when you step forward for the first time.
Zeydl...
Yes, it's unaligned load -- nobody check that clut is 16-bit aligned address. And look at function call: last part of clut is c2.
gregory....
Arg, I found the issue. I test the wrong variable...
if ((u32)vm & 0x0F) { must be replaced by if ((u32)clut & 0x0F) {
gregory....
FYI, I commit the change -> r3839

Revision 3838

newdmac: Redid VIF/GIF/IPU FIFOs, and did preliminary IPU/DMAC tie-ins.
wtonberr...
thanks very much for job
tatsuy...
Can't remember if its this specific revision but as of r3843 from r3788 Sky Odyssey has a huge speedup from 46 FPS (100% EE, 20~40% GS) to 55 FPS (100% EE, 15~40% GS), great work.
tatsuy...
Intro that is, gameplay is still a solid 60 FPS.

Revision 3839

GregMiscellaneous: zzogl-pg:
* use a fence after non temporal move
* fix a crash in write clut
arcum42
That takes care of the crash in both Final Fantasy X-2 and Kingdom Hearts 1. I noticed some graphical distortion, but I think it was there before.
The messages about the frame mask and time taken by resolve spam the console pretty badly in some cases, so we'll want to either comment those out or have them controlled by a define before committing to trunk.
Frame Mask 0 seems like it is used a lot. Kingdom Hearts 1 seemed to use frame mask 1 pretty often, and frame mask ff000000 seemed to get a good deal of use as well.
Speedwise, things are looking good.
We still need a bit more testing, of course. I just stopped once I knew I had a reliable crash bug on at least two games. Though I did play through a decent amount of Grandia III earlier...
gregory....
The timing can be commented out.
Frame mask 0 is equivalent to redraw all pixels (so probably called for every base frame). The idea was to do somethings like that (hope to reduce memory transfer):
if ( likely(imask) ) {
dst_tmp = basepage + pageTable[i_msk][(INDEX)];
*dst_tmp = (Tdst)src_tmp[0] | (*dst_tmp & imask);
dst_tmp = basepage + pageTable[i_msk][INDEX+1];
*dst_tmp = (Tdst)src_tmp[1] | (*dst_tmp & imask);
dst_tmp = basepage + pageTable[i_msk][INDEX+2];
*dst_tmp = (Tdst)src_tmp[2] | (*dst_tmp & imask);
dst_tmp = basepage + pageTable[i_msk][INDEX+3];
*dst_tmp = (Tdst)src_tmp[3] | (*dst_tmp & imask);
} else {
dst_tmp = basepage + pageTable[i_msk][(INDEX)];
*dst_tmp = (Tdst)src_tmp[0];
dst_tmp = basepage + pageTable[i_msk][INDEX+1];
*dst_tmp = (Tdst)src_tmp[1];
dst_tmp = basepage + pageTable[i_msk][INDEX+2];
*dst_tmp = (Tdst)src_tmp[2];
dst_tmp = basepage + pageTable[i_msk][INDEX+3];
*dst_tmp = (Tdst)src_tmp[3];
}
But x86 is a crappy architecture... What the cpu does for *dst_tmp = (Tdst)src_tmp[3]; is first load dst_tmp in cache. Change the value. Later write back to memory. I did not find any way to write a 32bits value without caching....
This function is unfriendly for cache. We read a big chunk of memory (cache pollution) change some values (not all) in random order. Write back the cache line because there is no place for the new. Reload it later...
Hum, maybe stay in the same basepage will improve the situation. I need to do some test.
Zeydl...
For speed test use breath of fire. It does often use data transfer, so it' easy to observe a performance issues.
And masking... Well, PSMCT16 is a 16-bit storage mode. And data store as 2 16-bit numbers in one 32-bit register. Zerofrog do a trick: he address a 16-bit data as not-aligned 32-bit data -- and at this case 16-bit pixels are always stored at the bigining of such unaligned number. And mask here is a combination of 0xffff from 16-bit's and fbm (it's PS2 defined value that prevent usage of several bits). fbm is used to keep only one color at screen, or to keep alpha. 24Z should habe 0xffffff basemask.
I really think, that we SHOULD get rid of all unaligned 32-bit data access. It's pretty slow and made cache polution even worse.
We should use "aligned" variant:
32-bit-aligned address == (8 / PIXEL_PER_WORD(psm)) * getPixelAddress##PSM##) / 8, and fract part of this division -- is number of pixel in word.
so at 16-bit code should be:
dst_tmp = getPixelAddress##PSM##_Aligned32(j, i, shift, pageoffset, fbw);
*dst_tmp = (((src_tmp[0] & mask) || (*dst_tmp & ~ mask))) << shift;
dst_tmp = getPixelAddress##PSM##_Aligned32(j, i, shift, pageoffset, fbw);
*dst_tmp = (((src_tmp[0] & mask) || (*dst_tmp & ~ mask))) << shift;
This code should be quicker -- it use only 32-bit aligned write.
I hope, I was clear? And basepage is minimum problem -- the troublesome part is squizzled data in pageTable -- we could not predict address for next data.
gregory....
Agree unaligned 16 bits access is a bad things. But not sure to understand everythings. If I sum up.
16 bits data are store in 32bits format. Zerofrog does a trick to obtains "0000 DATA" instead of "00DA TA00" for example (I'am correct ?)
The question how do you obtains the shift value (depends of the psm format ?)
Agree also that the troublesome part is the random data. However my comment on basepage was "do a pageTable at once" instead of a src raw at once. So we keep memory access from basepage to basepage + 4ko. It improves a little the cache locality. In my basic god of war testcase I gains 5-10%
Zeydl...
No, instead of DATA 0000. Get GS user manual at least, PSMCT16 mode have 2 16-bit pixels in 1 32-bit word (DATA DATA). The code is pretty simple for aligned address:
basepage = ((y>>A) * (bw>>B)) + (x>>B);
word = ((bp * 64 + basepage * 2048) << 3) + (g_pageTable[psm][y&D][x&E] << (3 - C));
shift = (word & 0x7) << 2;
return ((word & ~0x7) >> 3);
Here we assume, that D+1 an E+1 are size of swizzled table (32*64 for PSMCT32, 24, 32Z, 24Z, 8H, 4HL and 4HH, 64*64 for all 16-bit's, 64*128 for PSMT8 and 128*127 for PSMT4), 1 << A = D + 1, 1 << B == E + 1 (so x<<A == x/(D+1)), C == PIXEL_PER_WORD.
Zerofrog try to keep a basepage --
frame##SwizzleBlock##blockbits(pPageOffset + getPixelAddress(psm, j, i, bw), src+RW(j), Pitch(fbw)/sizeof(Tsrc), mask);
is a code for it (Offset + Address is work like a basepage for it, i and j are incresed to basepage size). But it seems that he made a mistake somewhere, so I do *0 for this code and we now have only a raw copying.
Note, that we need to made a GOOD code for getPixelAddress and writePixel and readPixel -- my current code is not as good, as I wish. This functions are called all around here.
gregory....
Get GS user manual at least << if you have a link or send me some docs by mail, I will be glad ;)
For the formula I'm good (few days ago I thought to create a template with similar parameters). Well except the aligned stuff. Note for 8&4 mode there is "bw+127" in current code. Not sure of the impact.
Anyway shift = ((g_pageTable[psm][y&D][x&E] << (3 - C)) & 0x7) << 2;
(bp * 64 + basepage * 2048) << 3) & 0x7 is null.
And so word = (bp * 64 + basepage * 2048) + (g_pageTable[psm][y&D][x&E] >> C)
So shift can be precomputed in a lut.
Zeydl...
Yes, it's the same. But trouble -- we try to save as much memory access, as it possible. Maybe we should store g_pageTable in indirect format (addr << 8 + shift, for example). We need try to forbit non-cconstant shifts.
gregory....
Yes good point. Seems a good idea to keep 3 bytes for the address and 1 byte for the shift.
Zeydl...
Well... Honestly, it's easy: we must store u4 adresses in g_pageTable. So I made g_PageTableNew = g_PageTable * PIXELS_PER_WORD (and for 8H, 4HH and 4HL add proper shift). And them
word = (bp * 64 + basepage * 2048) + (g_pageTable[psm][y&127][x&127] >> 3);
shift = (g_pageTable[psm][y&127][x&127] & 0x7) << 2;
gregory....
Depends on gcc jobs. If there is enough space, it will probably a little faster to keep 1 bytes for the shift, so it can be extracted with a 8 bits register move (save the mask). Besides the <<2 can be precomputed.
The >> 3 shift will depends on PSM. A template can be a solution to keep it constant.
Do not know if somethings like that could work.
template<u32 x_size, u32 y_size, u32 pagetable[2**y_size, 2**x_size]> function(....) {
if(pagetable == &g_pageTable32) { ... } else {...}
}
Zeydl...
Our main issue is speed here. Our plugin tends to have following code (sowhere in targets or flush):
#define Ugly_looking_define(psm. ...) \
for (i = ...) \
for (j = ...) { \
Do something with getPixelAddress##psm(x, y, bw); \
}
function RealyImportant function(working class) {
psm = class.psm;
case (psm)
switch every_psmt: Ugly_looking_define(psm_name, ...)
}
What's trouble with this code? It really prevent us form using generally written getPixelAddress this case should be outside for cycle (obviously).
And this case is source of bugs, for example TRANSFERLOCALLOCAL_4 define is erroneous,
I wrote template <int psm> getPixelAddress, and could paste inside define (well, at least one bad code piece is gone). But I wish to get rid of case.
gregory....
Hum.
For me template is enough. If the case is outside of loop is does not cost too much.
Here an extract of the code generated by gcc for the case.
18f8: 83 fe 3a cmp $0x3a,%esi
18fb: 77 33 ja 1930 <ZeroGS::_Resolve(void const*, int, int, int, int, unsigned int, bool)+0x90>
18fd: ff 24 b5 00 00 00 00 jmp *0x0(,%esi,4) 1900: R_386_32 .rodata
The cmp&jmp is to check that the value is in a static range (jump to default case). Then it directly jumps to the core function. So the case costs 1cmp+nop + 2jmp (go in&go out).
Zeydl...
This cases inside Resolve, Trasferlocate and getRectAddress is the source of numerous bugs, we SHOULD try to avoid this. For example, my current code fix Dark Cloud 1 issue (no resolve target's is not more needed). And there is many of it.

Revision 3840

- Enable patches is now on by default.
- Changed some configuration text, warning now that sVU is broken.

Revision 3841

* Fix a bug that prevented devel/verbose console logs from being logged in
Release builds.
* Switch microVU's cache logs to DevCon (verbose only). TODO: Make a vuPerfLog
for them someday.

Revision 3842

Made some more mVU messages tied to verbose flag.

Revision 3843

Bugfix for rounding/clamping mode patches not being applied (and possibly some
other obscure cpu settings bugs as well).
Cause: there were accidentally 2 instances of 'Recompiler' in the Pcsx2 emulator
settings structure.

Revision 3844

Lots of updates and fixes to the game database file.
Thanks to Lana for much of this ;)
konaj...
small update needed for game Drakengard
GameIndex.dbf
Serial = SLUS-20732
Name = Drakengard
Region = NTSC-U
Changes needed:
eeClampMode = 3 so the characters are visible in-game.
compat can be changed to 5 since its playable.
ramapcsx2
Thanks, it'll slip in next update :)
konaj...
Update needed for game Eternal Poison
GameIndex.dbf
Serial = SLUS-21779
Name = Eternal Poison
Region = NTSC-U
Compat = 1
changes needed
eeClampMode = 0 (makes in-game background visible)
Compat = 5
konaj...
Another update this time for game Primal (patch was made by me)
GameIndex.dbf
Serial = SCUS-97142
Name = Primal - Civilization Is Only Skin Deep
Region = NTSC-U
Compat = 4
Changes needed:
Compat = 5
[patches = FCD89DC3]
comment=Loading crash Fix (patch by hyakki)
patch=0,EE,00391DA4,word,00000000
[/patches]

Revision 3845

newdmac: Fixed bugs in FIFOs and SIF DMA transfers. Emulator currently
stalls/fails due to what appears to be errant handling of dmacInterrupt
requests.

Revision 3846

wiki: update some Ubuntu links

Revision 3847

GregMiscellaneous: zzogl-pg: restore the reverse order loop
Zeydl...
I think that update_4pixels code is non-effective. Why? because I read a manual, andnotice the "Pixel arangement scheme in a column". Do you know, where is located pixels 0, 1, 2 and 3? I miss this first, but it's x,y = (0,0), (0,1), (1,0) and (1,1). And for each even x,y this would be correct.
So our 4 pixels have same vertex. And data (u128*)dsct_tmp could be placed in 1 operation. We just need to get RW(base_ptr) -1, RW(base_ptr), RW(baseptr + pitch) - 1 and RW(baseptr + pitch) pixels. Then convert them if needed and put in (u32*) dst_ptr as dst[0], dst[1], dst[2] and dst[3]. We only need to keep i and j even in this cycle.
gregory....
Hum, actually I'am not surprised. Code in x86-32.S does somethings similar.
Just to be sure of one things. Data in src (without AA) are in the following form
0 1 4 5 ...
2 3 6 7 ...
And data in dst are standard aligned
0 1 2 3 4 5 6 7
In this case maybe we can also process 8 pixels instead of 4.
gregory....
Bonus, you could als use a non temporal store. It will reduce a little cache pollution.
Zeydl...
You understanding of Swizzle is not exactly correct. dst is data store in one of PSMT formats. It's swizzled, and PSMT16 are stored 2 pixels per 1 word. On contrary, src is a result of glGetImage command -- it's PC's texture, that was return to the memory. It have natural order (0.0, 0,1 etc). g_pageTable is a table, that return 32-bit address of pixel (i, j), it was build according 8.3 paragraph of GS user manual.
You could number of pixels's in src according dst addresses, but it's have no physical sence. So pixels of real texture
0.0 1.0 2.0 3.0 4.0 5.0 6.0 7.0
0.1 1.1 2.1 3.1 4.1 5.1 6.1 7.1
have addresses
0 1 4 5 8 9 12 13
2 3 6 7 10 11 14 15
And I don't think that 8 pixels (really even 16 -- this 8*2 structure is the similar for every PSMT) give us a noticiable bonus. 4 pixels in line is one 2*2 block, and it's fast to convert. with 16 pixel you could save a few call of g_pageTable. Not much.
gregory....
Yeah I inverted the 2.
The gains with 8 pixels is probably weak. We could still load and store 8 pixels. I have a 8 pix implementation but can still be removed later.
For the table I'm good with the 32bits one. But the memory layout is not clear for 16bits pixels (probably the alignment trick).
Begin of the table g_pageTable16[0] is
0xeedb7440 <g_pageTable16>: 0 2 8 10
0xeedb7450 <g_pageTable16+16>: 16 18 24 26
0xeedb7460 <g_pageTable16+32>: 1 3 9 11
0xeedb7470 <g_pageTable16+48>: 17 19 25 27
How does it map with the one in the manual ?
gregory....
Hum I need a confirmation of 16 bits texture.
The destination of the 12 first src pixel will go to 0L 1L 4L 5L 8L 9L 12L 13L 0H 1H 4H 5H. In others word data need to be interleave with previous value. In this condition 4pixels will be easier.
gregory....
Ok I made somethings in r3860

Revision 3848

GregMiscellaneous: zzogl-pg: Disable the Resolve messages by default.
arcum42
I also made them all consistently only show up on a Dev build...
actact9...
TNX another great commit arcum cant wait for the zzogl to be just as good as GSDX
hmm!! forums are down today wonder why

Revision 3849

Even more database updates from Lana :)
tmkk...
Final Fantasy - Zodiac Job System [with bonus DVD] (NTSC-J)
[SLPM-66750]
STATUS=PLAYABLE
(i can even say that is perfect)
I completed this game on PCSX2 :)
konaj...
added two more games that need updating in the db check comments in revision r3844
I also made a Primal NTSC patch so the game gets past the loading crash.

Revision 3850

Fix the VU interpreter (and occasionally sVU) addressing change from r3697.
Fix an sVU regression from way back in r3549 (God of War, Tales of the Abyss).
ramapcsx2
Good job.

Revision 3851

GregMiscellaneous: zzogl-pg: Nice comment to decipher asm code.

Revision 3852

wxWidgets/MSW: minor fix for debug assertions under WinXP OSes.

Revision 3853

* Disable Ok/Apply/Cancel buttons on dialogs while settings are being applied,
prevents potential deadlock when accidentally double-clicking the buttons.
* Add preliminary code for selectively disabling spam-heavy hardware registers

Revision 3854

newdmac: more bugfixes. SIF working quite fine now, bios/boot still failing
though on some yet-unknown cause.

Revision 3855

Made the installer create a cheats directory as per request.
Remove the sVU is broken warning, since it's been functionally restored.
hst...
where can I download this version?
hst...
thank you very much!

Revision 3856

w32pthreads: remove some unnecessary cleanup code being run on critical errors,
which was only causing confusion when debugging thread crashes.

Revision 3857

UI bugfix for speedhacks being improperly applied even when speedhacks were
disabled.

Revision 3858

... simplified code for the last bugfix. :p

Revision 3859

newdmac: minor dmac register logging bugfixes.

Revision 3860

GregMiscellaneous: zzogl-pg:
* Redo update_4pixels_sse2. Do 128 bits transfer instead of 32bits.
* fix regression on target code. The address was bad in 16bits
gregory....
Note: I test a little on FFX, I did not see any regression with the new code. But I'm not sure that mov/store are always aligned.
gregory....
Hum the code generated by gcc for 16bits texture is wrong.
There is probably something wrong with the following instruction...
pixels_0 = _mm_andnot_si128(imask, pixels_0);
Will fix that tomorrow
Zeydl...
By the way, it's possible to buy GS user manual:
http://www.amazon.com/playstation-GS-users-manual-2nd/dp/B001DZ4L4C/ref=sr_1_3?s=books&ie=UTF8&qid=1285709478&sr=1-3
And honestly, I think that I miss something about 16-bit psms. Pixel arrangement order in column (16*2 block) are following
0 1 4 5 8 9 12 13 | 0 1 4 5 8 9 12 13
2 3 6 7 10 11 14 15 | 2 3 6 7 10 11 14 15
bits 0-15 bits 16-31
I recode SwizzleBlock function and found, that this is mean that in word 0 we store 0, 0 (at lower part) and 8, 0 (at upper part),
at word 1 -- 1, 0 (at lower part) and 9, 0 y (at upper part). And so on.
gregory....
Your sentence is quite cipher for me :)
Here my understanding. Lets take the following 16b pixels:
0L 0H 1L 1H 2L 2H 3L 3H 4L 4H
After swizzle we get:
0L 1L ....... | 0H 1H .......
2L 3L ....... | 2H 3H .......
gregory....
Note: it is based on the value on the gTable.

Revision 3861

GregMiscellaneous: zzogl-pg:
* Really add the new resolve function (the good things is I fix severals issues)
* Fix an issue in 32b to 16b conversions

Revision 3862

GregMiscellaneous: zzogl-pg:
* Properly update the different part of the pixels.
Zeydl...
By the way. Look at TRANSFERLOCALLOCAL_4 define (in targets.cpp). It have copy-paste error, it does not handle 4-7 pixels (only 0, 1, 2, 3, 2, 3, 2, 3). It should be 0 - 7.
gregory....
Thanks

Revision 3863

GregMiscellaneous: zzogl-pg:
* Fix a long copy/past error in hostmemory
arcum42
Well, there are definitely issues with Resolve_32b. In Baroque, the text on the opening movie is missing (I think psm is PSMCT16S in this case). There are a few other graphical issues in Baroque once you start playing.
And all of them go away if you disable OPTI_RESOLVE_32...
gregory....
Could you comment "#define DO_8_PIX" in Resolve_32b loop. It will use 16bits addressing code path in sse instead of the 128bits one.
gregory....
With OPTI_RESOLVE_32 enable
arcum42
I still have missing text if I comment out DO_8_PIX with OPTI_RESOLVE_32 enabled...
arcum42
Here's a dump of the beginning of Baroque; just make sure to skip the bios, and press start when a black dot appears on the grey background (because I skipped most of that movie).
The missing text is on the movie after a new game, when you hear "His EEG readings are moving violently!"...
http://rapidshare.com/files/422640122/baroque.tar.bz2
gregory....
Hum, I found 2 stupid bugs ;) The first one impact all the sse code path. The second one only the 16 bits code paths.
Index: pcsx2.snapshot-3811/plugins/zzogl-pg/opengl/targets.cpp
===================================================================
--- pcsx2.snapshot-3811.orig/plugins/zzogl-pg/opengl/targets.cpp
+++ pcsx2.snapshot-3811/plugins/zzogl-pg/opengl/targets.cpp
@@ -3327,7 +3327,7 @@
mask[1] = mask[0];
mask[2] = mask[0];
mask[3] = mask[0];
- pix_mask = (imask<<16) & imask;
+ pix_mask = (imask<<16) | imask;
}
else
{
@@ -3420,7 +3420,7 @@
#ifdef ZEROGS_SSE2
Tdst* basepage;
// A bad hack for the moment
- if(do_conversion) {
+ if(texture_16b) {
basepage = pPageOffset + (i_div + j) * 4096;
} else {
basepage = pPageOffset + (i_div + j) * 2048;
One big question, how are dumps working ? How create them ? How load them ?
arcum42
The way you create one is that you switch to using the CDVD plugin. When you configure it, check the checkbox that says "Create a dump of the running iso". Then you choose to use the plugin in the CDVD menu.
You then play through part of a game, and it copies the parts of the iso that are accessed to a dump file. (It has the name of the iso, with dump for an extension)
You (or someone else) can then run the dump file as if it was an iso. However, if the game tries to access any areas of the iso that weren't accessed when it was dumped, the game will essentially act as if there was a bad spot on the disc. ^_^
It's mainly useful for troubleshooting, when there's a bug in a game you don't have. Note that creating a dump isn't always reliable. (mainly because games could access different areas of the disk every run randomly in areas, depending on the game. Tekken doesn't dump well, for example.)
gregory....
Ok. Very nice features actually. It will more easier to debug. Unfortunately previous patch did not work...
gregory....
My alpha shift was wrong of 1. So all 16 bits textures were transparent ...
arcum42
Ouch. That would do it. And that'd be a fairly hard error to spot...
gregory....
Yeah it is more easier to spot graphical corruption rathen than missing special effect. Otherwise with the testcase it was easy, the non sse version was good and the major difference is the conversion. Do not know if you already try, but intrinsic is much more gdb friendly. You can print variable content with x/4x <variable> (the print command print the address...).

Revision 3864

GregMiscellaneous: zzogl-pg:
* Windows compilation fix
* Fix alpha value & mask value
arcum42
That took care of it!
(And if you happen to play with that Baroque dump a bit more, and notice that the text sometimes gets messed up after talking to the angel and picking up the gun, that's a pre-existing bug, so we don't need to worry about it for the moment...)
btw, I recommend saving away any dumps you pick up, for later use in testing. Baroque looks like it's good for testing 16S resolves.
(I've done that with a few dumps. Ape Escape 3, for example.)
arcum42
So far everythings looking mostly good, and the only issue I've been encountering is one I have issues with occasionally anyways.
I'd personally say that if you don't see any issues on your end, let's go ahead and merge it in. We can always fix any minor issues afterwards.
gregory....
I'm good. I want to add the emms clear for windows. Then I will try merge the branch
arcum42
Sounds good. You may want to up the version number in GSMain, too. I tend to forget to do that. I'm sure this should be higher then 0.2.0...

Revision 3865

debian:
* update copyrigh info
* create a stable "branch" of the package

Revision 3866

GregMiscellaneous: zzogl-pg:
* Add an emms because msvc is not happy.
gregory....
In the future it will probably be good to see what does exactly the compiler.
I saw old messages that said msvc is inefficient with intrinsics (vs gcc or icc)
arcum42
Hmmm... Still having msvc issues. For the moment, lets move the __mm_empty statement to the end of update_4pixels_sse2, and only define DO_8_PIX in Linux. That way we can go ahead with the merge, and figure out what's wrong with update_4pixels_sse2_bis on Windows later...

Revision 3867

GregMiscellaneous: zzogl-pg: Work around a windows crash by temporarily
disabling DO_8_PIX in Windows.
arcum42
We can work out why it's crashing in Windows later, but for now, this will work, and will let us concentrate on getting this version of zzogl-pg in trunk... :(
gregory....
yeah, one issue at a time.

Revision 3868

zzogl-pg: Merge back GregMiscellaneous branch (3867)
* Various clean
* Replace ASM by intrinsics (much more portable)
* Various performance tuning (expect 10%-20% speedup ^_^ )
wing...
YAY!!! =)
The time has come for us to test all those changes.
romulux_...
I have a question that has been puzzling me for some time... Is ZZogl usable in Windows (Win 7 in my case), or is it Linux only ?
iakobo...
you can use it in any system that supports opengl (windows have it :P )
Ragha...
Technically asm using Intel syntax is more portable than intrinsics, however GAS sucks which screws up Linux portability. (Then there is FASM, which supports correct ASM programming.)
ASM is most often used for stuff that shouldn't be reordered by compiler. While a flag: "this ASM code can be optimized" would solve the problem, Intel tried to sell SSE2 registers and invented something different: Hey look intrinsics, these are so simple even C++ programmers can use something so C++ looking, it looks like higher level language so it must be comfortable. (Intel marketing department isn't exactly sane, I still remember how they called SSE instructions "A great stuff for internet browsing".)
So two questions.
Have you tested it properly?
Is image quality at GSDX9 level?
Re romulux
You should install newest drivers for your GFX card. (OpenGL libraries are part of these drivers.)
gregory....
Well, intrinsics has the advantage to be amd64 compliant. Moreover control flow can still be written in C and optimized by the compiler (less asm code). Marketing department is maybe not sane, but Intel is the first micro-electronics industry...
We made some tests to spot major regressions. Now it needs some test by users :)
Actually I do not have windows, so I cannot compare with GSDX9. However I read that zz is slower with more graphical glitch.
ramapcsx2
Yea, GSdx has less bugs and is quite a bit faster.
The difference depends on what the games do but I've seen GSdx reach 120FPS when ZZogl gets 30FPS.
This difference is carried over from the first ZeroGS OGl versions.
I guess the emulation bugs compared to GSdx should get a priority now? :p
gregory....
There is some majors work on going to rewrite some parts of ZZ. It woulds probably add new bugs and remove old ones. But the code will be cleaner and easier to fix.
Current priority is to increase the user base.
-> More speed. Well more than 30fps ;) If we you 60 fps instead of 30, more user could test it.
-> Distribution of PCSX2 by linux distribution. The three biggest barrier for this one are
- the 32 bits compatibility layer.
- few files with not clear licences.
- replace cg by pure opengl.
We need times ZZ have room for lots of improvement ;)
ramapcsx2
Sounds like a plan :p
And yeah, I avoided all the 64bit issues by simply going Ubuntu x86 :p
atia...
I want to see the times zzogl is much better than gsdx!

Revision 3869

* Bugfix for Issue 850 - memorycards being deleted when swapping slots.
* Preliminary work done for Issue 735 : allowing specified custom memorycard
filenames.

Revision 3870

* Implemented GIF PATH/TAG logging option.
* Some other EE/Core logging additions and formatting tweaks.

Revision 3871

zzogl-pg: fix the crash problem in msvc/sse intrinsics, and avoid compiler use
of MMX by using the SSE version of 64-bit loads.
Jake.Stine
I couldn't actually reproduce the crash, but the codegen is much more sane now with the proper intrinsic loads, so I'm pretty confident the bug is fixed now. Lemme know if not. :)
gregory....
Thanks very much.
ramapcsx2
Can't spot any crashes in multiple games tested. Seems fine :)
arcum42
We should actually still define DO_8_PIX. The workaround was having it not defined in Windows, so that Windows used update_4pixels_sse2 instead of update_4pixels_sse2_bis...
Jake.Stine
@gregory:
it's really kinda silly too; the _mm_movpi64_epi64() function is basically equivalent to:
xmmreg = mmxreg;
(with special handling of indirect memory and immediates and such, which load into an mmx reg internally and then assign to an xmm). But yea, there's never any actual reason one has to use the function; since its the equivalent of loading into an mmx register and then moving the contents of the mmx register to an xmm register. ;)
Jake.Stine
@arcum: woops. I removed the ifdef right before I committed. I had it set properly while I was testing. -_-
Zeydl...
Well, this concrete example of intrinsincs code give a hint -- never use assembler any more. Such much work without noticeable speedup agains C-code.
gregory....
Actually I still have some improvement for later.
But I agree with you intrinsics is tricky. To be sure the code is correct, I read the asm... In my opinion, the wrong idea is to thinks intrinsics is higer level than asm.
arcum42
@Jake: Still having issues. My test case is going into Kingdom Hearts 1, and starting a new game...
Jake.Stine
Alright, I'll check it out.
gregory....
Does it work in linux ?
Jake.Stine
Also, regarding intrinsics; I think Intel had intended for them to be high-level when they first started the intrinsic project in the early SSE days, but then they made the instruction set so bizarre and non-intuitive to programming actual tasks, that using SSE efficiently will always require micro-management at the instruction level. -_-
arcum42
Yeah, it works fine[1] in Linux. That's why I'd only disabled DO_8_PIX in Windows.
[1] Aside from the usual whacked out opening movie colors. But that's been that way forever.
gregory....
Could be this part: maybe there is some alignment constraint ?
__m128i imask = _mm_cvtsi32_si128(pix_mask);
imask = _mm_shuffle_epi32(imask, 0);
GCC generate this code:
2f7: 89 9d e4 fe ff ff mov %ebx,-0x11c(%ebp)
2fd: 66 0f 6e 95 e4 fe ff ff movd -0x11c(%ebp),%xmm2
305: f3 0f 10 ca movss %xmm2,%xmm1
315: 66 0f 70 c9 00 pshufd $0x0,%xmm1,%xmm1
Jake.Stine
Ok the crash is because:
__m128i pixel_0_high = _mm_loadl_epi64((__m128i*)(base_ptr + 1 + src_pitch));
(base_ptr + src_pitch) ends up being past the end of the source buffer. In windows, this causes a GPF, probably because it aligns closer to the end of a 4k page boundary or what-not. But yea, in the end its reading data past the end of the buffer in both Linux and Windows, I suspect -- its just not crashing in Linux (yet).
Jake.Stine
After considering the option, I would suspect the best fix is to make sure the buffers are all allocated with one extra scanline worth of reserved (you should also make sure there's an extra pixel worth of reserves to the right side of each scanline too).
Adding conditionals would murder performance. Adding special handlers for the bottom scanline and right-most pixel would have reasonably good performance, but is probably more cumbersome than allocating a slightly larger buffer (though I'm not sure -- adjusting the framebuffer's allocation size could be problematic as well, so maybe I'm wrong there).
gregory....
Hum, could you tell me if maxfbh if odd or even. I suppose it was even but I could be wrong
Jake.Stine
If you do the extra scanline buffer allocation, the bottom scanline needs to be black -- though it'll cause the bottom scan of the result to be dark. If you choose to use special handlers for bottom and rightmost pixels, then you can just copy them/or blend them with themselves -- probably yielding a better visual result.
In any case choosing and implementing the fix is outside my scope of effort at this time, so good luck and have fun. ;)
Jake.Stine
>> Hum, could you tell me if maxfbh if odd or even. I suppose it was even but I could be wrong
maxfbh == 0xD9
so i==0xD8 when the crash occurs.
gregory....
Thanks.
Here the plans:
- use the old methods for the moments. I will change it with some others change and clean.
- fbw is a multiple of 64 so rightmost pixels are good
- I will probably add an extra handler for the bottom line. Most of the time the size is surely even so no performance impact.
However still one issue:
The current method have some hole (perhaps uninit memory) in the frame buffer... I'm curious what GS does in this case.

Revision 3872

Fix for some general slowness in Release builds, accidentally introduced in
r3724
romulux_...
nice slowness hunting you performed, important fix, thanks.
wing...
Compilation is broken on linux:
[ 76%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/gui/Dialogs/FirstTimeWizard.cpp.o
[ 76%] Building CXX object pcsx2/CMakeFiles/pcsx2.dir/gui/Dialogs/GameDatabaseDialog.cpp.o
/home/wingnux/pcsx2-read-only/pcsx2/gui/Dialogs/CreateMemoryCardDialog.cpp: In member function ‘void Dialogs::CreateMemoryCardDialog::OnOk_Click(wxCommandEvent&)’:
/home/wingnux/pcsx2-read-only/pcsx2/gui/Dialogs/CreateMemoryCardDialog.cpp:125: error: ‘class AppConfig’ has no member named ‘McdCompressNTFS’
/home/wingnux/pcsx2-read-only/pcsx2/gui/Dialogs/CreateMemoryCardDialog.cpp:125: error: ‘m_check_CompressNTFS’ was not declared in this scope
make[2]: *** [pcsx2/CMakeFiles/pcsx2.dir/gui/Dialogs/CreateMemoryCardDialog.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [pcsx2/CMakeFiles/pcsx2.dir/all] Error 2
make: *** [all] Error 2
tatsuy...
Sky Odyssey intro lost 10 FPS.. it was recently bumped to 57 FPS now its 47 again.
ramapcsx2
I went through some revs beginning with r3113. The intro is always the same kind of speed.
There is a speed bump of a few fps beginning with the IPU speedup revisions.
Note that the intro is especially slow due to how it uses the GS.
FFX-2 does a similar thing.

Revision 3873

zzogl-pg: oops.

Revision 3874

Linux: Compilation fix.
gregory....
You beat me of 2 minutes ;)

Revision 3875

zeropad: Properly setup the path of the ini file.
+ metadata of my previous zz merge

Revision 3876

Likely fix for Issue 825 : converted NVM/MEC file routines to unicode (fixes
"file cannot be created" errors for users who's names are not english)
ramapcsx2
Seems to work :)

Revision 3877

wxWidgets/MSW: Likely fix for "cannot commit changes to pcsx2.ini" type errors.
ramapcsx2
Works.

Revision 3878

Lilypad: fix ini file support on non-english systems (unicode compliance issue).
Details: The "%S" directive in sprintf() only does a shallow wide char
conversion from ASCII, it does not actually convert UTF8 to UTF16. Replaced it
with a call to MultiByteToWideChar.
ramapcsx2
Works as well. :p
xat...
Could you set Lilypad to look in the user directory by default? PCSX2 standard behavior looks in user directory, but Lilypad still looks within pcsx2's folder i.e. when loading bindings.

Revision 3879

Sync with portaudio r1541 at rama's request.
Too many changes to list here, check portaudio svn log from r1505 to r1541 if
you are curious.
Hope it works fine.
ramapcsx2
Thanks :)

Revision 3880

SPU2-X:
- Use the cross-platform mbstowcs() function to convert from
ansi/ascii/multibyte/utf8 (whatever) to widechar instead of MultiByteToWideChar.
Allows linux people to configure the portaudio device in the .ini.
- Set the requested portaudio latency to 0.2f (200ms) instead of 0, since
apparently it's bad to request 0, and 200ms is a sensible(ish) default.
- Comment out the call to Pa_Terminate on Close, since it causes issues when
re-initializing later. Preferably, we should add some Init() +
Shutdown()/Terminate() functions to the output module system to allow for one-
time initialization and termination, but this will have to do for now.

Revision 3881

SPU2-X:
Quick workaround for the soundtouch / portaudio device selection / latency
issue.
Let's simply increase the default output latency to 300ms so even a "default
device" in Linux will work.
ramapcsx2
A proper fix for this whole thing would be coding up a gui part that queries all available devices, then letting the user decide on which to use. Aka a ton of work :/

Revision 3882

debian:
* forgot to remove some unstable stuff
* Remove a bad tabulation in control file...

Revision 3883

newdmac:
* fix many bugs (mostly word/qwc size mismatches, and a few printf formatting
errors)
* BIOS boots up now; BIOS clos works nicely -- memorycard screen exhibits
errors still.

Revision 3884

newdmac: sync with trunk r3840-r3882
(mainly because it fixes release build slowness due to logging)

Revision 3885

Another round of game database updates by Shadow Lady. :)
konaj...
I also posted a few updates in r3844 comments.
(for games primal and eternal poison)
nefer...
Thanks for that, cotton mentioned this earlier when the database got implemented but maybe we should add an issue or forum thread specifically for database changes. It gets too outdated fast
tmkk...
Also in https://code.google.com/p/pcsx2/source/detail?r=3849 there are some new updates

Revision 3886

spu2-x: Remove Decoder.cpp.
arcum42
I'm trying to make sure that this works in Windows & Linux, so I'm breaking it into a few commits.
gigaherz
Yay finally someone did that :P
arcum42
Yeah, I'd wanted to for a while, and since the talk about dependencies for the beta turned into a discussion of liba52, I thought it was a good time to do it.
No need to have the plugin depend on libraries being installed that it isn't really using, after all...
gregory....
Yeah, good news. IMHO, this dependency cause too much issues for nothings.

Revision 3887

spu2-x: Remove liba52.

Revision 3888

Update codeblocks to take the last two commits into account.

Revision 3889

Get rid of the *other* copy of liba52, and make sure cmake doesn't look for it.
arcum42
All right, think that's all of them. spu2-x has one less dependency, and is now a smaller plugin...
gigaherz
\o/

Revision 3890

debian:
* drop the liba52 dependency too
sunnydra...
last ppa versions of ubuntu missed pad plugin.
gregory....
Ah crap, I forgot to update it after the beta release.. Thanks for the reminder. Do not hesitate to ping me in case of issue, I used a debian distribution, so it is not easy to test the package.
Anyway, I upload a new version.

Revision 3891

newdmac: IPU work. IDEC (sorta) works, fmvs are still broken. >_<
eliotfur
I see your project is close to completion... I wish you infinite patience...
Jake.Stine
It actually plays Disgaea and Disgaea 2 to near perfection (with the skip mpg gamefix enabled). Fixing IPU shouldn't be hard, I'm just overlooking something obvious in the dma/fifo data transport stream, I think -- causing some kind of misaligned data/fail.

Revision 3892

Edited wiki page CompilationGuideForLinux through web user interface.
gregory....
Forgot to enter the comment....
Remove useless dependency.

Revision 3893

newdmac: minor FIFO fixes, and added a boolean for enable/disable of VPU
recompilers.

Revision 3894

zzogl-pg:
* Rework resolve function to reduce memory transfer in 16 bits
* Big clean
* Handle corners case when fbh is odd. For the moment I copy the line.

Revision 3895

newdmac: some VIF bugfixes, including correct I-bit handling and properly
stalling VIF transfers.

Revision 3896

newdmac: woops. this fixes the last commit (which broke everything)

Revision 3897

newdmac: more VIF fixes and logging additions.

Revision 3898

newdmac: fix a logging crash.

Revision 3899

newdmac: fix a nasty little bug in the VPU's STRow/STCol and MPG commands.

Revision 3900

newdmac: SIF bugfix which caused IOP memory corruption on especially large
transfers.
frost....
What is diffrence betwen newdmac and usual trunk?
ramapcsx2
Newdmac replaces PCSX2's most emulation component, the PS2 dma controller.
Once done, we hope to raise compatibility a lot :)
ramapcsx2
* most hacky emulation component

Revision 3901

newdmac: had toSPR/fromSPR inverted (major bug!), should fix tons of crap. Also
did some preliminary MFIFO retooling (still not done).
azte...
what tons of garbage are you referring to?

Revision 3902

newdmac: redid IPU to use FIFO exclusively (no direct DMA hacks); fixes a few
more FMVs. Most still hang after a few seconds, it seems. >_<
SNP_Tira...
Any estimation as to how this will compare to the current DMAC speed-wise?
keb...
sorry if you get this question a lot (i've been out for sometime), games aren't supposed to boot with this new dmac right? at least none of mine do
Kar...
Kebrus: Right, hence the modified files being in /branches/. The code is kept seperate until it's stable enough to merge with the rest.

Revision 3903

zzogl-pg:
* Finish to convert ASM to intrinsic
* Force the pointer outsides of the screen in fullscreen
* do not compile useless files
gregory....
I test severals without graphicals issues, so I'm pretty confident that it is not too buggy.
Note: if it broke windows compilation, ping me :)
gigaherz
// Note: Use big value instead of width/height to be sure it is really out of the screen
That won't work if someone happens to have a 4096x2048 screen!! ;P
I'd suggest width*2, height*2 or similar.

Revision 3904

newdmac: minor fixes, still major IPU compat issues and no MFIFO yet.
Jake.Stine
I'm totally stumped on why IPU's not working.
Grandia 2's vids play but have occasional garbage that looks indicative of SPRAM processing glitches.
Atelier Iris 3 vids play for a few seconds if I screw around with the DMAC and disallow the GUST fmv engine from rewriting dma.CHCR on-the-fly.
... so at this point I'm going to assume that the problem lies in the DMAC's (in)ability to properly restore suspended transfers -- something the IPU does a lot. I coded it to specifically handle such things gracefully, though.
Jake.Stine
Nope, confirmed that DMA suspend/resume works fine. Problem is elsewhere.
Gradius V vid plays, but only 1/4th of the screen is visible (and the game itself is mostly missing). Not sure what's going on there yet either.
kaboo...
you make it sound like a "informatics horror" movie ^^
Jake.Stine
Ok the main problem *appears* to be more GIF-related than IPU-related.

Revision 3905

zzogl-pg: Add a checkbox to disable automatic hack enabling, and straighten out
the way auto-enabled hacks are being done a bit.
arcum42
This ought to get rid of that funky behavior with not saving hacks you checked if they are also automatically disabled.
The option to disable hacks will hopefully mainly be for testing, but could be used if a hack is doing more harm then good. (It's only in Linux right now, but I'll port it over to Windows later.)
Also, in the Linux dialog box, if you note an asterisk by a hack, it means that the hack is currently automatically enabled. (may not always appear at the moment, though.)

Revision 3906

spu2-x: Work a bit on the way multiple sound modules are handled in Linux.

Revision 3907

zzogl-pg: Add a usleep when toggled fullscreen.

Revision 3908

zzogl-pg: Update license
* zpipe.cpp is based on a public-domain example
* zpipe.h trivial file, I change the license to gpl
gregory....
The only remaining bad license are these 2 files ZeroGSShaders/zerogsshaders.(cpp|h)
But I think you can build zz without it. Now we are able to provide a nice tarball with a clean license status ^_^
Zeydl...
ZeroGSShaders could be removed, it now used only as fx -> dat compiller. Working shader file is ZZoglShaders, and it was made by myself with small parts of old code included.
gregory....
it now used only as fx -> dat compiler <= nvidia cg specific or also work for GLSL ? Anyway for the moment I just remove it of the debian tarball.
Oh, and another question what is the current status of GLSL ?

Revision 3909

debian: do not bundle ZeroGSShaders. Now the tarball is 100% free :)
SNP_Tira...
Not sure where this should be posted, but compilation hasn't worked on VS2010 in some time (pcsx2\PrecompiledHeader.h(87): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory)
gregory....
well I only work on linux ;) But I'm know that vs2010 is not supported. We can get VS2008. You could also try to fix the file (it probably miss some include path), you can also lurk in the issue tracker to find user patches. Hope it helps

Revision 3910

newdmac: fixed two major dma chain mode CALL/RET bugs. Huge compat boost.
IPU problems still persist and MFIFO is still not quite done yet.
azte...
how many games may be playable now with this boost?

Revision 3911

newdmac: fix for VIF1 source mode (VIF download to main memory from GS).
SNP_Tira...
Any estimate as to how this will compare with the current DMAC speed-wise?
kaboo...
is this (copy+paste) gonna be a two day thing?
but if you want an answer... faster, but it's more about compatability
SNP_Tira...
Thank you, and I apologize for repeating myself.
winterne...
Hmm fatal frame 3 seems to semi work. I noticed though that the game does eventually mess up. The in game textures will show for a bit then the console will start spamming "sceGsExecStoreImage: Enough data does not reach VIF1" and all the in game textures will disappear (White / Gray polygons). So whatever you're doing it's getting better because it didn't even get in game before.
atia...
@winternexus
How come? Fatal Frame III works perfectly and I've finished it long time ago.
SNP_Tira...
@atiamar
Using the old DMAC, perhaps. Winternexus was commenting on the new one.
winterne...
@atiamar
Like SNP said I'm not talking about the trunk but the newdmac branch. Anyway my comment isn't useful at all, but just a little encouragement. It'll get fixed probably once he fixes other things I'm sure.
ramapcsx2
atiamar:
Newdmac means it doesn't affect the PCSX2 you know and use.
Jake: Stuff doesn't actually download though. All reverse FIFO games have gsexecstoreimage errors :p
Jake.Stine
>> Jake: Stuff doesn't actually download though. All reverse FIFO games have gsexecstoreimage errors :p
No, several games use it for simple things during bootup, and they all work fine. You need to be more specific than "all." :p

Revision 3912

newdmac: fix for EE DECI2 console logging errors.

Revision 3913

newdmac: MFIFO implemented enough to boot FFX (and then crash, but whatever..)
tatsuy...
One of the latest revisions with newdmac/FIFO/FMV changes completely killed Sky Odyssey intro, freezes at the start of it.
pcsx2gu...
NewDMAC is in a branch so it can in no way affect anything unless you compile from that branch. So find which revision it was and comment in that one
ramapcsx2
The best thing is that with recent changes the game nearly works :p
And yea, trunk works 100%.
(No dice on FFX or FFX-2)
arcum42
Odin Sphere works relatively well. Baroque runs, but with missing graphics and text in places.
Of course, it doesn't compile unless I make a dozen source code changes in Linux, but that was expected...
lemuel2010
From r3879 many games crash!!! Why?
ramapcsx2
Because you're blindly downloading svn revisions from some site without knowing what they are.
Hint: If it says newdmac anywhere, it WON'T WORK (yet).
Wagnar...
I did not follow every discussion about this branch. I do know what the DMA is in ps2 but I would like to know the expected result of this new dma. What are the expected results of this new code.
Jake.Stine
>> Of course, it doesn't compile unless I make a dozen source code changes in Linux, but that was expected...
Yeah I do plan to hit the linux errors soon. I'm just swamped with other stuff tho still. >_<
Jake.Stine
>> I did not follow every discussion about this branch. I do know what the DMA is in ps2 but I would like to know the expected result of this new dma. What are the expected results of this new code.
The hopeful goals are:
* 20-40% speedup in many games.
* Full compatibility with nearly all games that currently don't like to boot.
* Forever rid of PATH3 masking and SIGNAL/FINISH synch issues.
arcum42
Eh, the big one was the issue with having constructors in tDMAC_ADDR, which I've mentioned in the past. (I just got rid of the constructors, and redid the only line that used it.)
Other then that, "ps2\NewDmac.h" should have been "ps2/NewDmac.h" a few times, and several spots need ._u32 at the end, because they aren't pod-safe.
And, of course, NewDmac.cpp wasn't in the codeblocks project.
Oh, and VifUnpackLoopTable is both static and extern. All and all, it could have been a lot worse...
Dhalai.L...
Sounds promising. +1
konaj...
drakengard fps up 20-30% when text onscreen (was a major slowdown factor in the old dmac), it was the only game i could get to fully boot to test with ^^

Revision 3914

trunk/stable: logging additions for VPU's VIFcodes

Revision 3915

newdmac: various maintenance work... dev notes:
* Renamed spr1dma/spr0dma to toSprDma/fromSprDma
* Renamed ipu1dma/ipu0dma to toIpuDma/fromIpuDma (and associated g_fifo
members)
* fixed some linux compilation errors and such.
* added missing newdmac savestate items (may not have covered them all yet)
arcum42
It's a good start. Here's what I did to get this revision to compile:
http://tinypaste.com/834185

Revision 3916

Minor tweaks to assist in comparing new and old DMAC behaviors:
* VIF now sends a 128 bit tag instead of a 64 bit tag (lower 64 bits masked to
0 -- this should mimic real hardware behavior more closely)
* Added more GIFtag logging info
ivicamar...
Great! Now that's 2 things that you have already done in r3000 (Dx11 and new DMAC). Can't wait for 24 threads support, SSE-X instructions and USB-vibrator support. And please consider 512-bit Win 14. Cheers!
atia...
^ lmao! great work by the way!
kaboo...
I really wonder if we ever will use more than 64bit OS and cpus in home desktops ... seeing as the industry takes over ten years to switch from one to another
also interesting would be to see when we'll turn from x86 compatible cpus...
gigaherz
Well I heard Microsoft was starting to think of the future, and made windows 8 able to be compiled for 128bit platforms, if they ever exist :P
kaboo...
neat in it self, but useless if every one continues to cling so desperatly to 32bit... hopefully better pc emulation in the years to come will loosen the grip somewhat...
SAMuham...
Tekken 5 SLUS_210.59 displays black screen after pressing start button.
FIFA 2007 shows similar type problem.
Tekken 5 log shows
----------
microVU1: Cached MicroPrograms = [003] [PC=0025] [List=01]
(Cache = 0.057%)
microVU1: Cached MicroPrograms = [004] [PC=0032] [List=01]
(Cache = 0.057%)
microVU1: Cached MicroPrograms = [005] [PC=0030] [List=01]
(Cache = 0.057%)
microVU1: Cached MicroPrograms = [006] [PC=00ec] [List=01]
(Cache = 0.057%)
microVU1: Cached MicroPrograms = [007] [PC=015c] [List=01]
(Cache = 0.057%)
microVU1: Cached MicroPrograms = [008] [PC=0000] [List=01]
(Cache = 0.099%)
microVU1: Cached MicroPrograms = [009] [PC=0500] [List=02]
(Cache = 0.099%)
microVU1: Cached MicroPrograms = [010] [PC=0010] [List=01]
(Cache = 0.099%)
microVU1: Cached MicroPrograms = [011] [PC=0500] [List=03]
(Cache = 0.814%)
Vif1: Unknown VifCmd! [a5]
Re-protecting page @ 0x00001
------
Using r3916. HW DirectX 11. SSE3.
r3915 shows no problem at all.
Thanks.
ramapcsx2
Flagging this rev as it breaks GT4 and Tekken 5. This VIF change needs investigating.
shadowladyngemu
Also kills killzone... nevermind not gonna make a killer joke :p
Jake.Stine
Ok, thanks. This change can be reverted in trunk anyway; and I'll investigate it further on my own later, since understanding this behavior is important for me and the new dmac.

Revision 3917

spu2-x: Misc Alsa stuff. Added a few missing files into the pcsx2 codeblocks
project.
arcum42
Headers don't have to be in the codeblocks project, but it's easier if they are. Most of the logging changes were just so the logging actually *works* in that file...

Revision 3918

zzogl-pg:
* rework isdirty intrinsic. I miss swizzle stuff in first try :p

Revision 3919

GregMiscellaneous: sync with trunk (3805-3918)

Revision 3920

GregMiscellaneous: zzogl-pg:
* redid the WriteCLUT_T16_I4_CSM1_sse2 functions (more generic, faster, cleaner)
* Create WriteCLUT_T16_I8_CSM1_sse2 based on WriteCLUT_T16_I4_CSM1_sse2
* Change some clut buffer offset... Probably impact the compatibility
gregory....
Note: I think it will be more clear and easier to use csa as an argument instead of clut for 16bits texture
gregory....
Hum, WriteCLUT_T16_I4_CSM1_sse2 core is incorrect...
Zeydl...
u16 *dst = (u16*)(g_pbyGSClut + 64 * (tex0.csa & 15) + (tex0.csa >= 16 ? 2 : 0));
Why 64?? What do you want to obtain? GSClut is u8*, so GSClut + 64 * x is mean that you pick 64*x byte of CLUT. This is 16-bit clut storage mode, that mean that each clut record is 2-byte length, and CSA == offset / 16, so starting byte is 32 * csa. So you code is different than Zerofrog's and I don't understand why.
p.S. I don't know, why Zerofrog put this (tex0.csa >= 16 ? 2 : 0))) for CLUT16.
gregory....
My understanding (but I'm maybe wrong that why I put in the branch ;) )
If you have the doc, look chapter 3.4.7.
The clut buffer have 512 16 bits entries. The arrangement in the clut buffer is
0 256
.. ..
15 271
16 272
.. ..
31 303
In 16 bits modes:
CSA 0 contains 0-15
CSA 1 contains 16-31
...
CSA 16 contains 256-271
CSA 17 contains 272-303
In 32 bits modes:
CSA 0 constains 0-15 and 256-271, low 16 bits (of dword packet) are 0-15 and the high 16bits (of dword packet) are 256-271
The current implementation of the buffer is 256*32 bits, in 32 bits we have CSA0 CSA1 ... CSA15.
In 16 bits they is an interleave of CSA_X and CSA_X+16. We have somethings like that
CSA_16<<16|CSA_0 ; CSA_17<<16|CSA_1 ...
So when CSA >= 16, we must take the high 16bits (of dword) hence the +2 bytes.
When CSA = 1, the real offset is 16 entries of CSA_16 + 16 entries of CSA_0 => 32*16bits => 64 bytes
gregory....
That explain why it is really tricky to write 256 entries in 16-bits clut.
If you start at CSA 14, the 2 first we must write the LOW bits of clut, and clut +1. Then you must go back to the clut base to write the HIGH bits.
Now I have a good question. What is the real behavior when you overrun the buffer ? Lets take 32 bits format. CSA 15 and index 8 bits (so 256 entries
What the write buffer do -> write 256*32 bits from clut+15*64 to clut+15*64+16*64.
What the target function do -> read 16*32 bits from clut+15*64 to clut+15*64+1*64 (so we only read 16 entries....).
What the hardware do ???
1/ Either nothings, just forget things above clut+16*64. Maybe some extra copy in I8 modes can be saved.
2/ Either wrap the buffer around, go back to the beginning and save data.
Actually it just depends of how much wire they puts for the address.
What game expect, I do not know

Revision 3921

GregMiscellaneous: zzogl-pg:
* Fix previous commit :)
ramapcsx2
Gregory:
I noticed that on Windows at least there is a performance problem with zzogl when you start it for the first time.
Start PCSX2 > start a game > 15FPS
If you restart emulation then (just do run CDVD again), speed goes up considerably.
Start PCSX2 > start a game > 15FPS > restart game > 22FPS
This happened for ages now. I assume some threading problem on first init..
gregory....
Hum, for the moment I understand the memory layout of GS :) Not the threading stuff :p Maybe porting the plugins to gsopen2 could fix this issue, I do not know.
In performance subject, did someone have either "spartan total warrior" or "orphen". Maybe PAL related. But these games spends a huge time in my ati driver (seems the gpu wait the cpu to send data). I'm curious what is the performance of GSdx and zz with nvidia drivers.
ramapcsx2
Don't have those but I could name a few games that trigger slow scenes in zzogl.
The xenosaga games are a good example but also the Level 5 engine ones (Rogue Galaxy, Dragon Quest 8, Dark Cloud 2).
arcum42
I actually do have a copy of Orphen, though I haven't done much with it. I pulled it out of a stack of $1 ps2 games that were at the counter of a local game store one day, IIRC...
The ones rama mentioned are good examples, though. Xenosaga I has one of the first few movies go down to 1-3 fps while spewing "Transfer error, width exceeded." if it's a debug build (from HostMemory.cpp; I think in InitTransferLocalHost.)
And DragonQuest 8, besides being slow in one section of the initial movie, has graphics issues at the same point. (It's been a while since I've played Rogue Galaxy & Dark Cloud 2, so I'm having trouble recalling problem spots at the moment...)
Oh, and looking through the plugin, I'm not even seeing much threading going on. That probably should go on the list of things to be looked in to.
I have been occasionally starting to play around with the Windows side of ZZOgl-pg and improve it, mainly because otherwise only the Linux side gets worked on. (Unfortunately I don't really know what I'm doing that well on that side, though...)
ramapcsx2
Well, if Dragon Quest 8 has glitches, the other 2 Level5 games will as well.
I remember ZeroGS looking way worse in these games back in the day though, so heads up ;)
The slowness issue may very well exist in Linux as well.
I'd try to convert the plugin to use gsopen2() first, as Gregory suggested.
This'd also fix the escape button not working! ;)
arcum42
Converting the plugin to use gsopen2 has been on the agenda for quite a while.
That's how GLWin32.cpp and GLWinX11.cpp came to be, in fact; I was separating out the platform-specific window code to make conversion easier.
The tricky part, from what I recall, was grabbing the widget passed to ZZogl in Linux and getting opengl rendering on it...

Revision 3922

GregMiscellaneous: zzogl-pg:
* Forgot to remove the dis-alignment

Revision 3923

GregMiscellaneous: zzogl-pg: Various legacy printfs were hanging around. Change
a few messages to just be in Debug mode.
arcum42
Not really an experimental change, but I didn't feel like redoing this in the main trunk, especially when I was going to be working in this branch a bit anyways...

Revision 3924

GregMiscellaneous: zzogl-pg: Remove the ZeroGS namespace.
arcum42
The fact the 3/4's of the plugin was in one namespace has been bothering me. Also, this makes moving things around a lot easier. (A few things I was thinking of doing were made rather more difficult because of the ZeroGS namespace.)
I may have to do some cleanup after this. I already renamed some of the more problematic functions...
gregory....
It was really needed.

Revision 3925

GregMiscellaneous: zzogl-pg:
* Keep same format when reupload the texture after an error...
* various minor clean

Revision 3926

GregMiscellaneous: zzogl-pg: Move target-related structures from zerogs.h to
targets.h.

Revision 3927

GregMiscellaneous: zzogl-pg: Shuffle more stuff around from zerogs.h.

Revision 3928

GregMiscellaneous: zzogl-pg: Add a new header. More work on zerogs.h.

Revision 3929

GregMiscellaneous: zzogl-pg: Create ZZKick.cpp & ZZKick.h, and move appropriate
code there.

Revision 3930

GregMiscellaneous: zzogl-pg: Add a header for HostMemory.
gregory....
Note: on my side, I move most clut related things into a new file :)
arcum42
That probably is a good idea. There are a lot of cases where things that really should be in separate files are combined.
I've basically been picking at zerogs.h, trying to make it go away, or at least not be included by every file.
Of course, I've been planning ZZKick.cpp & ZZKick.h for a while. Being in the zerogs namespace was complicating things, so I'd put it on the backburner for a bit.
I've even been thinking about splitting target.cpp & target.h into multiple files. Not tonight, though.
gregory....
There is a minor issue in debug build with HandleGLError.

Revision 3931

GregMiscellaneous: zzogl-pg:
* regroup clut core function into one big files
Note: codeblock need to be updated. And I hope template are ms friendly :)
arcum42
Looks like we're missing the two new files from this commit...
Zeydl...
I don't like you need arrangements. VB should not be in targets, it's Visual buffer, last stage of drawing -- output picture to screen. And target's is texture cache, Flush are settled between them. I don't understand, why do you push only Kicks outside? It's part of XYZ* routine, it's would be understandable if you push all drawing routine outside zerogs.h. And main transfer code located in Mem.cpp, in this ugly define (it was one of part's, I rewrite completely recently).
gregory....
Arcum, I added the file but codeblock need to be updated (do not want to break the syntax).
arcum42
@gregory.hainaut: No problem; I'll add it in.
@Zeydlitz: Regarding VB, I was planning on moving VB to ZZoglVB.h. There are dependencies between the VB and the 3 target classes I moved, though, so I moved it with them until I get them sorted out.
And I might go ahead and move the other drawing routines with the Kick functions. I just wanted to get them separate for the moment to make it easier to work with them.
And I've been watching what you've been working on with Mem.cpp. The thing is that I tore that all up a while ago, and got rid of most of the defines, and greg got rid of the fill blocks section that was remaining.
Once you're done with the rewrite, I'm probably going to see what I can do to integrate it, but I'm going to try to keep it define-free if I can...

Revision 3932

GregMiscellaneous: zzogl-pg:
* minor clean
tmkk...
When will be next merge with trunk?
arcum42
When it's ready.

Revision 3933

wxIsoFile (new branch): for introducing a heavily refactored built-in isoFile
system -- rewritten to utilize wxWidgets input streams, improve exception
safety, and fix a few minor bugs. Placing it into a branch awaiting Linux
compilation testing; hopefully to be merged into trunk in a couple days.

Revision 3934

wxIsoFile branch: (needs linux testing)
* Convert IsoFileFormats.cpp into a class.
* Use wxFile and wxFileInputStream instead of windows/posix specific file
functions.
* Added new ScopedAlloc classes, which are very simple dependency-free
templates for exception-safe allocations.
* FastFormatString: Improved performance ad fixed an obscure bug.
* Drag&Drop (UI) - Improved the friendliness and responsiveness, so that PCSX2
doesn't end up tying up an explorer window while it prompts the user or issues
error messages.
Jake.Stine
I'll try to do some linux testing on this myself in about 12 hrs, when I get back to my desktop PC.
gregory....
In short:
-> #include "ScopedMalloc.h" must be replaced by "ScopedAlloc.h" (Utilities/Dependencies.h, Utilities/StringHelpers.h) I think it only impact windows :)
-> inheritance issue. Maybe it need a .inl/.h separation.
The first gcc message
Utilities/ScopedAlloc.h: In constructor ‘ScopedAlloc<T>::ScopedAlloc(size_t)’:
Utilities/ScopedAlloc.h:145: error: class ‘ScopedAlloc<T>’ does not have any field named ‘BaseScopedAlloc’
Utilities/ScopedAlloc.h: In member function ‘virtual void ScopedAlloc<T>::Alloc(size_t)’:
Utilities/ScopedAlloc.h:157: error: ‘m_buffer’ was not declared in this scope
...
-> Utilities/Exceptions.h:46: error: ‘errno_t’ has not been declared
Win specific ?
Jake.Stine
ok, thanks. I'll fix it up shortly.

Revision 3935

GregMiscellaneous: zzogl-pg:
* It is better with the files:p
arcum42
Hmmm... You may want to run through that dump I sent you before for Baroque with the new clut routines.

Revision 3936

GregMiscellaneous: zzogl-pg: Add the Clut files to the CodeBlocks project...
Zeydl...
Why do you ruin a naming convention? I settle ZZogl prefix for all newer files for several reasons: 1) to see what code is Zerofrog untouched, and what is new, 2) to have better ording by names (all sources are started by Z in directory, that's usefull).
gregory....
Sorry, did not know, well I could guess. I will do the rename later, I want to finish somethings first.

Revision 3937

GregMiscellaneous: zzogl-pg: zerogs.h is now only included by zerogs.cpp.
arcum42
I probably could have deleted it, but I figure I can reuse it as a private header for zerogs.
This probably did add a few more externs scattered around in spots then I'd like, but I can always clean that up later...

Revision 3938

SPU2-X:
- Prevent the mixer from clamping to the maximum possible range as some audio
output modules hate that and start clipping. Notably portaudio is unaffected in
tests but all the MS APIs not ;)

Revision 3939

SPU-X:
- Changed defaults and ranges for the soundtouch timestretch parameters. This
reduces added latency from timestretching.

Revision 3940

GregMiscellaneous: zzogl-pg:
* Bad copy/paste: restore 256 entries texture

Revision 3941

wxIsoFile branch: fix missing includes and gcc compilation stuffs.
gregory....
It is a bit better. A compile test give these errors.
ScopedAlloc.h: In constructor ‘ScopedAlloc<T>::ScopedAlloc(size_t)’:
ScopedAlloc.h:145: error: class ‘ScopedAlloc<T>’ does not have any field named ‘BaseScopedAlloc’
For the 4 OutOfmemory
ScopedAlloc.h:163: error: ‘OutOfMemory’ is not a member of ‘Exception’
You miss some "this"
ScopedAlloc.h:159: error: ‘m_size’ was not declared in this scope
ScopedAlloc.h:161: error: ‘m_size’ was not declared in this scope

Revision 3942

wxIsoFile: And a couple more compiler fixes.
gregory....
Ok Round 3 :)
pxStreams.cpp:58&109: error: ‘errno’ was not declared in this scope
Exceptions.cpp: In constructor ‘Exception::RuntimeError::RuntimeError(const std::runtime_error&, const wxString&)’:
Exceptions.cpp:175: error: call of overloaded ‘wxString(FastFormatUnicode&)’ is ambiguous
/usr/include/wx-2.8/wx/string.h:698: note: candidates are: wxString::wxString(const wxChar*)
/usr/include/wx-2.8/wx/string.h:692: note: wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.8/wx/string.h:690: note: wxString::wxString(const wxString&)
/usr/include/wx-2.8/wx/string.h:689: note: wxString::wxString(const wxStringBase&)
/usr/include/wx-2.8/wx/string.h:682: note: wxString::wxString(int) <near match>
Exceptions.cpp: In constructor ‘Exception::RuntimeError::RuntimeError(const std::exception&, const wxString&)’:
Exceptions.cpp:187: error: call of overloaded ‘wxString(FastFormatUnicode&)’ is ambiguous
/usr/include/wx-2.8/wx/string.h:698: note: candidates are: wxString::wxString(const wxChar*)
/usr/include/wx-2.8/wx/string.h:692: note: wxString::wxString(wxChar, size_t) <near match>
/usr/include/wx-2.8/wx/string.h:690: note: wxString::wxString(const wxString&)
/usr/include/wx-2.8/wx/string.h:689: note: wxString::wxString(const wxStringBase&)
/usr/include/wx-2.8/wx/string.h:682: note: wxString::wxString(int) <near match>
The easy one:
I add "General.h" because it complains about missing stuff like _aligned_malloc. Probably not the best
Index: common/include/Utilities/ScopedAlloc.h
===================================================================
--- common/include/Utilities/ScopedAlloc.h (revision 3942)
+++ common/include/Utilities/ScopedAlloc.h (working copy)
@@ -16,6 +16,7 @@
#pragma once
#include "Exceptions.h"
+#include "General.h"
// pxUSE_SECURE_MALLOC - enables bounds checking on scoped malloc allocations.
@@ -188,7 +189,7 @@
class ScopedAlignedAlloc : public BaseScopedAlloc<T>
{
public:
- ScopedAlignedAlloc( size_t size=0 ) : BaseScopedAlloc()
+ ScopedAlignedAlloc( size_t size=0 ) : BaseScopedAlloc<T>()
{
Alloc(size);
}
gregory....
Note: it compiles successfully when I comment the bad parts.

Revision 3943

GregMiscellaneous: zzogl-pg:
* make code more consistent
* Use some sse2 for 16 bits texture
gregory....
16 bits clut texture would love some additional tests. But I need to find first which of my games use them. So I will do that later
arcum42
Mana Khemia uses 16 bit cluts.
http://rapidshare.com/files/425779417/manakhemia.dump.tar.bz2
(Note: lines on the screen are a known issue.)
gregory....
Thanks. Actually I bought the game, well I wait the post office delivery in a couple of days ^^ But the dump will be useful to test it now.
arcum42
Ah, cool. The game has a number of issues, so it's a good one to have anyways. (Besides, I like Gust games.)
Main issues you can see from the dump (not clut related) are:
a) the movie before and after a new game have lines through them. This is related to issues in the KickSprite function, as far as I can tell.
b) When you hit start, you'll notice it change to a picture from the start of the opening movie. It's calling MemoryTarget, and getting an old picture.
c) You'll notice some noise on several of the pictures. That's MemoryTarget as well.
Once you have the game, you'll notice more graphical corruption*, and more MemoryTarget stuff too. I just wanted to go over it so you know what of the issues you see *isn't* clut issues, and is pre-existing.
Most of the opening uses 16 bit cluts, though, so it should be useful. (And I know for a fact that it calls that line in CheckChangeInClut labelled "Mana Khemia triggers this". ^_^ )
*Not enough to be unplayable, just annoying occasionally.
gregory....
Manakemia definitely uses 16 bits textures. I get a crash at startup.
The local clut array is not 16bits aligned. It is defined inside the CMemoryTarget class as a vector<u8>. Is there any way to aligned this kind of object, or would be better to replace it with an u8* pointer ?
arcum42
Yes, and yes. It's possible, but the latter would be preferable. If you look at old copies of GetMemoryTarget in target.cpp, you can see what it used to do to manually align a vector<u8>, but I turned it into a u8* and used an aligned malloc instead...
refraction
Bully, GTA SA (I believe), Sly games, there's a couple for you :P

Revision 3944

wxIsoFile: ... and some more fixes.

Revision 3945

wxIsoFile: final annoying compilation error fixed. Just needs a little linux-
side testing now.
kaboo...
does that mean it's safe to try under windows?
pcsx2gu...
Yeah should already be working fine under windows (except for blockdumps iirc)
arcum42
All right, I've played a few minutes of several games under Linux with this revision on this branch, including Gradius V (which is cd based), God of War I (8 GB), Baroque, and a few other games. Seems all right so far. (Though the blockdump or two I threw in didn't work.)
Jake.Stine
Excellent. I'll fix the dumps when I have a chance, and then we can merge.

Revision 3946

cmake: * make FindGlew more robust & consistent

Revision 3947

GregMiscellaneous: zzogl-pg:
* 16 bits aligned the local clut array to allow sse2 operations

Revision 3948

GregMiscellaneous: spu2x:
* Copy wavfile back to spu2x directory. Note I shrink the file to only usefull
feature to keep it small.
Rationale: Wavfile is not delivered by the soundtouch library (it is an
example).
pcsx2gu...
AH that's nice, thanks gregory :)
Would be great if you could make it grab the game's name form the DB and rename the wav to that name (or use some default file name if the game isn't found in the DB)
That way we prevent accidental overwrites when recording a new video
gregory....
For the moment it does not impact the windows build. However Code block will need some updates.
gregory....
Your are sure fast :) I do not know if we have an easy access of DB information from the plugin. But it would be an interesting feature
pcsx2gu...
Yeah we get the feeds in the mIRC channel from a bot whenever someone commits :D I guess it can be easily ported to windows

Revision 3949

GregMiscellaneous:zzogl-pg:
* rename filename (Clut to ZZClut)

Revision 3950

GregMiscellaneous:zzogl-pg: Rename also the include....

Revision 3951

GregMiscellaneous:zzogl-pg:
* Forgot one line in previous commit

Revision 3952

GregMiscellaneous:zzogl-pg:
* fix sse2 code for 16bits cluts.
* Fix debug build
gregory....
Hum, There are still issue with clut things...

Revision 3953

GregMiscellaneous:zzogl-pg:
* More clut fix.

Revision 3954

wxIsoFile: fixed support for dumpfiles.
Jake.Stine
I'll be merging this in today.

Revision 3955

Merge wxIsoFile branch. Feature Summary:
* Better support for unicode/multilingual editions of Windows, and less hassle
with UAC (user access control).
* Allows use of iso images that are in use by other programs (such as daemon
tools, etc)
* Allows running multiple instances of PCSX2 concurrently on the same iso image
(useful for branch testing/debugging).
* Exception-safe and slightly better error handling.
* Better drag&drop behavior (doesn't hang the explorer window for as long as it
used to)
frost....
Good.I like merging branches.

Revision 3956

newHostVM branch created; implementation purposes:
* a mapped memory system for PS2 virtual machine areas (32mb main memory, 2mb
IOP memory, etc) that will be constant across all builds of PCSX2 (should fix
problems with 3rdparty cheat apps)
* virtual reservation system for recompilers; reduces the emulator's overall
memory usage while reducing the need for recompiler resets at the same time.
* recompiler resets (if/when needed) should be much faster.
frost....
So this branch is mainly because memory?
crushtes...
frost.fry, the description couldn't be more descriptive.
Jake.Stine
This branch's memory efficiency will be limited mostly to Windows -- Linux already does something similar as per its Over-commit "feature" (which is half awesome and half catastrophic voodoo).

Revision 3957

GregMiscellaneous:zzogl-pg:
* Add a sse test to compare GSMem and clut buffer
* minor 16-bits clut fix

Revision 3958

newHostVM branch: work-in-progress stuff...
Jake.Stine
The main code of interest here is RecompiledCodeReserve and BaseVirtualMemoryReserve, which are being implemented into System.cpp (the code locations are messy at the moment)

Revision 3959

newHostVM branch: (now boots games!)
* EE and IOP recompilers are using the new RecompiledCodeReserve class.
* PS2 main memory should typically be located at 0x20000000 (code still need
some cleanups)
VU0/VU1 recompilers will be implemented soon.
serban.a...
you are the man
ramapcsx2
Problems so far:
Savestates and tri-ace engine games. Otherwise seems to work :)
arcum42
Eh, Linux doesn't compile, but I'm sure that's expected. The changes to LnxHostSys.cpp need some proofreading...

Revision 3960

GregMiscellaneous: zzogl-pg: Continuing to work on zerogs.cpp and zerogs.h.

Revision 3961

GregMiscellaneous: zzogl-pg: Give VB its own header. Some changes to the Kick
functions.
arcum42
Forgot to remove that accidental change to zerogs. I'll take care of that in a bit...
gregory....
Hum, I thinks kick will need some minor improvement. Because these functions are called a lots, it really worth to gains few clock cycle. My rought ideas (not yet clear in my mind ;) )
1/ The idea is to save the triangle fan test & fn call functions. Maybe you can merge draw and kick into a big template function and play with funciton array. I need to think more about it.
2/ move conf.settings() outside. The hack configuration is constant during emulation, so you could avoid to test them every vertex. It seems I gain 1fps when I comment the conf stuff.
3/ Sprite function. There are 2 vertices but SetKickVertex is called 6 times. 4 call can be replaced by some memcpy (or plain affectation not sure what it is faster).
Opinions are welcome :)
arcum42
I agree that kick could use work. That's one reason why I pulled it out into it's own file.
Since Zeydlitz said every line in NoHighlights besides the last one should be removed, we should probably go ahead and do that. (He also mentioned that Mana Khemia should have the Gust hack removed; I just haven't gotten to it.)
As far as settings, conf.settings().texa appears to be a hack that changes the way colors look. We could probably comment it out, and remove it from the dialogs. Not sure if anyone uses it, though.
And the sprite function could use work anyways, since it has that AA hack in it. At least we already know a spot that can be tested with changes to it...
gregory....
Yes the AA hack it really bad. I have a nice jail in spartan (menu, it crash ingame) when enabling the AA.

Revision 3962

GregMiscellaneous: zerogs: Revert an accidental change to zerogs...
arcum42
Code::Blocks pulled up a zerogs header when I asked it to pull up the definition of a function in zzogl-pg. I caught it, but forgot to get rid of the changes I'd made...

Revision 3963

GregMiscellaneous: zzogl-pg: Get zzogl-pg working in Windows again.
arcum42
All the __forceinline's I commented out were giving unresolved external symbol errors in the linker otherwise...
arcum42
If we need them forceinlined, I believe putting the functions in a header, or in an inl file would also take care of the Windows linker issues.
Or we could use a define that only __forceinlines under Linux...
arcum42
If we need them forceinlined, I believe putting the functions in a header, or in an inl file would also take care of the Windows linker issues.
Or we could use a define that only __forceinlines under Linux...

Revision 3964

GregMiscellaneous: zzogl-pg:
* copy some vertex instead of re compute them twice
* pass vertex as reference avoid useless copy on the stack...

Revision 3965

GregMiscellaneous: zzogl-pg:
* Regoup drawing primitive in one function
* Increase the inital size of the vertex buffer
* various clean

Revision 3966

GregMiscellaneous: zzogl-pg: Remove the Gust hack from Mana Khemia. A few misc
changes.

Revision 3967

GregMiscellaneous: zzogl-pg:
* Improve a little sprite vertex processing

Revision 3968

GregMiscellaneous: zzogl-pg: Forget 1 line in previous commit ....

Revision 3969

GregMiscellaneous: zzogl-pg:
* Use an union to improve a little the copy of vertex
Zeydl...
Don't do this. Union field placement are NOT guaranted to be assumend. This code is no portable and in future could be unworked.
gregory....
Ak ok. I did not know
tool...
Actually, dealing with cross-platform development, unions are in fact very portable, and will never cause any issues unless they data sizes are miss-matched, which they are not in this case. (s16 is 16-bit, and u32 is 32-bit on all architectures).
There will be no alignment issues, as this is the nature of unions.
gregory....
The issue is placement order. No guarantee that 1 is before 2 that will take a tragic turn on the gpu.
tool...
That is true, however if you use it for simple record copy, such as xy = v.xy; v.xy = xy;, then there will be no issues with the gpu, unless of course, you derive xy from means other sources than v.xy, at which point you will need to ensure the ordering remains intact. This in itself is pretty simple however.
arcum42
Did you mean to remove 'f = v.f;' right below assigning x & y?
Jake.Stine
Agreed with toole; This is not an issue.
The field placement of unions is *only* undefined because of big/little endian machine differences. That is, the placement is defined and will always be in the order specified in the code. However, if you have this:
union {
struct {
u16 lo;
u16 hi;
};
u32 word;
};
... This is good for little endian machines but does not make sense on big endian machines, where lo and hi need to be swapped in order to make sense. No compiler will do such a swap implicitly for you, since the contents of the struct within the union is enforced by standard.
Jake.Stine
@gregory:
did you mean to delete this line, btw:
f = v.f;
tool...
@ jake, you are absolutely correct.
To be big-endian safe, you would need to wrap the variables such as this:
union {
struct {
#if BYTE_ORDER == BIG_ENDIAN
u16 hi;
u16 lo;
#else
u16 lo;
u16 hi;
#endif
};
u32 word;
};
arcum42
To be fair, big-endian vs. little-endian isn't a major concern when you are only targeting 32-bit x86 Linux & Windows...
tool...
Being Little-endian only helps quite a bit. ;)
gregory....
Ooups I delete the fog.
Anyway, I will remove the union and the operators overload. A plain C affectation is enough ;) (because it is a struct ? )
Jake.Stine
Yeah, any POD-style struct can be copied efficiently using the built-in operator=.
sunnydra...
too bad.. unions are great to store and read bit specific data in sane format(used this to read/setup vesa bios).
runtime can detect memory/register order and shift data structs(order) to provide unified access to host arch/ps2 specific data(even reorder to direct execution).

Revision 3970

GregMiscellaneous: zzogl-pg: * Revert previous commit and remove the =
overloading

Revision 3971

GregMiscellaneous: zzogl-pg:
* Use addvertex in register (stole from the new register code).
* Use primNext at the end of KickVertex function allow to use current index in
draw primitive.
* Create a primPrev
gregory....
Actually, it is a preliminary work of futur improvement. I just wanted to do some baby step.
The 2 global ideas are
1/ Use a gsvertex array that have a size of 2^n. It will replace the modulo in primNext/primPrev by a basic 'and' instructions. However I need to save base of tri_fan into an additional gsvertex variable.
2/ Allow reuse of previous vertex in (strip and fan). So the Set_Vertex function will be called only for new vertex.
Zeydl...
First of all, do you understand, that gsvertex is cycle array? In triangles we use 0, 1 and 2 elements of it, but it's really gs.primIndex+1, gs.primIndex+2 and gs.primIndex+3 (by modulo 3) -- those vertexes was sent one by one (in Fan mode we don't rewrite first vertex of fan). This code is hackish, of course, but seems to be highly effective. If you save those start vertex, than you could not use 0, 1 and 2 and should always count those last and last - 1 vertex indexes? But usage of previous vertex is nice idea, it usefull.
gregory....
Yes, that why I'm not totaly sure the gains will be big. The modulo is expensive (7 operations including 1 mult)
6c6: ba ab aa aa aa mov $0xaaaaaaab,%edx
6cb: 83 c1 01 add $0x1,%ecx
6ce: 89 c8 mov %ecx,%eax
6d0: f7 e2 mul %edx
6d2: d1 ea shr %edx
6d4: 8d 04 52 lea (%edx,%edx,2),%eax
6d7: 29 c1 sub %eax,%ecx
Vs a size of 4
68d: 83 c0 01 add $0x1,%eax
690: 83 e0 03 and $0x3,%eax
In worst case triangle: you need to do 4 more operations but we improve the primNext after every kick.
In others primitive: there is a really win.
Anyway for the moment I have a strange issue: adding "Vertex gsTriFanVertex;" is the gs structure declaration cause the code to break (actually only if I put before prac variable...)
gregory....
Hum, seem I just broke the savestate :)
Jake.Stine
Yes, avoiding modulo is almost always good. Unless you're using both results, ala:
int var1 = val / val;
int var2 = val % val;
... then there's usually no avoiding the modulo anyway, and both operations are essentially a single div instruction. But otherwise, just about any dancing around to avoid the modulo will end up being a performance win.

Revision 3972

10001 updates to the GameIndex file. Thanks to konajona, pgert and Lana :)
prison_b...
hey there pcsx2 team
i just wanted to say that i absolutely adnire your work on this great emulator and that you guys are doing a great job
now i know i posted this some time ago but i would really like (if possible) for you guys to look into this bug on the camera of fatal frame 1
i posted a video in case you guys are interested:
http://www.youtube.com/watch?v=JLu5o7QCMPE
thanks in advance :)
ramapcsx2
If you check our forums you'll see that this bug is long known and verified.
We know what it is and we've stated several times that it takes additions
to GSdx that aren't done yet.
We will fix it some day, just not now.
In the mean time use software rendering. That'll fix the problem.
pcsx2gu...
wtonberrios: Seriously STOP giving +1 to every single revision. You are not helping anyone and still giving +1 to broken revisions which only makes it harder for us to find them.
DB updates always welcome! :)
prison_b...
@ramapcsx2 oh so it was a GSdx hardware bug...
Never thought of that lol
Thanks for the help ;)

Revision 3973

GregMiscellaneous: zzogl-pg:
* use a size of 4 for the gsvertex array (allow compiler to optimize a % into an
and)
* Reuse previous computed vertex for _strip & _fan primitives
gregory....
Forgot to say: previous save state will be imcompatible due to the gsinternal structure modification

Revision 3974

* ( Issue 734 ) Configuring plugins from the First Time Wizard should work better
now (plugins options changes wouldn't stick)
* Security fix for Windows: Forced plugin filenames to be absolute paths, which
resolves issues with windows' default path search order for DLLs, and hopefully
avoids some errors for users who have installed Microsoft's Improved DLL
Security patch.

Revision 3975

newHostVM branch: Implemented VM reservation feature for all recompilers.
* SuperVU note: SuperVU recompiler now uses two separate 8mb caches for VU0 and
VU1 (needed in order to simplify/saneify the reserve/alloc stages of pcsx2 app
startup).
* Added MemsetFast.inl, which houses SSE intrinsic versions of memset and
memzero, for use on aligned data targets.

Revision 3976

newHostVM: Working on linux side now ... (WIP)

Revision 3977

newHostVM: Fix linux/gcc compilation errors. PCSX2 doesn't work yet tho --
crashes on startup and I don't have a proper debug environment setup to trace
and troubleshoot it.

Revision 3978

newHostVM: Fix linux/gcc crash on startup.
arcum42
Finding this was made a bit more difficult because the backtrace was a nearly endless string of calls to line 209 of Exceptions.cpp. ^_^
Jake.Stine
Yay, thanks. Does the emu actually work now? :p
arcum42
It seems to work, but I haven't done more then start up a few minutes of Atelier Iris 1. Seemed rather slow, but it was a full debug build. I'll test it with a more normal build later.
Oh, and the Database Editor menu item opens the Memory Card Manager, btw...
Jake.Stine
yea database editor hasn't been reimplemented yet. I need to fix it up so that the UI is easier to use, and isn't so prone to misrepresenting the selected item and modifying the wrong stuff unintentionally.
arcum42
All right, while a scene seems slower then I remember, it is outside of this branch, too, so it isn't an issue here.
And I can see what you mean on the database editor; I just thought it was odd that it opened the memcard manager...
arcum42
Incidentally, in case you're curious, the slowdown seems to have been a video driver issue. I accidentally updated my videocard drivers on my system without updating the videocard drivers in the chroot. :(

Revision 3979

newHostVM: improving error handling and memory management (WIP)

Revision 3980

newHostVM: More error/exception handling WIP stuff.
romulux_...
Ok, I have to ask, where exactly are you going with this newVM ?
Is it meant as a speedup, or ... ?
kaboo...
look at r3956 and check if that answers your question at least partly

Revision 3981

disc image support bugfix for games that have non-conforming SYSTEM.CNF contents
(invalid or missing ISO filesystem version numbers, typically specified as ';1'
after the filename).
kaboo...
and yuyu hakushou works again thank you very much

Revision 3982

Hackfix the Mana Khemia 1 "off campus" problem.
No one is sure yet how it actually works on the real console though.
gregory....
I have a segmentation fault in the ee recompiler with Mana khemia 1. The segfault seems to be trigger when I'm in the "off campus" zone. It appears within 5-30 minutes.
At the address (0x200018b3) it try to execute the folowing store instruction:
movlps %xmm0,(%ecx) (linux format).
But ($ecx) is 0x00081fec (out of memory).
No guarantee for the following:
Previous instruction seems to be a load
0x200018b0: movlps (%edx),%xmm0
With (%edx):
0x9c70870 <cpuRegs+496>: 0x00081fec
Look like it is the ra register content.
Except trying to found a bad svn revision and check my compilation flags :p, I do not know what I can do to help !
gregory....
Note: it is the pal version.
gregory....
Hum, using the workshop cauldron to do synthesis result in an easy triggered crash, but not same as previous. It is slow but it work with the ee interpreter.
gregory....
Ok I found the culprit. It was only the crappy ATI graphics drivers. I update it and solve 99.9% of the crash.

Revision 3983

GregMiscellaneous: sync with trunk (3805:3982)

Revision 3984

GregMiscellaneous: zzogl-pg:
* For 24 bits texture: there is some spare room in gsmemory so do not bother to
avoid overflow in the copy
* Port some swizzle function to sse2. It would avoid some copy in a temporary
buffer
arcum42
Something in this revision isn't quite right; take a look at the opening of Mana Khemia...
arcum42
Though what this does to the opening video in Kingdom Hearts 1 is interesting.
gregory....
Arg, I need to double check this. I test various place but not the opening of mana khemia...

Revision 3985

GregMiscellaneous: zzogl-pg: A few minor changes.

Revision 3986

GregMiscellaneous: zzogl-pg: Consolidate the context-specific Registry code, as
was already done in NewRegs.
gregory....
Just for information, I made some change in regs (related to zzkick) that I do not yet backported to newregs it is only impact prim register.
Actually I do not know if new regs is in a good state !
arcum42
I probably broke it recently, actually, but haven't got around to fixing it.
I've been planning for a while to copy over from NewRegs all the changes I was relatively sure didn't have any issues, but haven't gotten to it for the most part...

Revision 3987

GregMiscellaneous: zzogl-pg:
* Mem swizzle: fix mask scrambling & bad copy paste

Revision 3988

GregMiscellaneous: zzogl-pg:
* Backport prim change from regs to newregs

Revision 3989

GregMiscellaneous: zzogl-pg:
* Fix a regression of my commit r3965 (missing draw in god of war)

Revision 3990

GregMiscellaneous: zzogl-pg:
* Improve a little previous commit
* Remove a fixme that was fix long time ago

Revision 3991

newHostVM:
* Moved profiler management to the RecompiledCodeReserve class.
* Improved error handling some more.
* Numerous minor cleanups.

Revision 3992

newHostVM:
* Preliminary implementation for the SpatialArrayReserve class, which will be
used for recompiler lookup tables (large portions of these tables are never used
by many games). Will put it to use and test it soon.
* Finished implementation of TryResize method for reservations, which will be
used by PCSX2 if the operating system runs low on ram.

Revision 3993

Plugins (MSW only): Removed the Image Randomization flag from most plugins'
projects. They now default to the value specified by the PCSX2 properties
sheet, which enables image randomization by default.
Technical details: Image randomization is a feature on Vista/7 that loads DLLs
at random(-ish) addresses, improving security and reducing the amount of DLL
relocation work required. This option has no effect on WinXP.

Revision 3994

newHostVM: More exception / error handling mess.

Revision 3995

newHostVM: Sync with trunk (r3972-r3993)
rudhy.ma...
excelent

Revision 3996

Edited wiki page Todo through web user interface.

Revision 3997

Edited wiki page Todo through web user interface.
frost....
Who will write revision 4000 ? :D
kaboo...
who cares it's not a beautycontest
romulux_...
Bositman (pcx2guide) again maybe like r3000 :))
But seriously my money is on Jake for that one.
jfre1...
Mines on arcum with something on the linux port side of things

Revision 3998

newHostVM: Linux compilation fixes.
Jake.Stine
Thanks
arcum42
np. I figured I'd occasionally test this branch, and make sure Linux keeps working...

Revision 3999

GregMiscellaneous: zzogl-pg: Move the time functions over to be by the Profile
code.