PCSX2 Documentation/Google Code svn repository comments archive 1500 to 1999

Revision 1500

Shit I'm commit-spamming again. >_<

Fixed a "omgf"-class bug, which just happened to work while using ISOs because

of a shared variable which wasn't meant to be shared.

And more cleanups.

keb...

i'm spamming in the rev 1500 which happens to be spam? how ironic

kaboo...

no ironic would be if giga's commit note was about spamming and that nobody should ever do something as cruel as such and there you spamm that would be ironic...

keb...

i win then :P

i'm joking please don't ban me :c

Seinfeld...

ironic would be getting a warning with spam bacause of spamming

kaboo...

no that's called "Cause and Action" ^^

kgwillia...

Irony is the outcome of an event being opposite to and in satire of the expected outcome.

refraction

The irony is nobody seems to know the true meaning of irony, but keep using it :P

kaboo...

true Oo

keb...

refraction said it all, or did he?

B]

Revision 1501

Fixed the crashing with blockdumps. It was the "iso file format" lib I took from

cdvdiso.

So I axed the compressed iso (Z/BZ2) format reading, as part of fixing it.

Anyone needing it can still use CDVDiso.

gigaherz

Forgot to say, blockdump setting is actually saved. just wasnt' showing up in the menu after displaying the window!

valles...

Good call. Anything else than LZO is stupid anyways because it easily makes the cpu the bottleneck for little gain in compression.

Revision 1502

Bugfixed thread affinity restoration during CpuSpeed detection; pcsx2 should use

all your cores properly again. :)

kaboo...

sounds like pcsx2 should have been a bit slower on previous revs... Oo *testing*

kaboo...

compiling this rev makes VC++ 2008 say

"4>Projekt : error PRJ0002 : Fehler "31" wurde von "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe" zurückgegeben.

"

Jake.Stine

That's the manifest generator, and the error means it's probably crashing due to some corrupted database or object file information. A full rebuild should resolve it.

gabest11

... or there is something that reads the exe as soon as it is linked but before the manifest file is appended, it happens to me a lot when aqtime reloads the profiled module.

RebelliousX

Just wondering, anybody was able to profile PCSX2 (Release build) under

AQtime?? I only succeeded profiling it with the debug build with all

recompilers off -_-

zantezuken

Jake:

Properly do you say:

http://img139.imageshack.us/my.php?image=1coreload.png

:(((

Supe...

Can't get it, still one core kept going 100% while running BIOS on pcsx2-r1550.

Revision 1503

Fixed Linux again. Still don't have time to actually implement adding the new

features yet in Linux. (Likely won't till next week or later)

Revision 1504

Minor code conformity cleanups and svn properties settings for new cdvd code.

Jake.Stine

on the wx side of things I'll remove all the win32 specific code and end up converting most or all of the filename code to wxString, wxFileName, and wx's built in directory contents enumerators.

Revision 1505

wxgui: Added plugin selection dialog (complete with plugin enumeration and an

exceedingly fancy progress bar), fixed some menus, added isofile recent lists,

and lots more stuff is correctly saved and loaded from the configuration file.

* Dev note: Re-enabled USE_STL in wxWidgets since that's required to ensure

thread safety.

Jake.Stine

Beh, just noticed I accidentally added Linux/HostGui.cpp, which isn't needed. I'll remove it later on my next commit, whenever that is. ;)

Jake.Stine

Further info, since this branch is very nearly to the point where it'll be usable:

The Settings dialog box is now correctly bound to the Config->Settings menu. Go to the Plugins panel to see some fanciness. The branch should build and run fine under Windows and in Debug build target. Linux is broken at the moment, and I haven't tested devel or release targets lately.

Jake.Stine

Ok, just tested Devel targets, works fine here. Yay. I'll probably re-fix linux tomorrow. I'm sure GCC hates no less than 27.3% of my new code. >_<

pcsx2gu...

Great job Jake :) I don't think people realize how much work this is or how much better it is from the older GUI but we do! I'll test it asap keep it up ;)

refraction

I dont yet :( been too lazy to try it :P definately looking forward to it though!

ramapcsx2

Few crashes here and there, and it seems to hate enumerating zerogs.

Else its looking very nice already :)

nokiaqdman

This is great work! I like it way more than older one.

kaboo...

wow looking marvelous already!!!

seriously good job and the "run" menu is perfect^^

feels comfy cozy already XD

Revision 1506

Linux: Implemented the gui side of the new built in ISO loading functions in

Linux.

Revision 1507

wxgui: fixed up linux size (and omg it was easy for once!)

ntcong.it

Hey, isn't it the power of wxW ? :D

Revision 1508

Switched from vs2008 to NSIS for creating the installer.

Not final version, but putting it here as backup

Instructions in the txt

azte...

congratulations for changing to nsis krakatos, surely you are going to use lzma with solid compression? :)

kraka...

Since the file is fast to compile, and there is the option to do that automatically, for every setup we're going with the one that takes the least amount of space. Bandwidth is precious after all

But yes, it's LZMA solid for now XD. And looks like it will be for the foreseeable future

azte...

[quote]Bandwidth is precious after all

But yes, it's LZMA solid for now XD. And looks like it will be for the foreseeable future[/quote]

for me bandwith is really precious, i'm on 56 kbps here.

good you are going to use lzma with solid, really nice. Thanks for the answer.

kraka...

I think I need to clarify. Each time, I'm going to try all the compression methods and choose the one which gives me the smaller installer.

That way, we'll always have the smallest possible installer

azte...

oh, good idea, i understand now, thanks for the info. :)

Revision 1509

Made the EE recompiler 64-bit constant buffer (was called a "stack" despite not

being used as one) reuse recent constants rather than duplicating for every

instance, resulting in less recompiler resets (e.g. espgaluda resetting every

couple of seconds).

240...

This revision makes character in God Hand (NTSC) flicker every second (Gene keeps appear & disappear).

I guess it has nothing to do with Gdsx, also the previous revision ran perfectly fine with same game.

Please can you have a look

My specs:

T9300 2.6Ghz

4GB RAM

9800 GTX - 1GB

Vista Home 32 bit

ramapcsx2

Are you sure it is this revision? Would be very strange if it was.

240...

I am sure because I follow all pcsx2 revisions.

Since this revision, character in God Hand keeps flickering, the previous revision I tried was r1504 and it does not have the problem! Correct me if I am wrong, but r1506, r1507, r1508 only affect GUIs, so r1509 must cause the issue.

I also tried with/without Speed Hacks, Native Solution. The issue still persists

I am running in DX10 Hardware btw

sudonim1

Confirmed, investigating the bug.

Revision 1510

Remove some messages from release builds, switch some remaining printf to

Console::Status and remove a layer of bloat when checking if an iso image is

double-layer.

Revision 1511

Start improving the CDVD interface. Change the internal ISO interface to use it.

I will later work on getting the typical plugins to support these new functions.

I have tried to also update the linux side, but I can't compile or test it so it

might not work properly.

Revision 1512

Tiny "Whoops".

Revision 1513

Now that having internal CDVD interfaces is easy, I added a NODISC interface,

with a menu option to run the BIOS with no disc.

heatbla...

I wonder if there will be any good for PCSX2 to go x64.... However good news here :")

jfre1...

Been done b4. No good came of it.

Revision 1514

Some fixes and cleanups. Now the File->Run* options won't reset the emulation,

so it might be possible to swap discs properly from nodisc, iso or whatever cdvd

plugin has been selected (to switch between iso/cdvdplugin/nodisc, it's

necessary to use the file menu options, as run->execute will not update the

active cdvd interface).

jfre1...

Why not have a "Eject CD/DVD" function from the file menu in the same way that psx (the ps1 emulator) does it? And have cd/dvd changing done via that method. Just an idea.

refraction

Eject should be in the cdvd plugin rather than the emulator itself, else things could get quite confusing and the emulator may not be able to remount the dvd if you swap.

heatbla...

@refraction: good point :")

Revision 1515

Debug message slipped in.

Revision 1516

Linux: Added the new menu options, and cdvd/bios running doesn't reset the

emulator on Linux, either.

Revision 1517

SPU2-X: Just the version update

Revision 1518

Fixed broken blockdumping in last change.

Added the possibility for plugins supporting getBuffer2 to return -2, meaning

"still busy".

Revision 1519

Whoops.

Revision 1520

Cleaned up Disk Type detection code, when workign with CDs, which in turn fixes

CD-based games booting (as far as I can tell).

gigaherz

Eh message should say "Cleaned up Disk Type detection code, and fixed detection of CDs" or something like that :P

Revision 1521

SPU2-X: Tagged public release v1.2

ltrap...

Am I wrong or SPU-X uses intrinsic memcpy routines instead of optimized ones? And if so why not to use optimized ones?

Revision 1522

Just a tiny cleanup, nothing interesting.

Revision 1523

Tweak for recompiler resets, helps a bit against the stalls when those happen.

Revision 1524

Cleaner version of the EE reset optimisation, there's no particular reason not

to skip these steps every time so there's no need for a second function.

Revision 1525

Give more information about the active disk even in Release builds.

Remove unnecessary re-checks at startup, so the cdvd info only shows up once

(and every time the plugin notifies of a disk change).

Add a condition to print which shouldn't be printing always.

Add a little "hack" to Mechacon command 0x80 ... will get rid of it later if it

doesn't help.

Revision 1526

Plugin interface / GSdx changes that binds the GSdx vsync option to the pcsx2

framelimiter.

This patch by matsuri makes playing with vsync a lot nicer, so thanks for that

one ;)

Note: For now its directx 10 only, due to dx9 needing a swapchain reset..

Autor...

Very Nice, DX10 vsync always was buggy and could limit games itself incorect

kaboo...

yeah in wild arms 3 every time for me -.-

really nice

zantezuken

Yep, now it works much better.

Revision 1527

Silence a stupid compiler warning, fix the layer1 detection code, and remove the

hack I added before, as it does no good.

karlheinzgraf74

Loading via CDVD Plugin does not work anymore on Vista x64. Last working version ist r1503 :-(

gigaherz

I code in Vista x64 and it works just fine here... which plugin do you use?

gigaherz

Also, please don't rate down a revision for something which it did NOT break. If 1504 broke it, then rate 1504 down, not this one!

Jake.Stine

I doubt 1504 broke it anyway, since it has no functional code changes. He probably hasn't tested every revision.

karlheinzgraf74

[Plugins]

GS=gsdx-sse4.dll

SPU2=spu2-x.dll

CDVD=cdvdolio.dll

PAD1=lilypad.dll

PAD2=lilypad.dll

DEV9=dev9null.dll

USB=usbnull.dll

FW=fwnull.dll

no, I have not testet all revisions but it isn't working anymore in:

Pcsx2-r1513

Pcsx2-r1517

Pcsx2-r1526

Pcsx2-r1527

sorry, but I could not test r1504-r1512

I tried Shadow of the Colossus and God of War 2.

karlheinzgraf74

i tried a plain new configured pcsx2-r1528 and cdvdiso.dll and various other plugins, but no success! No iso-file is loading. :-(

karlheinzgraf74

it locks here:

<...>

DvdRead: Reading Sector 263(8 Blocks of Size 2064) at Speed=4x

DvdRead: Reading Sector 809(2 Blocks of Size 2064) at Speed=4x

<lock>

in Release 1503 it continues as follows:

<...>

DvdRead: Reading Sector 263(8 Blocks of Size 2064) at Speed=4x

DvdRead: Reading Sector 809(2 Blocks of Size 2064) at Speed=4x

PAL Display Mode Initialized.

Framelimiter rate updated (UpdateVSyncRate): 50.0 fps

DvdRead: Reading Sector 811(1 Blocks of Size 2064) at Speed=4x

<...>

Revision 1528

Matsuri sent me a cleanup of his previous patch. No changes in functionality.

Jake.Stine

bool is not allowed in PS2Edefs.h. It's not compatible with extern "C", and thus cannot be compiled by non-C++ plugins. We'll need to revert back to int (but the rest of the code cleanus can stay, since bool<->int implicit conversions will be sufficient)

gigaherz

Oh... well not hard to undo :P

Revision 1529

wxgui: Fixed crash-on-exit problem in Release builds and made the console logger

thread-safe (uses messages instead of direct wxFrame method invocations).

ramapcsx2

Congrats.

Revision 1530

wxgui: minor code cleanups.

Revision 1531

Remove the bool from the GS exports, as Jake said.

matsur...

Didn't know we have to support C plugins, so I didn't take that into consideration.

Well done.

ltrap...

I fixed the code for allowing users to resize initial windowed mode window via gsdx.ini file (for the custom sizes) or via the settings dialog. It also doubles as more comfortable way to switch between fullscreen and windowed mode. I think it'll be better to separate refresh rate setting from resolution but it takes much more effort to do so. Though it looks nicer with checkboxed window mode:

http://pic.ipicture.ru/uploads/090716/hbC30JHnOA.jpg

Here is the changes:

http://rapidshare.de/files/47865437/GSdx_diff.zip.html

PS: GSdx.rc file is now 9 999 bytes )))

ltrap...

There is no default selection in resolutions list in that code but it can be easily added.

For example 800x600 as default (I beleive most systems support it):

GPUSettingsDlg.cpp / GSSettingsDlg.cpp

if(CComPtr<IDirect3D9> d3d = Direct3DCreate9(D3D_SDK_VERSION))

{

uint32 w = theApp.GetConfig("ModeWidth", 800);

uint32 h = theApp.GetConfig("ModeHeight", 600);

uint32 hz = theApp.GetConfig("ModeRefreshRate", 60);

ramapcsx2

ltrapper:

Maybe open a new issue, its better for sharing patches and stuff ;)

ltrap...

Is it OK to use issues for this? If so I'll move there. ^_^

gabest11

How does the user know which combination of width x height x refresh rate are valid?

gabest11

... and setting the window size isn't really good, since it includes the non-client area, still not the selected resultion, as before.

ltrap...

>How does the user know which combination of width x height x refresh rate are valid?

If user going to manually edit configuration files he is certainly must know what he is doing, doesn't he?

And about setting the window size - I don't implied that it's precise setting. It's just a base idea for keeping same window size between program sessions. If you know the better realization I'll be only happy.

gabest11

Yes, the ini can be edited even now, but that does not mean it should be.

DirectX enumerates the exact modes it supports, it's not something freely editable.

For 800x600, it might be avaliable today, but not tomorrow, and many lcdtv's are very picky, there are only a few modes they can display.

If you really want to set exact window size, there are system config calls that can query the caption and border size, it's annoying to calculate precisely but not impossible.

ltrap...

It can be edited but it's totally useless - in windowed mode (all the time I have talked about it) it doesn't really counts.

As for fullscreen mode I agree - it's not something that users must meddle with. But so I didn't change the configuration dialog that's why most users don't see any differences.

ltrap...

BTW 800x600 is just for setting selected item in the list it doesn't change current resolution if there are no selection. ;)

Jake.Stine

>> If you really want to set exact window size, there are system config calls that can query the caption and border size, it's annoying to calculate precisely but not impossible.

... or you can just use Windows' built in API for converting a client window size into a framed window size (you give it a client window size + the GetWindowLong() of the window's flags, and it returns the calculated size). I forget the name offhand. I can look it up.

gabest11

AdjustWindowRect, found it

ltrap...

BTW I had already opened issue for this so if you don't mind let's continue discussion on the topic there:

https://code.google.com/p/pcsx2/issues/detail?id=316

Revision 1532

wxgui [Linux]: Updated project files, fixed docking logic.

Jake.Stine

Oops forgot about all my docking logs. Ah well, guess now's a good time to benchmark console performance anyway. :)

Revision 1533

Fix flickering characters in god hand from r1509.

ramapcsx2

Odd. What happened here? :p

Jake.Stine

EErec const/liveness bug. The _eeGetConstReg() function has additional optimization logic that fails on these particular instructions, likely because of malformed settings in the incomprehensible BSCpropagate table.

ramapcsx2

You make it sound as if you didn't like the awesome eeRec! (lol)

Revision 1534

GSdx: just squeezing a few more fps.

ltrap...

It seems previous bug with incorrect display of numbers in Persona 3 FES is no more. *happy*

But the one I had failed to mention earlier - graphical garbage in some scenes is still here:

http://img154.imageshack.us/img154/7429/example3.jpg

Maybe it's possible to fix too?

And thanks again for you hard work!

gabest11

I only ever reached the first fight, but that was normal.

Please make a .gs.

ltrap...

It looks like part of a game - trying to press Shift+F8 in margin of half of second from dynamic scene. ^_____^

ltrap...

OK here is the result of completing quest for the one garbage bug:

http://rapidshare.com/files/256951548/gsdx_20090717234755.rar.html

ltrap...

And one more result in a different fight:

http://rapidshare.de/files/47877784/gsdx_20090717235644.rar.html

gabest11

Did you have any speed hacks on?

Strange but in two frames it cannot finish drawing the scene, only the characters are there.

ltrap...

2x cycle rate. EE is all. VU is except max/min. VU cycle stealing is on "moderate speedup".

ltrap...

It seems without the cycle stealing and status flag hack the problem still persist but become apparent on much rarer occasions.

Jake.Stine

Yeah that looks like VIF texture corruption to me. Most likely not the fault of gsdx.

ltrap...

Maybe, but this corruption was not seen in build 1384 for example so I thought that it might be related to gsdx.

And to next part - I have found one more strangeness. It looks like pale white lines grid in some scenes: http://img132.imageshack.us/img132/5895/gsdx20090718042123.jpg

refraction

Looks more like post processing issues to me, how does it look with gsdx in software mode?

The only thing it could be (which Persona uses) is Path3 masking, most likely the same change which caused problems with one of the Star Wars games. Probably going to remove that anyways.

gabest11

nah, persona games are nice, no evil frame buffer tricks, it's just that with some settings vsync arrives more often than it should.

gabest11

the other glitch, the thin lines, are probably the result of upscaling.

Revision 1535

wxgui: Optimizations and improvements to the console logger's threading model.

Revision 1536

wxgui: various cleanups.

Revision 1537

wxgui: Whee, a basic file browser dialog for Run Iso. Eventually it *will* do

something more than log the result. >_<

Revision 1538

GSdx: added ltrapper's modifications.

animus...

I don't know when did it happens but F5 doesn't work anymore.

gabest11

Are you using an older pcsx2 build?

animus...

Ooops! So that was the reason...Tnanks

By the way in Xenosaga III loading sreen is broken in hardware like this:

http://img154.imageshack.us/i/nativeb.jpg/

http://img169.imageshack.us/i/1024x768.jpg/

It happend somewhere after 1376

ltrap...

So the changes are finally made it to the build. In spite of a bit misaligned controls in dialog box (look in issue 316 thread) it makes me happy. It was really annoying to manually resize the window each time.

Seinfeld...

very positive, just hope garbage in the upper left corner on FFX in the intro and the half bottom missing in hardware of Dropship can be fixed.

keb...

yeah FFX has a very similar garbage in the intro when tidus starts climbing the rocks when the camera changes (top edge of the screen), maybe it's related, the problem exists for some weeks now, i actually thought it was related with the emu itself since there are already a lot of graphical problems in FFX because of it

Seinfeld...

the FFX problem started at r1439, r1426 is fine.

venom4...

hey gabest, i noticed that with r1479 (dx10) the messed up shadows in Ico are removed but with newer revisions they are present...would it be possible to do the same with shadow of the colossus and remove the glitchy shadows completely? i believe ico and sotc use the same game engine and they both have the glitchy shadow problem...i tried r1479 (dx10) with sotc but the shadows are still there so whatever was changed seemed to only effect Ico...

Revision 1539

wxgui:

* Console now uses a fixed-width font by default

* Core PCSX2 memory structures (VTLB and Recompilers) are allocated on startup.

* Added some more gui/ini/startup mess.

darkvalen21

I would like to test the new GUI, what changes need to be done in the source?

nefer...

Just make a new checkout directory pointing to the URL of the branch, in this case http://pcsx2.googlecode.com/svn/branches/wxgui/

kaboo...

nice progress speed jake!!!

kaboo...

sry for the double post

will it be possible to change the theme of the gui?

Jake.Stine

The icons and backgrounds will be changeable via theme. The window frames are not.

Revision 1540

microVU: Work in progress stuff... (no functional change)

Autor...

Just interestig, what this WIP about? :p

gigaherz

First few lines from /trunk/pcsx2/x86/microVU_Alloc.inl:

//------------------------------------------------------------------

// Reg Alloc

//------------------------------------------------------------------

I think the comment makes it pretty clear.

Revision 1541

microVU: cleanup (removed old mmx vi reg caching)

Revision 1542

microVU: more work in progress stuff...

Revision 1543

PCSX2:

- Added *.MDF Disc Images to the "Run ISO" file browser.

I'm not entirely sure if theres any file system differences between .mdf and

.iso (couldn't find much info on it); but all my .mdf files are working as-is

with gigaherz's code, so I think compatibility should be fine.

- Moved "Run ISO" menu option above "Run BIOS" since users will run ISO's more

often than the bios xD

microVU:

- More work in progress stuff... hopefully I finish within the next few days.

azte...

congratulations on this change cottonvibes, since ppl use formats like .mdf, .bin or .ccd more often than .iso usually this make it as a nice and indeed useful add-on. :)

guessous...

There was an opensource project mdf2iso that allowed conversion of mdf to iso, so I guess they are not exactly the same thing.

micheles...

it could be similar to dolphin

ramapcsx2

Yay, regalloc :>

Hope it works out and doesn't clutter too much ;)

zantezuken

can't wait for new allor funcs in mvu :P

cubi...

Hi there,

you might want to have a look at libmirage (http://cdemu.sourceforge.net/pkg_libmirage.php) since it lets you access a lot of image formats. It's the central image access library for the cdemu optical disc emulator (something like the equivalent of dtools on linux).

ntcong.it

I'm just wondering if register allocation will make a posible huge speedup for mVU.

Autor...

Cotton, i'm interesting what should bring new mVU changes?

gigaherz

Comment by ntcong.it, Today (18 minutes ago)

I'm just wondering if register allocation will make a posible huge speedup for mVU.

Speedup IS RegAlloc's only reason for existing. Huge or small is what we don't know yet.

gigaherz

Hi there,

you might want to have a look at libmirage (http://cdemu.sourceforge.net/pkg_libmirage.php) since it lets you access a lot of image formats. It's the central image access library for the cdemu optical disc emulator (something like the equivalent of dtools on linux).

I have been looking a bit through the libMirage docs. It doesn't look too complicated to use but, it kinda annoys me that it requires GLib to compile. I dont' know if libMirage and GLib would bot compile fine under VisualC++ 2008, and I would rather avoid adding another external library to the project.

I wouldn't blame anyone if they decide to use it, but I think this kind of implementation should be left out of the core project and, if anyone really wants it, implemented into an external plugin.

gigaherz

Hm forgot to separate what's quote from wht's my text ... oh well too late for it XD

guessous...

@gigaherz

well I don't know what advantage there's in using the new built in option "Run Iso" instead of an external plugin first.

Anyway, both seems to work fine for me.

cottonvibes

about the mVU changes:

Been working on implementing some smart regalloc into mVU.

regalloc (register allocation) is basically an idea to keep values in registers as long as possible, to eliminate writes/reads from memory (which is slower).

I have no idea if this will be a speedup or not. But I was planning to rewrite my upper opcodes in a neater format anyways, and since i was going to do that, then i decided i might as well implement regalloc while i'm at it =D

Revision 1544

wxgui: Added more functionality to configuration dialogs and more options are

saved to ini.

sunnydra...

eager to see this in main trunk soon:)

coolraju...

Its all coming together.Looking forward to see it complete.

Revision 1545

microVU: more W.I.P. regAlloc stuff (upper opcodes are using my regAlloc class

but are set to flush every opcode so speedwise this commit should be slower (or

the same as before)

Once I rewrite my lower opcodes to use regAlloc, I can remove all the flushes.

Revision 1546

microVU:

- Fixed Micro Program Logging (broke it on my last commit)

- More regAlloc work

- Big Cleanup, deleted about a thousand lines of obsolete code.

cubi...

Always good to see improvement on microVU.

I have a general question concerning the different processing units. As far as I know the PS2 has 5 PUs: the R5900, the 2 VUs, the GS and the IOP / R3000.

Which is the PU that does the "most work"?

I'm asking because the microVU rewrite of the VU recompiler implicates that current emulation is suboptimal. Also does Jake work on the R3000air recompiler. I wonder because the R3000 / IOP seems to be the slowest PU inside the PS2, so why bothering rewriting the recompiler for that component?

Jake.Stine

VU recompiler rewrite was more for maintainability and compatibility than for speed. The old SuperVU was pretty efficient on whole, but had a handful of fundamental compatibility issues that were going to be neigh impossible to fix within the context of the way the recompiler was written. It also left no room for potentially threading the system.

The R3000a is for most intents a purposes a simpler version of the R5900. Most of the core instructions are implemented similarly (with the exception of the R5900 having 64-bit sign extension on all the 32-bit instructions). The goal is to be able to re-use the first-pass interpreter and bulk of the regalloc code being written for the R3000a for a rewrite of the R5900. Also, while the R3000 is the least intensive of the PS2 cpus it also has by far the least efficient implementation, so there should still be an easily noticeable improvement in speed once the new R3000a recompiler is finished.

(Having two branches to maintain is killing me tho,s o I'm trying desperately to get wxgui working so I can get myself down to one branch)

cubi...

Thanks Jake!

I see, so microVU is basically a rewrite because of superVU's design flaws that can't be easily fixed (without major hacks). Do I understand it correctly that current VU impl doesn't support any threading?

I know that the GS impl support multi-core systems and I was assuming that for multi-core systems the two VU recompiler could be mapped to different cores. Is this even true? Or is there some kind of sync issue between the two VUs which makes it impossible (in the current state) to run them on different cores?

Also, does that mean that with microVU it will be possible to utilize >=dual-core systems properly? (e.g. each VU recompiler spawning two threads, so each core of a quad-core system has work to do).

Anyway, I'm really looking forward to the wxgui since I'm primary a linux user. :)

Currently using pcsx2 on WinXP though since the OpenGL plugin (ZZogl) is a lot slower than GSdx. Plus ATI's fglrx driver on linux isn't on a par with the Windows driver. I'd very much like to see Zeydlitz and zerofrog join forces once zero returns (I think he's pretty much inactive at the moment).

Jake.Stine

Threading the VUs is tricky because of sync issues with the R5900 and DMAC components of the EEcore. There are a handful of hardware registers which are shared between the devices that need locks or copies to protect them from corruption. There are also other sync points and branch conditionals that need to react appropriately based on the state of the VU1 microprogram execution status. I did some preliminary experimentation and got the VU1 running *mostly* threaded, but not yet stable (most games ran, but with severe geometic errors).

Ultimately the benefits of threaded vU1 will be minimal for most games. Only games that make heavy use of the VU1 will really benefit -- but those are currently some of the slower games to emulate, so it should be worthwhile.

shagkon

>Only games that make heavy use of the VU1 will really benefit

Could you please name a few?

Revision 1547

microVU:

- More regalloc work/fixes

- Implemented some untested SSE4.1 optimizations (can't test since don't have

sse4.1 cpu)

pcsx2:

- Added an SSE4 instruction to the legacy emitter (just a wrapper to the new

emitter function).

Note: Currently tri-ace fix and logical min-max code (thing that mad DaZ safe to

use) is broken with mVU. Will fix later.

heatbla...

Great job! Looking forward to SSE4 and 4.1 improvements

Makotech...

WOuld like to add that KH and Kh2 are buggy with mvu

KH1 has SPS

KH2 has weird slowdowns caused by random things, like equipping too many abilities or items.

Completely fixed by disabling mvu.

refraction

Makotech: can you find out where it was broken (im sure it worked at some point) and submit an issue.

pavlovm...

Excuse my curiosity, but what the difference between opCase3 & opCase4 ?

source /trunk/pcsx2/x86/microVU_Upper.inl

opCase3 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }

opCase4 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }

Revision 1548

Did a bit of cleanup on the new iso code, mainly so we're using the Console

functions for messages.

arcum42

And, yes, I'm back from my vacation. Looks like no one broke Linux while I was gone, too, which is nice...

And that isoDetect code was bugging me with how repetitive it was, so I refactored it.

The filereading code bugs me a bit, too, with the Linux and Windows sections being totally different. I'll have to see if there's a crossplatform way to do it when I have more time available.

gabest11

Probably does not matter much with an iso, but readTrack and getBuffer are there to make readTrack non-blocking.

Does linux have anything similar to overlapped io of windows? It just fits here so nice as if it was designed to.

Jake.Stine

The current iso code implementation doesn't even enable asynchronous (overlapped) file access when it opens the stream, so the code is pretty much functionally equivalent to using the ANSI C file streams anyway. That is, you could #if 0 the win32 version and have both win32 and linux use the generic version and it'll work fine.

While I doubt overlapped i/o would be beneficial for reading isos (most read operations will be pulled from the internal cache management, and CDVD block sizes are a bit small for efficient overlapped io performance), the Win32 API does give a fine-tuning option on how data is cached for reads; either random access or sequential. Enabling sequential caching might be a small performance gain. Or maybe not. I've never experimented with it.

gabest11

It just worked well for reading dvds directly, for isos someone may mount them from his slow NAS (like me :P).

Revision 1549

GSdx:

- trying the dx10.1-only "gather" shader instruction for palletized lookups

("8-bit texture" mode), saves 4 instructions which isn't much but still... (not

tested, don't have ati)

- may fix the intel gma "no output" bug (don't have gma either :P)

- and the usual small code optimizations

gabest11

I'm not quite sure yet how gather works, it probably shifts the input coords by +/- 0.5, but that may depend on the sampler filter (will it still return 4 different texels when point sampling is set?)

Here is a bit modified build:

http://guliverkli.sf.net/GSdx-SSE2-w-gather.7z

And here is one without gather, for comparision:

http://guliverkli.sf.net/GSdx-SSE2-wo-gather.7z

refraction

"- trying the dx10.1-only "gather" shader instruction for palletized lookups

("8-bit texture" mode), saves 4 instructions which isn't much but still... (not

tested, don't have ati)"

shouldnt matter about ati, dx 10.1 should be available across the board, working on all existing dx10 hardware (including Nvidia) :)

me.thc...

dx10.1 is only available for recent ati cards, mobile 40nm nvidia parts and maybe a few integrated chips.

nvidia's desktop 40nm dx10.1 is only coming soon. Nvidia does have dx10 extensions, but that is a "different function".

I have a 4850... wonder how to test... time to compile...

chuuey

just tested this on my 4890, there's some weird texture pixelation occuring now..

refraction

my bad, stand corrected ;p

gabest11

chuuey: did you also test the two other build I linked in the first comment? do you see any difference in look or fps?

btw, this "gather" thingy and other 10.1 features will be all available in 11, they have to keep it backwards compatible, of course.

gabest11

oh and please upload screenshots of the errors :P

Ami.Mizu...

DX10.1 lol, suppose you will also be looking into DX11 support in future. :p

You're among the most curious developers I know to try out stuff, I mean SSE4.1, multicore software rendering, DX10, I'm suprised you haven't tried using CUDA yet. xD

chaotixx...

Tested with gather and without, windows 7 on a 4850 card in 1474 beta.

http://i27.tinypic.com/dmy4jo.jpg -with gather

http://i30.tinypic.com/9l92zo.jpg -without gather

It Doesnt seem to be all graphics, only certain text. Menus on GT are ok but in game text is pixelated and changing interlace doesnt help (screens are from same interlace setting). On Extinction only the language select is affected. Both games are PAL.

gabest11

Seems wrong :P

Can you see any diff between the svn build and GSdx-SSE2-w-gather.7z?

gabest11

I might just buy an ati for testing... Is the 4350 a good card?

chuuey

well i also tested with your build, same pixelation effect, but it's even worse ;) by the way, ffxi flickers from time to time when changing zones ;)

chuuey

for testing you'll just need any ATi card with 10.1 i guess ;) unless you need the extra performance ;)

gabest11

I could also use the reference rasterizer for free! :D

chuuey

your build with gather :

http://files.myopera.com/chuuey/albums/830695/gsdx_20090722135813.jpg

my compile:

http://files.myopera.com/chuuey/albums/830695/gsdx_20090722135954.jpg

both incorrect ;)

ramapcsx2

The 4350 has only 256mb of framebuffer afaik. It'll not represent actual common performance very well, but otherwise it should be good.

Maybe the 4830 is a better choice? ;)

ramapcsx2

Oh, this one might do as well:

http://www.newegg.com/Product/Product.aspx?Item=N82E16814102843

Jake.Stine

Yeah the ATIs are like the NVidias when it comes to how they number cards. The low end of the higher series is worse than the high end of the lower series. That is, a 3850 is probably better than the 4350 (in the same way the 7800 series nvidias are generally better than 8400 series). So if you want to get a 4000 series you really should look at 4600+.

chaotixx...

http://i26.tinypic.com/2rc5w0i.jpg -w gather build

http://i28.tinypic.com/28apc1v.jpg -1549 build

http://i29.tinypic.com/r86tq9.jpg -no gather build

On the language select screen only the background is animated so there is no in-game variation in the text aside from the build change. With 8bit textures disabled it looks the same as no gather build or older versions.

Revision 1550

More iso work. Timestamps work in Linux now (and use Paths.h). Worked on getting

rid of other redundant code, moving the logging to the standard pcsx2 log

functions, and misc cleanup.

gigaherz

1 line-by-line comment

/trunk/pcsx2/CDVD/CDVDaccess.cpp  

r1550  

line 270:

270: char fname[MAX_PATH], ext[g_MaxPath];

Missed a MAX_PATH here.

arcum42

Oops. Oh well, I've already rewritten that section, anyways. I just haven't had a chance to make sure it works in Windows. After adding a GetCurrentDirectory function to PathUtils, it looks like this:

if (CDVD.init == ISO.init)

{

// Base it out of the current directory for now.

string temp = Path::GetCurrentDirectory() + Path::GetFilenameWithoutExt(isoFileName);

strcpy(fname_only, temp.c_str());

}

else

{

strcpy(fname_only, "Untitled");

}

gabest11

ah MAX_PATH is evil, but ought to be enough for everyone :D

Revision 1551

GSdx: disabled "gather" until I can sort it out

Revision 1552

GSdx: ffxii fmv works again and even less bogus

animus...

Hello, Gabest. About Issue 184 . Software mode doesn't really help:

http://forums.pcsx2.net/attachment.php?aid=20016

david.zy...

This rev seems to solve the display problem for the intro fmv of FF XII PAL. But black flashes can be seen now during this same FMV. I'm not sure this is caused by this revision as with the previous ones, this FMV was not watchable before.

heatbla...

Hello, gabest11. Good job as usual. BTW I had to report that Steambot CHronicles crashes the emu with that version ot the plugin (DX9 and DX10) mode.

Revision 1553

GSdx: Disabled requesting of thread safe D3D devices. This is a speedup, and we

shouldn't need the safety.

Jake.Stine

We discussed this in IRC and tested a bit and it should be fine. I made certain many moons ago that all calls to the GS occur from exactly one thread (in MTGS mode it's the MTGS thread, and in STGS mode it's the main emu thread), with the lone exception of the plugin enumeration and versioning functions (but those should be fine ;). So there should really be no chance of a GS plugin calling any DX function from multiple threads.

But still, this modification needs to be tested to be sure there's no lingering mistakes. Typically if there is a concurrency issue it'll rear up as a monumental failure -- either a GPF of pcsx2 or a hard lock of your computer. So if anyone gets those, please report immediately.

ramapcsx2

I'm doing this on my games right now btw.

gabest11

I tried this before, but there was no difference.

rbuldo

didnt get any crashes with about 2hours playing various games, and there is a speedup in almost everything (and now xeno 2 is finally faster than r1426)

Autor...

Everything should be a way faster, still has slowdowns in MGS3 left from r1439, other games are faster

gabest11

Tested it again and it really got faster about 10%.

gabest11

Though one of the new features of dx11 is supposed to be better multi-threading.

There are drawing contexts can be used to submit drawings on different threads and replayed fast on the main.

I'll have to think about how to take advantage of that.

heatbla...

I downed VC10... what is the difference with VC9?

gabest11

compiled with vc10 beta1

heatbla...

Thanx :") I`ll test it ASAP. Btw there were improvements with your latest GSDX - VP2 had more speciall effects visible, TEKKEN5 was faster on a certain usually-slowdown-places. GSDX gets better and better - CHEERS!

NeoFry...

Wow. FFXII jumped 60%, or 75fps to 105+fps. I think it's time to use the frame limiters.

After a bit of playing noticed some big errors in SW mode. Will post on forums.

heatbla...

Tested bot Visual compiles 9 and 10 - some small efx differences... Better speed confirmed. Steambot Chronicles still crashes emu.

Revision 1554

wxgui: Tons of updates and fixes ...

* Mostly finalized the i18n system.

* fully implemented the speedhacks dialog.

* improved the wxHelpers quite a lot.

* added a new gamefixes icon as put together by gigaherz.

xat...

can't wait to see this make it into the main branch

kaboo...

dito

Revision 1555

microVU: minor changes

joaolvas...

Sorry bored you. I have a mem card save (Mcd001.ps2), now every time i begin a game, he jumps out, only with GSdx-r1553, because with GSdx-r1538, dosen´t happend. I'm trying to help, if they want to continue to call me names, continue.

P.S.- the game works if i put in Porgressive Mode 480p, if this help.

gigaherz

ferrarin: as long as your comments are not just worthless "GT4 still doesn't work" kind of comments, and they contain useful info, we will have no reason to delete them. Now if you were to repeat this originally-useful info over and over on every new commit, than that would go back to being spam, and we would proceed to delete your repeated posts. We can read the comments, no need to repeat yourself.

gigaherz

then* (hate googlecode not having an edit comment button >_<)

joaolvas...

Gigaherz, i just want to help, for you can help me. Thanks.

gigaherz

I dont' have GT4 (or any other GT game) and I don't know what causes the problems you have with those games, so no, I cannot help you. I n any case, that's not how the team works.

You see, all the developers and contributors are people with their lives, who just like to help the project. If they aren't interested in fixing GT games specifically, then you are out of luck. You have a few options: either fix it yourself, or buy a real ps2, or just wait patiently until someday it gets fixed.

We just don't like being "reminded" of bugs, or being pushed to fix them. We are doing this for free, because we WANT to.

Revision 1556

Made a clean fix for the memzero.h template expansion bug/warning (caused by

msvc treating template parameters like macros).

joaolvas...

Before, with version GSdx1551 was not error now gives.

joaolvas...

Correct. With GSdx-1538 works, the up version dont, so i think is a GSdx problem. Sorry my mistake.

Revision 1557

Added clean_msvc.cmd, which is a batch file that deletes all the mess MSVC

leaves behind even with Clean/Rebuild. Chances are if you're having

compiler/linker problems you can just double-click clean_msvc.cmd and have it

fixed, rather than having to do a full re-checkout of sources (see file for more

details on why).

Revision 1558

wxgui: synced with trunk (to acquire new CDVD/ISO api)

Jake.Stine

I'm leaving for the weekend. I'll fix the linux side when I get back.

arcum42

All right, sounds good...

Revision 1559

Added a few new calls to PathUtils, and used them to get rid of some platform

specific code in the new Iso code. I also modified some other code to use the

new calls, and fixed a few microVU compiler warnings.

arcum42

GetWorkingDirectory was going to be GetCurrentDrectory, but Visual C++ didn't like it. And I can see one or two remnants of reverted changes in here. Not a big deal, though.

ramapcsx2

Yeah, you cannot force msvc to accept typo'ed variables :p

arcum42

That too. ^_^

Revision 1560

Reworked a few things in PcsxConfig, to make things a little more organized, and

make path changes later easier. (May have broken Linux temporarily. If so, I'll

fix it in a bit.)

arcum42

Notes: Both Linux and Windows had variables they were saving the working directory into. These have been combined.

Also, I figure if we have iso handling built in, sooner or later we'll want default directories for isos and dumps to be in.

And, yeah, I did the Windows changes first because people get all upset if I leave Windows broken for any length or time...

kaboo...

Comment by arcum42,: "And, yeah, I did the Windows changes first because people get all upset if I leave Windows broken for any length or time...

"

-True , Windows user are often very angry in their natural habitat

Scientists are guessing that it could be 'cause the "Blue Screen" feature commonly reffered to as "BSOD" has been deactivated in latest windows versions

sincerely KabooZ

system.compiler

absolutely agree......^_o

BSOD is a great feature....

<it makes me remember i often reinstall my system and spent my weekend with my computer>

damn...BSOD

(sorry double post)

arcum42

Yeah, there's nothing like that feeling when your system suddenly grinds to a halt and you have to reboot. ^_^

Though I've found I can reproduce the feeling somewhat by running my Linux system with all unstable packages, and updating it regularly, so things randomly break every so often...

Revision 1561

Fixed up Linux after my previous changes.

system.compiler

so no more BSOD for linux...?

just joking.

it's morning here.good morning.

(I'll go to work in a minutes.feel free to delete this message as it has no relation with the rev.I just love the progress in linux side.I'm always dreaming linux and windows and also other operating system will be equal each other and each of them has different special feature (like direct-X for windows and OpenGl for Linux) but has almost the same performance)

kaboo...

yeah directx for MSDOS 6.22 or for OS/2 xDDDD

Revision 1562

Converted a few of the file paths to strings, and moved the generic file

manipulation functions in IsoFileFormats to their own file.

arcum42

The Plugin and Bios paths were more complicated, which is why I haven't done them yet...

Revision 1563

Unbreak FF X-2 with the new iso code.

badkos...

for (int i = 12; i > 2060; i++)

?

arcum42

Oops. Oh well, I didn't really need to zero that out anyways. Just thought it'd be cleaner if I zeroed out the area it was supposed to copy to.

refraction

i wonder if this is similar to the classic "Auron: Look!" crash, what happens if you wrap it?

arcum42

They seem similar. When I saw how close they were, I pulled out a savepoint 20 seconds before "Auron, look!" and played with it. Didn't have much luck, though. And I recall trying wrapping it a few ways...

I spotted this one because I'd testing to make sure I hadn't broken any of the code. Took a little while to trace what the difference was in routines. The linuz plugin *never* returns anything other then 0, no matter what goes wrong.

The pcsx2 code's rigged up to set pTransfer to NULL if there was an error, but since there never was, it doesn't seem like anything was put in place to handle it...

Master.h...

have you guys emulated the ps2 cache yet ?

by the way tanx a billion for your hard works .

arcum42

There is some preliminary cache code in pcsx2 that was written quite a while back, and not enabled; my understanding is that at the time it only worked properly for a game or two, though.

While that code is still in pcsx2, it didn't survive the change in memory models, and won't compile if enabled. Most games work without it, though, so it's been a low priority...

Revision 1564

GSdx: just updating vs2010 project files

Revision 1565

Added vs2010 project files for xpad and CDVDolio, too.

gabest11

My command line build automation for 2008 is broken now, devenv just crashes with 2010 on the same machine...

So, don't expect 2008 builds until this gets fixed somehow, only if I manually compile and pack it.

animus...

Hi Gabest. Sorry for unrelated post. But I really couldn't catch your attention on forums. It's about an Issue 184 . Hardware mode is a wontfix... how about software? Here's .gs dump:

http://forums.pcsx2.net/attachment.php?aid=20016

If software mode can't be fixed please say it.

ramapcsx2

Must be a new bug in sw mode.

gabest11

Added my thoughts about xenosaga to Issue 104 .

gabest11

I mean Issue 184 , haha.

Revision 1566

Fixed some bleedthrough on the colors on the console, took care of a typo I made

earier, and did assorted cleanup.

wisestud...

This revision borken windows version...

kaboo...

4>..\..\CDVD\IsoFStools.cpp(153) : error C2440: '=': 'char *' kann nicht in 'char' konvertiert werden

4> Es gibt keinen Kontext, in dem diese Konvertierung möglich ist

4>..\..\CDVD\IsoFStools.cpp(155) : error C2664: '_strnicmp': Konvertierung des Parameters 1 von 'char' in 'const char *' nicht möglich

he said cannot convert char into const char*

and can't convert char * to char XD

arcum42

Already taken care of.

kaboo...

yeah I noticed a minute after posting -.-

why does that wokr in linux and in windows not? (I just assume it works in linux :P)

arcum42

I have no idea why that works in Linux.

And, yes, it does compile and run in Linux. No matter what "vaustein" may think (on the forums), I do compile all changes before committing, and normally have run at least the opening of a game. (Multiple games and more then the opening, if it's a major commit)

Major commits get tested in Windows as well, but this was mainly a collection of minor stuff. One of the changes in CDVD.cpp and the change in Console.cpp were the main things I wanted to commit. The rest were just incidentals...

Revision 1567

microVU:

- Re-implemented logical min/max code

- Re-implemented tri-ace gamefix

- Fixed some bugs...

Revision 1568

microVU: Setting VU clamp mode to "normal" should fix sps/problems in alot of

games now.

I'll list what I think should be fixed:

Dawn of Mana SPS <- Should be fixed, untested

ToTa Characters <- Should be fixed, untested

FFXII SPS in Barheim Passage <- Should be fixed, untested

KH1 floor bug <- Fixed for me, but theres still other sps on characters caused

by something else

Most-likely SPS in some other games is fixed as well...

If anyone can confirm the games I listed are fixed, please leave a comment :D

cottonvibes

I confirmed Dawn of Mana sps is indeed fixed.

shoegazer tells me this fixed burnout as well.

rbuldo

tales of abyss disappearing characters is not fixed

pcsx2gu...

FFXII SPS in Barheim Passage: Confirmed,fixed.

ltc.inv

There is no more SPS around characters in ToTa when clamp is set to normal, but characters are now invisible.

Autor...

Nice Commit, fixes:

MGS3 SPS

MK Deadly Alliance missing geometry

Simpsons The Game SPS

zantezuken

Well...

It fixes SOME sps in Castlevania, but not all of them.

Still, now, it is MUCH better :P

Nice work.

cottonvibes

thanks for the comments guys.

Revision 1569

Quick fix for r1566.

gigaherz

That shows what's probably C's most annoying design problem (pointers being a variable attribute instead of part of the type).

yo ucould have also solved it like

char *token, *ext_point;

but I guess it looks "wrong".

gabest11

more weirdness: a typedef'ed pointer will not have this problem :D

arcum42

Oh, if I'm reverting a change, I just tend to revert it back to exactly the way it was. The other way would have been fine, too.

It was one of these things where, once I saw it, I knew exactly what I'd done wrong, but I just hadn't noticed it at the time...

Revision 1570

microVU: more regAlloc work...

espresso...

This rev fixes We Love Katamari (SLUS 21230) missing polys problem introduced in r1545. Thanks Cotton!

Revision 1571

GSdx:

- Automatic texture filtering should be ok now, occasionally point filtering was

used. Tested it on the ps2 and figured with no mip levels LoD and minification

settings are just ignored altogether.

- Also run a few tests on the gather instruction with the reference rasterizer

and found a fatal flaw with it. It returns the four samples for bilinear

sampling (in a funny order, which isn't documented of course, x = bl, y = br, z

= tr, w = tl), but there is no way to guess which four were selected exactly.

Due to some hidden rounding error it might grab different texels than I would

when calculating the position of the upper-left texel, of which the fractional

part is be used for the interpolation. When the texel positions do not match it

leaves annoying discontinuity errors. Oh well...

gabest11

Forgot to mention but the pixel shader might be too complex for 2.0 and it won't compile.

error X5426: Shader uses texture addressing operations in a dependency

chain that is too complex for the target shader model (ps_2_0) to handle.

So I added the D3DXSHADER_SKIPVALIDATION flag, let's see if it works :P

gabest11

Btw, it's probably because texture coordinates are now looked up for region repeat modes, ever since Jake enabled it in r1340 :P

ramapcsx2

Texture filtering seems fine again.

Noticed it stopped filtering a few textures in Grandia3 a while ago.

Well, that's fixed :)

gabest11

GT4 has problems that I cannot fix, the data coming from pcsx2 is wrong.

gigaherz

Hey gabest, just checked it a bit, and it seems sm4.1's gather is meant specifically for shadow stuff: it supports only single-component texture formats, and returns the values in w,z,y,x (clockwise)... or that's what AMD/ATI's pps says :P

Also, quoting from: http://msdn.microsoft.com/en-us/library/bb944003%28VS.85%29.aspx

"Gets the four samples (red component only) that would be used for bilinear interpolation when sampling a texture."

I'm not sure what were you trying to use Gather() for, but I don't think it's useful in its SM4.1 version.

On the other side, SM5.0 (d3d11) supports GatherRed, GatherBlue, GatherGreen and GatherAlpha, so that one might be useful, I guess.

But maybe you already knew. :P

ramapcsx2

This sounds a bit like it could be used for blending?

(Hoping some clever technology comes up to replace the problematic blending in hardware rendering :p )

ramapcsx2

GSTextureFX10::SetupOM << this stuff. It causes like 80% of the remaining bugs (exaggerated, but still :P )

gabest11

gigaherz:

I wanted to use it to replace four texture sampling with one, for palette lookups when first reading the indexed texture.

After getting the sample order right (trial and error), it actually worked about 99% well, just those ugly dots that appeared because of inaccuracy...

Only reading red channel isn't a problem, as I can create the indexed texture as a red-only format.

It would be more convenient if it returned the alpha though.

gabest11

ramapcsx2:

huh? :P

ramapcsx2

Games I know are broken due to the blend (can even hackfix them sometimes ) :

-Haunting Ground (The stripes in the image)

-Valkyrie Profile 2 and Radiata Stories (Also the stripes, the games are trying to do some depth of field effect and fail)

-I think Shadow of the Colossus and the Ghostrider game as well (not confirmed yet :p )

gabest11

The stripes are the sign of 32/16-bit frame buffer casting.

16 bit data is arranged so that it takes up every other 8 pixel of the 32 bit frame buffer, or something like that.

Games specifically draw in columns then change the format and it magically becomes right.

ramapcsx2

Here's my results for valkyrie profile 2:

-First is software rendering, which shows the depth of field effect working:

http://img5.imagebanana.com/view/ijwnwuc2/blend_sw.jpg

-Second is dx10 hardware rendering as it is now:

http://img5.imagebanana.com/view/h6o102vo/blend_hw_unmodified.jpg

-Third is dx10 hardware rendering with this hack:

//bd.BlendOpAlpha = D3D10_BLEND_OP_ADD;

bd.BlendOpAlpha = D3D10_BLEND_OP_MIN;

http://img5.imagebanana.com/view/q2gqg217/blend_hw_hack1.jpg

And last one is with another hack added, that fixes the texture scaling:

dst->m_texture->m_scale.y = (float)h / hh * 0.8f;

http://img5.imagebanana.com/view/o0xd6ieo/blend_hw_hack1hack2.jpg

ramapcsx2

I hope this helps somehow. If not, I thought about asking what you think of game specific hacks in GSdx? :p

xat...

Are the aforementioned blending issues vaguely related to TotA's offset bloom effects?

ramapcsx2

Nope, those are a slightly different issue (but related to the texture scaling hack).

mrdeathj...

Thanks for your plugin, run fine i probe your plugin dx9 in wine but run slowly but you have planned plugin for opengl?

gabest11

ramapcsx2:

Is it using one of the blending modes marked "bogus"?

Upscaling ratio is only estamated, offscreen rendering may span over the frame buffer edges :P

mrdeathjr28:

Opengl is hard (chaotic is better word) and I have no help, currently on hold.

gabest11

Found an old .gs that has the clipping problem but can't see the blending problem with it.

ramapcsx2

"Is it using one of the blending modes marked "bogus"? "

I think so, yeah :p

"Upscaling ratio is only estamated, offscreen rendering may span over the frame buffer edges :P"

Ah, ok. I thought it was due to lots of rounding, and at some point it missed an important pixel or smth.

ramapcsx2

I think it uses // * 0200: (Cs - 0)*As + Cs ==> Cs*(As + 1) ...

andutrache

thank you its fixed now.

P.S: EXCELENT job :)

ramapcsx2

This .gs should work (Also has some nice texture detail etc, vp2 is looking awesome! :p )

http://rapidshare.com/files/260343585/gsdx_20090726213728.7z.html

ramapcsx2

The common thing with the red fog garbage in vp2 and xenosaga3 and the overbrightness is all in this part btw:

else if(tw < tp)

{

// FIXME: timesplitters blurs the render target by blending itself over a couple of times

All these games have that condition, and if we simply return there the buggy scenes get skipped.

Any idea if that can be done better? :)

gabest11

This file is neither allocated to a Premium Account, or a Collector's Account, and can therefore only be downloaded 10 times.

I was late to the party :P

ramapcsx2

Sigh, I've had it with file hosts... :p

http://www.mediafire.com/?sharekey=4e933fd957af5f25b94117dade8fc295e04e75f6e8ebb871

heatbla...

Steambot Chronicles still crashes emulator when started... wonder what`s the reason..... But otherwise - good job!!!

ryanz_...

please re upload the file ramapcsx2.. thx and god bless

Revision 1572

wxgui: Improved threading model used by the log window, plus a few minor fixes

to main window startup/shutdown code.

Revision 1573

microVU:

- Finished implementing regAlloc. Sadly the speedgain wasn't great (0%~2% in the

games I tried). I think the speedup should be bigger with a CPU that supports

SSE4.1, but I don't have one to test :p

cottonvibes

Anyways I was able to cleanup a lot of code while implementing the regAlloc so its not a complete loss. And having a regAlloc class to manage reg allocations makes future modifications easier :)

Autor...

Speedup is always good, even if it small

ramapcsx2

Lemme test that. :p

ramapcsx2

Ok, preliminary results are somewhat poor. Sometimes I can't even see a 1fps difference.

I'd say you got a bug somewhere?

saku...

Red terrain bug in Shin sangokumusou 4 (Dynasty warrior 5) was again.

and still SPS.

Castrat...

Hey man, if it makes future modifications easier that's a plus. Remember, that was one of the reasons you began this project, to make the management easier. So to take a step towards that in my mind is a success. Keep it up.

Revision 1574

microVU: tweaking/testing some stuff...

Revision 1575

microVU: fixed a bug in my clamping code from r1568. Fixes TOTA invisible

characters when clamp-mode set to 'normal'

pavlovm...

Is it OK that opCase3 and opCase4 have no difference (setupPass1 method)?

opCase3 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }

opCase4 { mVUanalyzeFMAC1(mVU, ((isACC) ? 0 : _Fd_), _Fs_, 0); }

rbuldo

nice, another bug squashed

cottonvibes

@pma:

yes its okay ;p

Autor...

just a little testing

game Naruto Shippuuden Narutimate Accel 2

these screens captured with microVU (missing geometry proble)

http://img136.imageshack.us/img136/9958/mvu1.jpg

http://img136.imageshack.us/img136/3881/mvu2.jpg

http://img136.imageshack.us/img136/8683/mvu3.jpg

and these ones are with superVU (still mising geometry but much better compare to mVU)

http://img259.imageshack.us/img259/8009/svu1.jpg

http://img406.imageshack.us/img406/8349/svu2.jpg

http://img136.imageshack.us/img136/9393/svu3.jpg

cottonvibes

autor:

try turning off both mVU speedhacks, they were causing problems in NuN3.

i don't have NA2, but its most-likely the same problem.

Autor...

Nothing changed unfortunatelly

andutrache

use mvu0 and svu1 and it should work

Autor...

for this game it's the same as using just sVU

Revision 1576

Working on a brand new plugin interface, based on passing APIs via structure

instead of individually binding each function (which is generally cumbersome and

limited in a number of ways).

Jake.Stine

Much work and documentation left to do, but it's a good starting point I hope (and I need a break for a few hrs). I've been trying to cover most of the initial sticky points with irc discussions, but there's likely things I'm still overlooking.

Also, I'm planning on retaining most or all backwards compatibility with existing plugins using a compatibility layer api. So no worries there.

gabest11

If you really want to create something cool, why not make it a bit object oriented like COM? Without reference counting of course :P

First parameter would be the instance data, the "this" pointer.

It's just so ugly that plugins define it as a global variable instead of dynamically allocating it in the only exported function like DllGetClassObject and getting back as the first param in each call.

Jake.Stine

Actually that's not a bad idea for performance efficiency, if nothing else. If I change from CALLBACK to __fastcall that can actually reduce the overhead of function invocations by quite a lot, and really there's no reason to be using CALLBACK on all those fnptrs. I was just following the established convention.

Revision 1577

Cleaned up some loose ends I left behind in my initial rough draft of

PluginCallbacks.h, and added some eol-style:native properties to /common/include

files that lacked them.

Revision 1578

microVU: Improved microProgram management/searching.

Instead of just having live/dead programs, we now have young/old/dead programs.

cottonvibes

This works great with GoW (the game still needs the CHECK_VU_CONSTHACK hack ON to get good speeds)

Super VU will always run GoW faster however because it recompiles alot less than mVU.

But, mVU runs the game more accurately:

Super VU: http://img.photobucket.com/albums/v177/ouchmytiredhurt/zeroRecsGoW.jpg

microVU: http://img.photobucket.com/albums/v177/ouchmytiredhurt/mVUGoW.jpg

valeri...

Gow with this executable is fully playable without the blocks?

Autor...

This fires on blades of chaos is always were correct on MicroVU

VU_consthack is good but still fps in GoW is unstable anyway i like this game on microVu more than on SVU

Revision 1579

NewPluginApi: Some tweaks as per Gabest suggestion; probably a tired disaster in

need much review.

kaboo...

// fixme! [air dies of sleep deprivation]

yo me 2 >.>

but now I'll get a good night's sleep... or rather day xD

btw air you work mostly on larger projects (or so it seems to me^^)

how come?

RebelliousX

I like this function OSD_WriteLn().. also can't wait to see a snapshot

of savestates being displayed at the right top corner like psx emus.. ^^

One silly question tho, I wonder if external developed plugins (not with

pcsx2 project) would be compilable with these new changes and new definitions?

or it would be like before, all whats needed is "PS2defs.h and PS2Etypes.h"?

gigaherz

Well, the files will change, but it'll be like before. The existing plugins will have to be updated to use the new interfaces tho.

Jake.Stine

@Kabooz:

>> btw air you work mostly on larger projects (or so it seems to me^^) how come?

... because I'm too fancy for my own well being.

Jake.Stine

@Rebellious:

>> One silly question tho, I wonder if external developed plugins (not with

pcsx2 project) would be compilable with these new changes and new definitions?

Like before but, hopefully, even better. I'm trying to keep the design as independent of emulator and external libraries as possible. It will check for and use certain things if available (such as some of wxWidget's base cross-platform defines for window handles), but these aren't critical defines either... in that they have reasonably sufficient fallbacks.

gabest11

That's nice, but I imagined it just a bit different :P

With a little change it would be possible to cast those function pointer structures to c++ classes with the novtable attrib.

That's way it would be compatible with c and c++ at the same time.

gabest11

"That way" I mean, where is the edit button!

cottonvibes

Google has ingeniously converted the "edit" button into "delete + retype comment + submit" xD

Wagnar...

LOL for me its more "Copy+delete+paste+fix your error+submit"

;)

Jake.Stine

>> With a little change it would be possible to cast those function pointer structures to c++ classes with the novtable attrib.

You're going to have to be more specific because I'm not sure what you mean.

The novtable is MSVC specific so I assume its use is in the plugin only, although the docs for it are vague so I'm not sure how it really changes typecast behavior, or how I'm supposed to restructure the struct to match it. And I don't know anything about COM except that typically I can't comprehend its bizarre syntax and profane use of operator overloads, so citing that as an example probably won't be helpful.

gabest11

Did not test it, but something like this:

struct IPlugin;

struct IGS;

#if defined(__cplusplus)

struct __declspec(novtable) IPlugin

{

virtual bool CALLTYPE init() = 0;

};

struct __declspec(novtable) IPluginGS : public IPlugin

{

virtual void CALLTYPE vsync(int vsync) = 0;

};

#else

typedef struct IPluginVtbl

{

bool (CALLTYPE *init)(IPlugin* _this);

} IPlugin;

typedef struct IGSVtbl

{

bool (CALLTYPE *init)(IGS* _this);

void (CALLTYPE *vsync)(IGS* _this, int field);

} IGS;

#endif

class GS : public IGS

{

// IPlugin

bool CALLTYPE init();

// IGS

void CALLTYPE vsync(int field);

public:

GS() {}

};

extern "C" __declspec(dllexport) IPlugin* CreatePlugin(int type)

{

switch(type)

{

case GS: return new GS();

}

return NULL;

}

gabest11

IPluginGS => IGS

gabest11

When inheriting a class in pure c the members have to be repeated, that's the only annoyance.

gabest11

In COM the name, version and other properties are stored in the registry so there are no exported functions to query those.

It would be bad to just create the plugings for that. There could be another exported function which returns just this information in some struct.

gabest11

hm, if there is a "new GS()" there has to be a "delete" somewhere... to not mix memory managgers, only the dll can delete it.

gabest11

If it was reference counted it could deallocate itself in the last Release call, but I think now we need to resort to another exported function just to do that.

Jake.Stine

Hrm, if it were doable then best way to do that is to literally make an entirely separate header file that's MSVC/C++ specific. But I don't think it'll fly.

For one, it's a compiler error to use virtual functions or inheritance with struct types, so the IPluginGS will need to be classed. But regardless, the plugin's derived implementation needs to be a full-blown class (minus novtable), and at that point MSVC is entirely welcome to take certain liberties with how it lays out the vftable in memory (since its entirely allowed to, by spec) ... which would result in pcsx2 invoking the wrong functions unintentionally.

Furthermore, the vftable is usually not even stored as part of the class. I noticed for example in my new IOP work that MSVC constructed a single static version of the vftable for my InstructionOptimizer class, and most instance code referenced it directly (it's a good optimization since it eliminates a large chunk of memory and initialization overhead associated with classes with lots of virtuals). Other instance code that used the Instruction base class dereferenced the single vftable* at the head of the class. But this storage behavior can change from class to class, and most certainly has changed between versions of the compilers.

All of this still applies even with 'novtable' since that's only eliminating vtable overhead for the base classes -- the code still relies on there being a vtable generated for the plugin's derived implementations.

So yeah, it *might* work, but if it works at all, it would be working by the graces of the compiler deciding to adhere to the programmer's specific function order specification, and it not deciding to optimize the vftable to a static table outside the context of the structure itself. I don't think it's a good idea to encourage that sort of rules-breaking in a plugin spec. :/

gabest11

Well, believe it or not, every COM interface is defined this way and it works.

MSVC compiled code could use the class def with virtual functions, others (pcsx2 or plugins in c) the struct with function pointers, whcih is no different from the already suggested structures.

gabest11

Just a random interface from dx10:

extern RPC_IF_HANDLE __MIDL_itf_d3d10_0000_0000_v0_0_c_ifspec;

extern RPC_IF_HANDLE __MIDL_itf_d3d10_0000_0000_v0_0_s_ifspec;

#ifndef __ID3D10DeviceChild_INTERFACE_DEFINED__

#define __ID3D10DeviceChild_INTERFACE_DEFINED__

/* interface ID3D10DeviceChild */

/* [unique][local][object][uuid] */

EXTERN_C const IID IID_ID3D10DeviceChild;

#if defined(__cplusplus) && !defined(CINTERFACE)

MIDL_INTERFACE("9B7E4C00-342C-4106-A19F-4F2704F689F0")

ID3D10DeviceChild : public IUnknown

{

public:

virtual void STDMETHODCALLTYPE GetDevice(

/* [annotation] */

__out ID3D10Device **ppDevice) = 0;

...

};

#else /* C style interface */

typedef struct ID3D10DeviceChildVtbl

{

BEGIN_INTERFACE

HRESULT ( STDMETHODCALLTYPE *QueryInterface )(

ID3D10DeviceChild * This,

/* [in] */ REFIID riid,

/* [annotation][iid_is][out] */

__RPC__deref_out void **ppvObject);

ULONG ( STDMETHODCALLTYPE *AddRef )(

ID3D10DeviceChild * This);

ULONG ( STDMETHODCALLTYPE *Release )(

ID3D10DeviceChild * This);

void ( STDMETHODCALLTYPE *GetDevice )(

ID3D10DeviceChild * This,

/* [annotation] */

__out ID3D10Device **ppDevice);

...

END_INTERFACE

} ID3D10DeviceChildVtbl;

interface ID3D10DeviceChild

{

CONST_VTBL struct ID3D10DeviceChildVtbl *lpVtbl;

};

#ifdef COBJMACROS

#define ID3D10DeviceChild_QueryInterface(This,riid,ppvObject) \

( (This)->lpVtbl -> QueryInterface(This,riid,ppvObject) )

#define ID3D10DeviceChild_AddRef(This) \

( (This)->lpVtbl -> AddRef(This) )

#define ID3D10DeviceChild_Release(This) \

( (This)->lpVtbl -> Release(This) )

#define ID3D10DeviceChild_GetDevice(This,ppDevice) \

( (This)->lpVtbl -> GetDevice(This,ppDevice) )

...

#endif /* COBJMACROS */

#endif /* C style interface */

#endif /* __ID3D10DeviceChild_INTERFACE_DEFINED__ */

gabest11

I have even seen mplayer using directshow filters under linux through the c-only structures.

gabest11

well, there seems another level of indirection, the vtbl is a the first member of what CreatePlugin would return, allocated as a class, but it's basically the same.

gabest11

ah, can't write again :P

gigaherz

Gabest: is it even WORTH doing that? seems like it would bloat the plugin interfaces way too much, just to make it "cross-compatible" with C++ objects... :/

Revision 1580

microVU: tweaked some regAlloc stuff; i think it should be faster.

sunnydra...

anyone tested this ?

http://developer.amd.com/cpu/Libraries/sseplus/Pages/default.aspx

Ami.Mizu...

I benchmarked FFX intro:

sVU

----

2009-07-29 15:38:53 - pcsx2-r1580

Frames: 8290 - Time: 64654ms - Avg: 128.221 - Min: 100 - Max: 176

mVU

----

2009-07-29 15:36:04 - pcsx2-r1580

Frames: 8310 - Time: 62977ms - Avg: 131.953 - Min: 102 - Max: 179

mVU wins! But not by much but hey that's the first time I see faster speed with mVU I think.

ramapcsx2

Xenosaga runs faster with mVU now :)

FFX, FF12, Persona4 and DragonQuest8 all run slightly slower than with svu yet.

Still, this is the kinda speedup i was hoping for with regalloc. Nice job :)

Ami.Mizu...

Resident Evil 4 also runs like 2~3% faster for me with microVU than superVU now.

Jake.Stine

Comment by sunnydrake7

>> anyone tested this ?

>> http://developer.amd.com/cpu/Libraries/sseplus/Pages/default.aspx

Because PCSX2 is primarily working via dynamic recompiliation, that lib wouldn't be of too much benefit. It could benefit plugins like gsdx or spu2x though. Will have to look into it further later.

Revision 1581

More new plugin api work.

Revision 1582

wxgui: synced with trunk, and started work on an improved plugin initialization

procedure. (branch currently does NOT compile, sorry)

Jake.Stine

Sorry about the branch not compiling. My next commit won't b for 4-5 days, and hopefully I'll have everything sorted out by then.

kaboo...

oh nooo!!! the pain!!!!

how could you do this to us..... and I thought you were one of the good guys :P

though if you really beat yourself up about this "there there" as sheldon might say XD

steven_copson

not to be so negative but why commit if you know its broken compilation and your not going to be able to sort it for the next 4-5 days wont that stop other devs for fixing and updating things as they wont be able to commit there stuff for others to test and work on as nobody is going to be able to build the source?

refraction

steven: no other devs work on the wxgui branch, plus commits dont have to assure a working version if you know its going to be fixed soon, we can revert to an earlier revision if need be.

arksine....

One big reason to commit a broken build is for backup purposes. You never know what could happen while you are away. It also lets others see where the current build is headed.

Anyway I don't believe anyone other than Air is working on the wxgui branch. The other devs can continue to work with the trunk.

ntcong.it

arcum recently worked with this branch too.

Jake.Stine

>> not to be so negative but why commit if you know its broken compilation and your not going to be able to sort it for the next 4-5 days wont that stop other devs for fixing and updating things as they wont be able to commit there stuff for others to test and work on as nobody is going to be able to build the source?

That's why it's a BRANCH.

Revision 1583

microVU: fixed a bug

Revision 1584

GSdx:

- Trippled the number of cached textures, many games constantly recreated them

- Don't clear some shaders at each drawcall (in dx10) , which is a nice speedup

(but could potentially be bad, please check..)

heatbla...

I`ll check DX10 mode asap and report how are the games after I get back from work. Thanx for the update :")

rbuldo

i noticed a speedup of around 5% in various games

keb...

the only game i have where the graphic card is the bottleneck is FFXII in the menus with the recent 8-bit texture option tuned on, and i didn't notice any improvement, but it didn't seem to break anything either

shagkon

Wow, negative from ferrarinews! It's probably didn't fix GT4 again :p

pcsx2gu...

It's ok,as long as he keeps spamming,the game doesn't get touched :)

Rama: What bugs could it cause? We really need to start concentrating on GSdx accuracy than keep adding speed changes that could increase the already large count of bugs :/

ramapcsx2

Any bug by this would be of the obvious kind. You'd spot it instantly :p

cli...

much slower in final fantasy x-2 drop about 8-10fps compare to r1571 (D3D internal res:1024x768)

heatbla...

I am interested what happened with Steambot Chronicles. I`ll test it asap and report.

kojikni...

Doing various tests with persona 3, 4, and FFX I'm not seeing any huge difference, Persona 3 and 4 I don't see anything at all, with FFX I'm seeing about 1-2% less usage of the CPU but the same frame rate. Haven't noticed a single thing broken though.

ramapcsx2

climhz:

I did a variety of test on ffx-2, there was no difference in speed.

I'd need to know at what scene you get that slowdown though, maybe attach a .gs.

ramapcsx2

kojiknight: Yeah, this optimization is highly game specific. It helps xenosaga for example.

cli...

it mihen highroad scene

http://www.mediafire.com/download.php?zw2yjmnyrnj

ramapcsx2

It'd help if i saw something in that .gs :p

Anyway, the GSdx framecounter is working, and it says 86fps with this mod, and 81fps without this mod.

Can you tell me:

- Your vga card name

- Your cpu name and clockspeed

- If you run in dx9 or dx10

heatbla...

Report: Steambot Chronicles still crashes PCSX emu.

Other games have better graphical fixes of some glitches. Speed in Tekken5 is decreased by 2-3 fps in some terrains.

ramapcsx2

Ok, I get it Steambot is broken. Please don't turn this into another gt4.. :p

heatbla...

:) Nope, just reporting, rare issues, otherwies everything is fine. Some EFX are better in games like VP2 and Tekken 4,5 and TAG. However I am not using any speedhacks. I am reporting Steambot because it`s the GSDX that makes the emu crashing - the 1474 rev was OK, not that I will switch to it - just gave a report :) Hope it`s useful.

ramapcsx2

We'll look at it sooner or later. Sooner if you can provide a dump or .gs file that shows the bug ;)

cli...

i use 8600GT 256MB GDDR3, E2180, Dx9. maybe this happen only with weak vga card (i know mine is weak but it runs faster with older gsdx rev)

ramapcsx2

Well, this spot obviously stresses something in GSdx, and either your cpu, the vga card, or the dx9 api cause that slowdown (My guess is its dx9).

Ilya.Veselov

My guess would be a lack of video memory. It was mentioned before, that the games that use a lot of textures (like Xenosaga) requires a lot of video memory (512+) and raising cache size could move requirements even further.

gabest11

I was reinstalling my system, on windows 7 now :P

The texture limit could be much more sophisticated, 300 or 600 does not matter, most games are below the limit, but when a game like xenosaga runs out of vram (256MB is not enough for that game) it is no longer fun, let it be using 100 or 1000 textures.

Instead, the real amount of vram should be the upper limit, but ever since agp it became virtual and hard to figure out. I think dx7 was the last one that could tell the real psychical vram size.

This "virtualization" works better with dx9 where each texture has a copy in system memory and could be swapped in fast, but with dx10 to make room for a new texture another must be read back and saved, which is very slow.

About not clearing shader resources. Then the debug runtime complains and manually unbinds them, I don't know how harmful that is or is going to be in the future.

heatbla...

@ gabest11

Very well spoken lecture! Thank you for the detailed explanation.

ramapcsx2

Ok, I was doing a thorough check on the shader resource clear, to see if any game had any issue with it.

Since that wasn't the case, I figured we should take that speedup.

Revision 1585

microVU:

Saw that SSE4.1 has ptest, and I wanted to try it out xD

untested though cuz I don't have an SSE4.1 cpu :)

saku...

compile error -

ix86_legacy_sse.obj : error LNK2001: "class x86Emitter::Internal::SimdImpl_DestRegSSE<102,5944> const x86Emitter::xPTEST" (?xPTEST@x86Emitter@@3V?$SimdImpl_DestRegSSE@$0GG@$0BHDI@@Internal@1@B)

cottonvibes

fixed in my other commit.

its odd that i didn't get the link error...

NeoFry...

How do you test? It doesn't crash until I try to close pcsx2...

cottonvibes

The crash at closing pcsx2 can't be from this.

Rama already tested this for me, and it appears to be working correctly.

If it wasn't correct it would break pretty much every game or crash in-game :p

NeoFry...

Ah, well it just makes games faster, so good call. :)

Revision 1586

minor fix for broken compiling

Revision 1587

Some cleanup around iCore.

arcum42

I turned some defines into inline functions, and made sure that it wasn't checking if u32s were >=0 in them, and made sure the functions were being used, since there were a bunch of places where if statements equivalent to the defines were being used instead of the defines.

I spotted a discrepancy that might be a bug, but I'll leave it till I'm sure which behavior is correct...

arcum42

And, yes, they are still called by defines to my new functions for the moment, since I didn't feel like lots of search and replace, and I might change the names a bit to look nicer...

Revision 1588

Stub out some functions in the cache code.

arcum42

This is just mainly because I'd rather have broken (ifdeffed out) code in the trunk then uncompilable broken code in the trunk(again, ifdeffed out)...

ramapcsx2

Nice work all around, just a small request :p

Please consider that jake has a lot to merge already each time he updates the wxwidget branch.

So since he's away right now, the more we update pcsx2, the more he'll have to merge.

So best keep it simple is all I'm saying :p

cottonvibes

I should add that Jake plans to merge the wx branch into trunk soon.

His goal is sometime next week if time allows him to.

arcum42

I'll keep it in mind. Sounds like a good time to work on plugins, since they should be the same between the wx branch and the main trunk. and there are a couple other things I have to take care of anyways.

I'd been meaning to look more at what Jake had done with the wx port recently, since it seemed like it was getting close. Just hadn't a time recently where it would compile on Linux...

ramapcsx2

Alright, good luck then with the plugins.

I'm also having "fun" currently with that :p

Revision 1589

microVU: Optimizations, cleanup, and fixed a bug...

kojikni...

Latest build gives me 200+ new warnings all "c4800: 'int' forcing value to bool 'true' or 'false' (performance warning)

Program still compiles, but it immediately crashes when you try to load a game or start the bios.

cottonvibes

what compiler are you using?

msvc isn't giving me any warnings.

also can you tell me some of the line numbers where these warnings are happening.

if its talking about stuff like:

if (someInt) { doSomething(); }

then yeh i've been doing that stuff since the beginning of mVU.

ntcong.it

what the...it's traditional C/C++..

force 'int' value to bool is not a warning, lol.

it should be because of compiling with Warning level 3

Revision 1590

microVU: more optimizations

nstorm...

I am getting this error on the console when trying to run this revision:

First try failed allocating Micro VU1 at address 0x5f240000

But the PCSX2 itself continues working (didn't tested actual run, don't have bios dump atm).

rbuldo

works fine for me, no weird errors

gigaherz

Comment by nstorm0.0, Today (3 hours ago)

I am getting this error on the console when trying to run this revision:

First try failed allocating Micro VU1 at address 0x5f240000

But the PCSX2 itself continues working (didn't tested actual run, don't have bios dump atm).

--

This isn't an error you should care about. It's normal that it happens, and depends a lot on your system configuration (drivers and devices connected), and also by chance (address space randomization in vista).

As long as it continues working and doesn't fail to allocate it, its fine.

nstorm...

I see, thanks gigaherz for you comments.

Btw I've tested under XP Pro SP2. But I couldn't disagree - as long as it works, it's fine.

Revision 1591

GSdx: little code cleanup

resident...

Well what ever was causing the no output on the gma 950 is fixed with the clean up :D

no edit X|

but just read through, and saw the software vertex shader

nice job!

ramapcsx2

if(hh < 512 && m_renderer->m_context->SCISSOR.SCAY1 == 511) // vp2

^ Great :p

ramapcsx2

Also I see you have that PSSetShaderResources call in again. Somehow this doesn't slow down the build for me. Cool :p

Btw, try this here in Create() as a swapchain flag. It's interresting :p

D3D10_CREATE_DEVICE_PREVENT_INTERNAL_THREADING_OPTIMIZATIONS

gabest11

Checked with the debug runtime and calling it only at the end of StretchRect was enough, that's only called a couple of times per frame.

gabest11

But preventing any kind of optimizations doesn't sound good :P

ltrap...

Heh. It looks like previous glitch with thin lines developed to the new level: http://img229.imageshack.us/img229/9647/glitch4.png (Persona 4) >.<

GS, if needed: http://www.mediafire.com/file/wjz42zmlitk/gsdx_20090801133420.rar

ltrap...

It's the same for P3. Seems like they are using same engine.

gabest11

Again, the gs is incomplete in two frames, only the battle scene and the shadows are there :P

gabest11

Tried it myself and it doesn't look that bad.

http://guliverkli.sf.net/dx9.png

http://guliverkli.sf.net/dx10.png

ltrap...

Hmm.. it seems impossible to save dynamic scenes from this game in gs. x_X

Don't know what to think now. Maybe it's somehow related to my graphics driver or such

gabest11

it is possible, I dumped those from a gs, just don't use any speed hacks

ltrap...

All right here is the .gs with all speed hacks disabled:

http://www.mediafire.com/file/y0jlyzt0dkn/gsdx_20090801160732.rar

gabest11

http://guliverkli.sf.net/dx10-2.png

no idea :P

ltrap...

The last working build:

1426 - with no graphical garbage;

1469 - with no strange lines.

ramapcsx2

I'm pretty sure this is a case of odd multiples of the native res.

Try setting the D3D internal res to exactly *4 of the native res (typically 2560 * 1792, but check the GSdx window).

This odd rounding causes too many glitches, in other games as well.

We really need a more fixed scaler (like scale * 2 and scale * 4), at least as an option.

ltrap...

OMG. I found out that if I uncheck "Allow 8-bit textures" box the problem with lines solved itself.

ltrap...

And about resolution - maybe it'll be better to add multiplier of native resolution instead of custom dimensions?

ltrap...

Most people won't know in life what is D3D internal resolution is and many forums recommend to set it as you said to *2 or *4 of native. Why not to simplify the task for most of the users?

ltrap...

For example as shown on the picture: http://img228.imageshack.us/img228/541/resmul.png

ramapcsx2

Lol, nice job on that montage :p

But yeah, this is what I meant essentially.

There's the problem of the ressources this needs though.

X2 is 1280 * 896 which is fine. Next step (x4) is 2560 * 1792 already though.

That's about the point my card beginns to struggly. X8 is out of the question :p

But on the other hand it fixes oh so many glitches, so its really worth it imo.

kaboo...

then why not like this:

native

X1.5

X2

X2.5

X3

should work for most people I guess .25 steps would work as well

gabest11

... and how do you express the lcd-native fullscreen resultion like 1680x1050 with multipliers? :P

chane2k1

see your point gabest but, it would be nice to have a multiplier option for those games that have different native resolutions. that way we wouldn't have to change the resolution just to have a 1:1 x2 resolution output. some of my games are 512x512, 640x448, and 640x480. i know i don't have too but, i always change the native resolution to a multiple of the original and with a 2x option we wouldn't have to change it for games that have different natives. you're doing great work as it is though, so keep it up. :)

kaboo...

Comment by gabest11, Today (47 minutes ago)

... and how do you express the lcd-native fullscreen resultion like 1680x1050 with multipliers? :P

there is no difference in quality between the internal resolutions when it comes to LCDs at least with DX10 and DX11 not tested in DX9

also it doesn't matter if you have the same resolution you use for your desktop (at least I have never seen one Oo)

ramapcsx2

Yeah, output res is totally irrelevant. What matters is that non power of 2 scalers do shift the textures a tiny bit. Leading to glitches like this:

http://img5.imagebanana.com/view/omhh2mt5/1.jpg

http://img5.imagebanana.com/view/ov69oqji/2.jpg

Admittedly, fixing the scalers to powers of 2 just fixes half the glitches, but its better than nothing ;)

shadowladyngemu

Been having some problem with this revision, some games output "Gsdx: m_merge is NULL!" which they didnt before and in some games right after this PCSX2 crashes if I have any interlacing mode enabled and native mode not enabled.

So far just got 3 games that do this which I kept in HDD and cant test more cause i'm not home, but anyway Megaman X8, Gradius V and Bleach: Blade Battlers crash.

shadowladyngemu

In regard of the 2x 4x native res discusion, you could just add a default dropdown menu for native, 2x and 4x for example and instead of a "native" checkbox make it a "custom" checkbox that would change the d3d int res option into the one we have now for those who want it that way.

In my case with just 512x512 games 2x is not enough quality while 4x is too much which is why I like using 1536x1536 instead.

shadowladyngemu

Or like the one we have right now being greyed until you check "custom" that would enable the custom box and grey the "native/2x/4x" one in my example.

kaboo...

nice idea shadow lady O_o

and yo my gradius V crashes too with interlacing and custom res

ramapcsx2

Hmm, you need to have a interlace mode set in the options for it to crash.

Took me a while to figure that out :p

shadowladyngemu

Oh yeah forgot to say that in firsr comment and I was gonna say it next but forgot, my bad xD

blame no edit button :x

inte...

that revision brings back the old and famous "ghost bug", from tales of abyss :/

1490:

http://img145.imageshack.us/img145/5104/gsdx1490.jpg

1491:

http://img142.imageshack.us/img142/3875/gsdx1491.jpg

thumbs down, unfortunely.

(both with 1440x900 of internal res)

ltrap...

Maybe it's even better to use edit box with real numbers (1 up to 8 with 0.5/0.1 step) instead of dropdown list with multipliers? All better than calculating resolution by yourself. >.<

run...

using: pcsx2-r1593 all hacks off, mvu disabled(and enabled).

I'm getting the "m_merge is NULL" crash in vp2 w/ gsdx-r1591(dx9 hw)

but not with r1584(also dx9 hw).

WesandR...

As a guy said earlier - there's a problem with games crashing when interlacing is on while using a non-native resolution - Resident Evil Code Veronica X can't boot under these circumstances.

gabest11

I never boot games through the bios and they all still work, but I'll check.

andutrache

Yes some games crash with interlacing enabled on high native res (ex Popcap Games Vol 2 says m_merge is NULL and crashes). Also Naruto Accel 2 has a line at the bottom of the screen where it looks different and the ghosting effect is more visible now. I use 2048x1792 internal res.

Some screenies:

http://img139.imageshack.us/img139/7984/screenien.jpg

http://img265.imageshack.us/img265/1606/screenie2.jpg

All revs after this one have this problem (this one included).

Revision 1592

pcsx2: removed some msvc++ warnings from one of arcum42's cleanups

microVU: minor fixes.

The ps2's VUs (and FPU) pretty much always do sqrt(abs(x)) whenever doing

sqrt's.

SSE's sqrt will give you a NaN if x is negative instead, so force abs(x) before

doing sqrt (unless the value is known to be positive).

arcum42

Interesting thing is that while gcc may have lots of silly warnings that crop up, it doesn't seem to give warnings that require !!'s. As such, I'm not likely to notice when they're needed, unfortunately... :(

cottonvibes

yeah this is one of the cases msvc++ has given silly warnings that gcc was fine with lol

it was saying "performance warning", but it spammed it like 100 times for some reason xD

anyways it was fixed by just !!'ing the int expressions to convert to bool.

arcum42

Ironically, the cleanup started because I was getting tired of warnings gcc gives about doing (x >= 0) on unsigned variables all over that section.

I'll admit I'm still wondering about MMX_IS_GPR, tohugh.

MMX_IS_GPR was ((x >= MMX_GPR) && (x < MMX_GPR + 34).

In line 780 of iCore-32.cpp, which otherwise used IS_GPR, it used (mmxregs[mmxreg].reg >= MMX_GPR && mmxregs[mmxreg].reg < MMX_GPR+32)

This is *probably* supposed to be IS_GPR(mmxregs[mmxreg].reg), but I'm not sure if the 32 or the 34 is correct.

It's one of these cases where I just decided to leave that case the way it was, till I get a better handle on it. (though I adjusted it to remove the unneccessary check...)

arcum42

And, yeah, my spelling sucks in this comment. An edit button would be so useful... :)

Revision 1593

KiNGKiMO noticed a crash when specifying a iso filename in the cmdline, to make

pcsx2 auto-boot that file. I fixed that, and while I was at it, change the

bootmodes around.

The way it works now is:

- Base mode: 0=normal (cdvd plugin), 1=load elf, 2=use iso loader, 3=emulate no

disc

- Bios flag: 65536+base = mode startup through bios boot process. Default is to

skip bios.

So for example to load X.iso using the internal iso loader, and executing

through the bios, you would now do: pcsx2.exe -bootmode 65538 X.iso

This needs implementing in linux side, and maybe changing it so it's nicer user-

wise (for example, reading the number as HEX would make it 10002 instead of

65538).

ltrap...

BTW am I the only one with the process remaining in memory after closing program window sometimes?

ramapcsx2

Yes?

Are you sure you're closing it correctly? (IE: not just the gsdx window ;) )

Good work, giga :p

ltrap...

Yep. I am closing just the program even before loading GS.

ltrap...

*GSdx

There are no graphical window already but process still remains and eat up to 50% of first core time. It happens around on time in 3-5 program runs.

ramapcsx2

Yeah, and it doesn't happen to anyone else it seems.. :p

ltrap...

I am the Chosen One. ^___^"

heatbla...

Saw it. There is a huge frame skipping and the window cuts the game with black bar. Happened when I forgot MAKARON EMU opened. Noticed that VP2 is terribly skippy and ingame was lagged with that weird glitch of - half of the visible screen was cut and the other half was black. When I closed MAKARON it fixed PCSX2.

Good job!

kaboo...

er I have it too XD

but I am apperantly the only one who has the problem with the configuration data (the program "forgets" folder locations but remembers them If I start a new pcsx2 instance)

if I close pcsx2 I can still see it in the task manager and it uses 25% cpu exactly I have a quadcore AMD so it's one whole core

kaboo...

damn you google for not having an edit button!!!

it appeared a while ago (prolly with the folder forget thing together) but I thought it was my problem cause on my brothers pc there is no such problem -.-

heatbla...

hahah :")

ltrap...

OK. Submitted this as issue.

ramapcsx2

Ok, good :p

jrdavid3...

I used rev 1593 but it still impossible swap / change xenosaga episode III discs. There only logo appear where Shion ask you switch to Disk 2.No matter how you tryed logo still present and disc 2 does not boot. Same in different way when you start new game with disk 2 Shion appear and ask you swith to Disk 1, then i change disk 2 to disk 1 and nothing happen, logo still present and disk 1 does not boot.Same problem with Samurai Warriors 2 extreme legends then you try to transfer data from Samurai Warriors 2 Disc. It says "Data will be imported from the Samurai Warriors 2 disc.Proceed?", then you press yes there logo appear " Please open disc tray". I change SW2 xtreme legends disc to sw2 disc and nothig happen, data does not transfered and it seems that game freeze as it was in xenosaga episode III.

ramapcsx2

Don't these games offer to do a save before the "change disc screen"?

Do that save, mount disc2, and load the save from its menu.

Should let you continue then.

jrdavid3...

I know about it but i thought that swap discs may possible.

gigaherz

It should be possible, and in fact it works with some games. One way it might work, would be to escape from the game, choose File->Run BIOS, then let it emulate "no disc" for a few seconds, escape again, and load the new disc. But if the game needs to "think" the tray is open, then maybe the best option is to use cdvdGigaherz, which does emulate having the tray open when the drive reports access errors (when you have no disc, or the tray is open).

Still, not all of the CDVD drive commands are known, specially not all the commands in the security chip (mechacon) so it is possible games are requesting info about the drive's state in unknown ways.

kimoki...

This is KiNGKiMO, thank you so much gigaherz for the fix.. this is REALLY USEFUL.

I want to report 1 more thing regarding this too, I'm using "Esc Hack - Use Esc key to fully exit PCSX2." at Speed Hacks.. this isnt working with the fix, Pressing Esc Key doesnt close PCSX2 right away.

gigaherz

Hm nothing I changed should have affected it, kimo :/ With the wx branch so close to merging, I think it's not worth to waste time fixing that, given it will be useless later.

Revision 1594

Add the changes from r1593 to Linux.

Revision 1595

wxgui:

* finished most of the new plugin system (branch is buildable and runnable

again, but no significant functionality has been added yet).

* Removed STGS code from the branch since I planned to kill it off anyway and

it was more work to code proper support for it in wx than to remove it.

ramapcsx2

Haha, sneaky way to get rid of stgs.

Welcome back :p

kaboo...

stgs?

single-threaded-graphic-synthesizer?

ramapcsx2

yep

Jake.Stine

The MTGS will have a new synchronous mode, which will behave *almost* like the current STGS, except all GS activity will still pass through the MTGS ringbuffer. The mode will probably only be available in debug/devel builds since its only purpose will be for debugging stuff.

Jake.Stine

oops, haha. I noticed I made search/replace changes to Changelog.txt. I'll need to revert that. :p

RebelliousX

So with the new MTGS synch mode, will it affect frame skipping to be less

buggy?!

Jake.Stine

Yes, I have good plans in store for frameskipping.

Revision 1596

Zeropad/Win32: Make what appears to be a fairly significant bugfix, for what

it's worth.

Jake.Stine

Anyone even use this thing in windows anymore? Eh, whatever.. :p

arcum42

One or two, I think. Just enough to bug me when I make changes to it. I personally haven't seen it actually work in Windows since pre-0.9.4, IIRC, though.

In Linux, in the long term, I'll probably replace it with my Zeropad fork. Still have to re-port that to Windows one of these days.

ramapcsx2

No one uses this plugin in windows. There's no reason to, and all the alternatives are better.

Jake.Stine

Well if it hasn't worked, this bug might explain why. It looks to be important code and it was basically passing some uninitialized pointer to a Win32 API, so god knows what was happening as a result (likely a GPF).

anyways if it really doesn't work at all then I should prolly consider removing it from the pcsx2 solution and reducing plugin clutter.

arcum42

It works well enough in Linux, but, yeah, in Windows, I'd get rid of it. I get the feeling that Zero did a bunch of work on the Linux side, and never got around to fixing the Linux side back up afterwords.

And on the Linux side, hopefully my fork will supplant it eventually, when it's mature...

Revision 1597

GSdx: experimenting with msaa, add msaa=N to gsdx.ini to activate it (N=2,4,8)

ramapcsx2

It works :)

Some games take a huge speed hit, while not even looking better.

But some games got enhanced a LOT, and speed is the same :)

zantezuken

yays, AA via gsdx itself! Bored of driver settings :P

lessee...

Autor...

Oh god, AA in gsdx!

song...

great AA in gsdx, but when i tryed run Suikoden III whitout msaa black screen

gabest11

yea something is wrong with dx9

Autor...

Any other N-numbers or just 2,4,8?

gabest11

You can try any number :P dx9 up to 16, dx10/11 up to 32.

If I enumerate the modes only 2, 4 and 8 are supported on my 8600gt.

gabest11

If you give an unsupported sample count the next highest will be selected automatically.

Autor...

So it's up to my card and supported api, thanks

tiku...

I haven't tried this yet, but... the AA (at least set at 2) has no negative effect on the perfomance? It runs as fast as it were set to 0?

ntcong.it

It should have performace lost, compare to native res. But compare to a high internal res, I think AA will perform better

darkvalen21

Performs better in GOW 2 without the side effects of non-native resolution (i.e. ghosting). Very good work. We only need a hotkey to change and it would be perfect :)

necr...

Thank you! This is one of the last two 'changes' that I've been doing in my custom build.

Works great!

necr...

To be more specific with 'works great'-- playing Kingdom Hearts 2 at internal 1440x1080 w/ 4xAA on a 275GTX. No stutters now on very high-video demand sections whereas previously 2880x2160 would hiccup a bit when there was a lot to process in a cut-scene.

inte...

Using msaa with any value (except 0) the ghost effect from tales of abyss is gone!

great job :)

ltrap...

It looks not like true solution to the problem but it somehow works. So my gratitude to gabest also. :)

But in the tales of abyss I have one more problem:

http://img233.imageshack.us/img233/9281/gsdx20090803214202.jpg

Corresponding gs:

http://www.mediafire.com/file/xn1iizymmn0/gsdx_20090803214202.rar

Ghosting one:

http://img231.imageshack.us/img231/6042/gsdx20090803234036.jpg

Corresponding gs:

http://www.mediafire.com/file/dzdninxjzjc/gsdx_20090803234036.rar

PS: I tried to disable all speed-hacks this time. Even before making snapshot, because this game is truly capricious with them. Even a little acceleration cause all kinds of "Trap" and "TLB miss" errors.

kaboo...

really? 1.5X works fine I played it through with that also every speed hack in the middle section most of em are fine with almost any game Oo and they all work perfectly fine with ToA

the ghosting problem was never fixed was it? but msaa is a NICE workaround XD especially for me since I almost only play on native res XD I like the ps2 feeling it gives with msaa it's just smoother XD

ltrap...

Yeah. The middle section speedhacks almost certainly make the game unstable for me because of crashing after battles on random occasions.

guessous...

That's great, but I hope it will be supported through gsdx interface.

Having to edit an ini file, is not convenient.

ltrap...

And some irrelevant question to gabest - is Visual Studio 2010 really worth to try?

ltrap...

guessous: It was only try-out stage I seriously doubt that it'll be left as is if no critical problems occurs.

inte...

i talked too soon... msaa only fixes ghost effect under certain circumstances. when you change the screen (opening a menu or going elsewhere) the ghost effect comes back.

weird.

i'll try to reach gabest on forums.

Revision 1598

GSdx: fixed dx9 + msaa=0

Revision 1599

microVU:

- Normal Clamp Mode clamps a few more stuff (Fixes Ice Age 3 falling through

floor bug)

Revision 1600

GSdx: fixed the crash when booting through the bios

Revision 1601

memcpy on PcsxConfig made pcsx2 crash upon exiting, when the string members were

deallocated, I guess they were added later.

Jake.Stine

Oops, yeah that would have been my fault for adding strings. Tho admittedly it's a surprise why it ever used memcpy instead of a direct assignment in the first place... >_<

ltrap...

It's the case of killing two birds with one stone - you can close Issue 343 and probably Issue 341 . ^_^

zantezuken

Yeah, annoying crashes are fixed.

yays

kimoki...

Thank you gabest this was really annoying.

Revision 1602

wxgui: separated core emulation options from user interface options (mostly!

some interdependencies remain), and stripped out some of the old framelimiting

toggle/cycle code, which will be replaced with a better framelimiter system

soon.

Jake.Stine

... I wonder why my commits from my laptop put a bunch of extra linefeeds into the commit log. >_<

Revision 1603

wxgui: minor cleanups; renamed Utilities folder to Tools, to alleviate confusion

with the Common/Utilities.

Revision 1604

wxgui: maintenance sync with trunk.

Jake.Stine

Gone for another 5 days. Man I hope I have some serious progress made when I get back. Depends on if the weather co-operates or not.

Wagnar...

have a good time :)

Revision 1605

microVU: some optimizations...

Revision 1606

microVU: Removed the "Exiting from Possible Infinite Loop" logic from Release

builds, should be a small speedup.

Its still there in debug/devel builds, so we can easily tell if a game is

hanging on VU1.

ltrap...

It seems good.

But I believe if there are more of such optimizations it's better to group them with setting in the .ini file, DisableSafeChecks=0(1) or such for example. So users can restore the functionality if it's really needed but still able to disable it if not.

cottonvibes

well really this check shouldn't be needed if the recs are working properly (unless a game does something really weird).

i mostly just coded it for myself to find problematic games, and i originally included it in the release builds so normal users can report to me the problems.

at this point there are still a few games that get stuck in infinite loops, but i think its because i still need to implement a few stuff.

dozafix1992

I don't want to be like, you know, 'GT4' but you broke Champions RTA again.

But as long as my ps2 works, i can wait :)

cottonvibes

i know champions rta is broken, but it wasn't working correctly anyways.

i have a real fix planned eventually but the game is doing some very ugly stuff thats hard to emulate ><

Revision 1607

LilyPad: A number of small fixups.

DirectInput devices corresponding XInput devices should be listed as

"[Detached]" when XInput is enabled. No idea if this works, as it requires an

XBox 360 controller to fully test.

FF Axes now sorted, rather than being displayed in the order MS returns them.

Small motor DirectInput binding now correctly displays "Square" effect type in

list when first created.

Attempt to more accurately model "soft" vs "hard" presses. Don't have a game

where this matters, so no idea if it works.

azte...

"Attempt to more accurately model "soft" vs "hard" presses. Don't have a game where this matters, so no idea if it works."

soccer games like winning eleven/pro evolution soccer use this, thanks for this add-on mattmenke.

gawm...

Oi, would it be possbile for some ps2-like pads(f.e logitech rumblepad 2) to auto configure according to the orginal ps2 pad, just like dolphin does.

jfre1...

Rude to start a question with oi

Norikumi...

I have an x360 controller. Tell me what you're looking for specifically and I might be able to help.

Also, I know this isn't a support forum, but maybe you could provide an insight on what motor to use with the 360 controlller, and how many of them. Thanks.

mattme...

NorikumiSubs: When you have DirectInput and XInput both enabled, either the DirectInput device corresponding to the XBox 360 controller should disappear or you should see "[Detached]" before the name of the DirectInput device.

As for which is big and which is small, the first is the "left" motor, second is the "right" one. I believe left (first) should be set to big. Default motor setting when you create the FF bindings should be right for XInput, but if they're not, tell me, and I'll change them.

Norikumi...

Here's how it appears for me:

http://img29.imageshack.us/img29/9169/screenshot146g.jpg

http://img141.imageshack.us/img141/7/screenshot147s.jpg

And here's a little something taken from MS's page: "The left motor is the low-frequency rumble motor. The right motor is the high-frequency rumble motor."

Turning the Axis motors on/off seems to have the same effect with both big and small. By default, big motor is set to Axis 1: Slow, and small motor is set to Axis 2: Fast.

One problem i'm encountering in Persona 4 is that the UP and RIGHT axes of the left stick are somewhat limited, and the character is moving at slow speed. This may be because of either usage (though i've bought it a month ago) or calibration, but increasing the sensitivity manually yields proper behaviour (full speed movement of the character).

I don't know if the right stick has the same issues or not. (By the way, the 360 sticks and L2/R2 triggers have a 0-65535 range of sensitivity. This might be a problem since the sticks are extra sensitive, screwing up the MAX value.)

Oh and, to reply to this "Attempt to more accurately model "soft" vs "hard" presses. Don't have a game

where this matters, so no idea if it works." you could always use MGS2 for testing, because i remember it annoyed me when i played it on my PS2. If I recall correctly, the PS2 controller has 255 levels of sensitivity for the buttons.

mattme...

Oh, and gawmir7: Without a bunch of devices to test, I have no idea how common button numbering is, so I have absolutely no idea.

Norikumi...

On one other thing. Disabling the DirectInput in the General tab removes my x360 controller from the list, leaving me with 22 bindings. Removing XInput removes "XInput Pad 0" and leaves me with 4 bindings.

mattme...

NorikumiSubs: That's right...Slow/low frequency generally gives the bigger vibration, at least with my PS2 and RumblePad 2 controllers.

A lot of people have sensitivity issues with LilyPad and the XBox 360 controller. I suspect the controllers themselves are calibrated in a dramatically different way from PS2 and PC controllers, and also never/rarely return certain axes as fully down. Without my own Xbox controller, I can't really play with the calibration myself. Anybody with a controller and the necessary knowledge is welcome to play with it. All that matters is the two line function that matters is just "ShortToAxis(int v)" near the top of XInput.cpp. Current version uses no branches and all integer code to adjust the range from -32768 to 32767 to exactly match the range -65536 to 65536 (Adds 1 if above 2^14, and then doubles regardless. Sticking with all integer code doesn't really matter, as code is only called a couple hundred times a second or less). Larger/smaller values are allowed, so something as simple as just scaling might be fine, or might want to use some other function (Like * sqrt(abs(original value)/32767.0) or something).

I don't have MGS2. Tried the first one, wasn't impressed, never bothered to try the others. Also a bit of a pain, as it requires a pressure-sensitive source of input to work. Don't do anything fancy with standard buttons.

Thanks for the info on XBox 360 DirectInput controller behavior - that's exactly how things should be (Well, not sure about the binding counts, but removing the devices from the list is correct).

Norikumi...

Having DirectInput on and XInput off leaves me with this:

http://img259.imageshack.us/img259/1701/screenshot149q.jpg

Clearing and binding all buttons/sticks again works, but the sticks are so sensitive that they often rewrite themselves when I try to set the axes by moving them.

BUT with only XInput on, I CANNOT add Big/Small motors, as the buttons are greyed out.

Norikumi...

D'oh i blame the lack of an edit button. i mean that with XInput OFF i cannot add motors.

mattme...

That's because Microsoft's crippled DirectInput drivers for XBox 360 controllers don't support rumble, in an attempt to force developers to use XInput. For XBox controllers, you should probably be using XInput rather than DirectInput.

kaboo...

I think XInput is really nice except for the limitations...

and way more customer friendly the only really bad part is that atm only XBoX 360 controller are supported ... which is stupid cause they have the worst D-Pad since the original XBoX controller (oversensitive and not precise enough -.-)

mattme...

That's a huge limitation, and makes the entire thing useless on PC.

Fine for XBox-exclusive games, but for PC, just makes things even more complicated, as you now have to use *both* APIs if you want rumble on XBox 360 controllers and want to support general purpose USB devices.

mattme...

One other thing about the Xbox sensitivity: You could try going to the diagnostics screen and see what values you get when it's fully pressed.

Norikumi...

the only pressure-sensitive buttons on the 360 are L2 and R2. the D-pad does suck though.

kaboo...

@mattmenke yeah the problem is that so little gamepads actually feature XInput if only XBOX pads are usable then it's kind of pointless...

btw since XInput has the same binding for every controller (don't really know how to express myself there) why not make a "bind XInput controller button" since that is one of the actual improvements over direct input (or so at least I think^^)

mattme...

Too much effort. Might be tempted to spend time on it if I had one, but as it is, writing code which I can't run, or can only run after writing code to emulate a device I don't have, is painful.

Revision 1608

Worked for a bit on parseCommandLine in Elfheader.cpp.

arcum42

Basically, I added a bunch of comments, since I was working out how that function works with a mind towards rewriting it, pulled a commonly used conditional into a function, and likely fixed a bug or two.

Main one would be that it looked like it was starting out further then it should have when looping. At the very least, Champions: Return to Arms seems to have been picking up an erroneous argument from that, though I don't think it affected anything...

Revision 1609

After thinking about it, I'm reverting one of the changes I made in r1608 for

the moment, though I may rewrite the whole function in the future...

arcum42

It does subtract strlen(p) + 1 from args_ptr earlier, so I'm sure that's why it's in there. I hadn't noticed that previously...

Revision 1610

Here's a better bug fix for the issue that was bugging me in r1608.

arcum42

After r1609, I just suddenly realised that it was absolutely futile to be scanning over a whole bunch of space we already set to 0's anyways... :)

Revision 1611

GSdx: fix for transparent walls in kingdom hearts (or anything else that sets

AA1 with ABE off)

chane2k1

anything that fixes kingdom hearts is awesome.

heatbla...

LOL... I`ve played KH2 and KH COM a lot... haven`t noticed any bugs... with even 9xx revisions... and if I recall right even ot GSDX 875....

gabest11

It was a newly added bug :P

http://forums.pcsx2.net/thread-3031-post-67872.html#pid67872

ramapcsx2

Hmm, could you code this missing part Gabest?

//otherwise scale.x need to be reduced to make the larger texture fit (TODO)

I'm not quite sure if that's all that's needed, but some hacks showed improvement for these glitches in xenosaga3 or valkyrie profile 2.

(The brightening effect in xs3 and the fog in the forest in vp2)

It'd help if at least the bad texture size problem was out of the world :p

gabest11

I've only seen street fighter ex using that part, and even that is skipped because it is basically a blurring effect and not needed.

The real solution for such reinterpreted render targets (base address, pitch, pixel format may change) could be a similar page/block tracking system as the texture cache uses.

ramapcsx2

I just found out that at least vp2 doesn't even want to update the render target.

It looks like it's trying to update the depth stencil?

That part is labeled "Todo" right now :p

ramapcsx2

Ok, here's a .gs of "Tales of Crashia". The game got its name because it used to stall a pc to the point only a reset could fix it.

It's better nowadays, but still a memory hog. It also shows the bug I'm talking about nicely :p

http://www.sendspace.com/file/gqqqr4

bartlomi...

I have 2 problems with plugins since the beginning. One is missing parts of models especially in parts of ass :) )in db budokai tenkachi 3, and second is gray stripes (this is artifacts loking like the shadows) in the lotr third age. I see that performance is improved once again, and rest working near the perfect. One bug is that god of war loks crappy on non native res (when native res is disabled the main character is blurry and doubled). Kingdom hearts 2 looks and working avesome even in higher resolutions.

toast...

Sweet. I'm really impressed at how quickly that KH bug I reported was fixed. Nice work. ;)

Revision 1612

A few minor modifications to CDVD and IPU.

arcum42

Changes:

In CDVD, I changed it to explicitly put together the seek to sector and number of sectors from the parameters, rather then the ugly way it was doing it.

I changed a few areas to use a for loop, to make things a bit cleaner.

And I added a FIFOfrom_clear function, and have ipuSoftReset using that function, rather then clearing all the fifo output variables itself.

gigaherz

I fail to see how casting a pointer (which all it does is an unaligned memory access) is "ugly", and how reading 4 bytes separately, shifting them, and or'ing them is any better.

Unless you pretend to make this code compilable on big-endian machines... which would be pointless anyhow.

cottonvibes

yeh i also liked the old cdvd code better.

was easier to read IMO and faster :p

cottonvibes

although i would have used u32 instead of uint/int for the casting xD

arcum42

Eh, well, I probably just looked at it one too many times. I'd been trying to trace back the "Auron. Look!" crash...

If both of you prefer the old version of that code, I'll revert (and use u32s).

arcum42

Reverted.

Revision 1613

Revert the changes to CDVD, and clean up the changes I made to ElfHeader.cpp,

getting rid of some extraneous commented out test code, and refining the

comments I left a bit.

arcum42

Having comments explaining how the function worked was a good thing, but the ones I left were drowning out the actual code, so...

ntcong.it

only 1 spam comment :D, I want to say that, recently, I don't see any of your comment ended with "though..." :P

arcum42

I've been trying to cut back a bit on certain words I tend to overuse. And ellipses, too, but I use them so often, I have trouble trying to end a paragraph without them occasionally.

Silly, I know, but it's habit at this point.

Revision 1614

Workaround a problem with thread affinities.

Should fix some slowness issues, mainly on AMD cpus.

ramapcsx2

Note: I actually hated to change any code there, it was so tidy before :p

xat...

// (up to 25% faster on athlonx2, about 5% faster on core2)

In case there are those who don't look at the diff :p

nexxus86

25% faster on AMD X2? is that 100% sure?

will try because i have one since my E6700 broke...

yoshi...

"up to 25% faster" doesn't instantly mean "25% faster" .

also it seems linux is not affected :/

ramapcsx2

Linux never had that issue to begin with :p

Norikumi...

d'oh so my phenom won't receive boosts...

oh by the way, what's up with that bug that uses 100% of the first core?

ltrap...

Huh, it was around the time I was thinking about what's wrong with thread affinities also. O_O

Norikumi...

lol nevermind. i guess this fixed it.

mattme...

NorikumiSubs: Believe it was deliberate, actually, on the theory that running pcsx2 on one core/cpu and the GS on the second would give better cache performance. For games that are CPU-limited, this would result in 100% usage of the first core, rather than semi-randomly switching pcsx2 between cores. For whatever reason, this hurt performance drastically with Athlon XPs and a little on Core 2s.

My explanation could be wrong. Haven't been keeping up with the project lately.

KiNiO...

@mattmenke this is hitting also Core Duo and pentium D :-( On my core duo i dont remember game that won't be absorbing first core almost completle! 70-100% while second is on 2x - 60%.. this is waste of resources :-)

mattme...

In theory, it's not. If you have two cores, and two threads, one needing 100% CPU time of one core, and the other 60% of a core, it shouldn't matter if you run the 100% one on one core and the 60% one on the other, or let the OS decide what to do with them, and have them as a whole take up about 80% time of both cores.

In fact, all else being equal, if they don't share L1 cache (Or L2 cache), having them run on separate cores should well be marginally faster, for caching reasons.

I could see why this would be a problem for HT chips, but surprised it hurt performance so much in general.

gabest11

What if the OS puts other processes on the core that needs to run pcsx2 100%?

It could have run on the second core instead, but missed it, and now only gets "100% - X" of one single core.

mattme...

gabest: Indeed, and Windows kernel itself only runs on the first core, or at least it used to. Regardless, as there was a 25% X2-specific slowdown, that doesn't seem to be the main problem.

Norikumi...

before r1614, removing core 0 from affinity (and leaving cores 1, 2 and 3) didn't put 100% load on any of the other cores.

Jake.Stine

The Affinity change was implemented for CpuSpeed checking only. I coded it as according to MSDN docs and examples -- saving the current affinity when setting the new affinity, and then restoring once the CpuSpeed was calculated.

This apparently does not work on some AMDs though. So much for docs and examples. :p

ramapcsx2

Yeah, i saw that part but wasn't sure why it didn't work.

So I made another function to make sure it's unset.

Jake.Stine

Yeah according to the docs, just blindly setting an 0xffffffff mask is *supposed* to fail, and you're *supposed* to use some other function to query the valid affinity mask from Windows. But apparently AMD's cpu drivers don't bother with those rules and regulations :p

nokiaqdman

Thanks for AMD support :)

Revision 1615

microVU: extra + preserve sign clamp mode now semi-implemented (before it would

just do the same as 'normal' in mVU)

Autor...

Fixed some missed geometry in mVU1 in Naruto Shippuuden Narutimate Accel 2

i've reported before, fixed not by this commit but , thanks anyway

Autor...

still some little problems on MVU1 still reamains

pcsx2gu...

@ Heatblazer: Why are you using google code comments to report GSdx bugs, even in totally unrelated revisions?? Make an issue or report it on the GSdx thread in the forums. This is considered spam and will be deleted in the future.

cottonvibes: Good job, will test SPS games with it. Any word on when you will fully implement it? I guess it will be smarter to wait till then to test it :P

cottonvibes

its possible that this fixes some sps games, but yeh probably best to wait till i fully implement it.

i'll probably get to it sometime within 1~2 weeks when i'm bored xD

Dhalai.L...

Happy Birthday Vibes Cotton !

cottonvibes

heh thanks xD

Revision 1616

Fixes for ICC compilation errors ( Issue 350 )

Supe...

I remembered for earlier revisions I can only compile ZeroGS with ICC(11.1.035), pcsx2.exe definitely cannot be compiled.

now all sorts of 18 projects except setup can all be compiled with latest version(11.1.038) of ICC?

I haven't tried it out, currently ICC removed from Windows.

nstorm...

I failed to compile GSDX with recent revisions. Gabest wrote on forums:

"intel's compiler produces horribly slow gsdx, icc<vc9<vc10 (when I last checked it, it could not optimize sse intrinsics very well, that could be to reason)"

I wonder how ICC will affect emulator performance, going to test tomorrow.

gabest11

Compiled gsdx with icc about a month ago.

fuujin.s...

Tried compiling with ICC11, pcsx2 hangs with a black GS screen when starting any game or bios, without any error messages. Debug build worked though, maybe I did something wrong.

nstorm...

I succesfully compiled PCSX2 (but not plugins) with ICC11 and it runs bios just fine.

bharav...

Well, for now I can compile with ICC11 all that I need except gsdx. All dependencies (SoundTouch, pthreads etc.), PCSX2 itself and SPU2-X.

And there is GREAT boost on performance.

Just for example: it allows to use quad-core CPU (not SO effective as manual parallelisation, but... better, than nothing).

And it gives more fps on 2 cores too (for Intel CPUs, at least; not sure about AMD).

I have no additional bugs with ICC-compiled builds.

zantezuken

>> And there is GREAT boost on performance.

OH REALLY

How much great?

How did you test it? Which settings? Do you use native/simple gfx settings for best result?

Where do you test it? BIOS/Disgaea, lol? Try GoW2/Tekken5/FF12/GT4.

Provide some statistic.

bharav...

"Great", of course, differs from man to man. :)

But just for example, God of War 2 (approximately, of course):

Default compile - 31-38 fps, 34fps for 70% of the time in first room (after you kill all enemies).

ICC compile - 33-42 fps, 39 fps for 70% of the time.

My settings a bit agressive:

http://img156.imageshack.us/img156/1521/clipboard01p.png

http://img218.imageshack.us/img218/3189/clipboard02juw.png

http://img218.imageshack.us/img218/1843/clipboard03y.png

But the same tendency with lower resolutions.

Revision 1617

vs2010 project files for pcsx2 (plugins later)

Supe...

Yay, so we will entirely ditch VS2008(SP1) and stay with VS2010 beta 1 eventually right?

I'm looking forward to it.

kaboo...

hmm when that time comes it's probably not beta anymore Oo

nov...

That means I'll have to download the massive 500+MB Visual Studio 2010 redis package to be able to use PCSX2...well I won't be downloading that I'm affraid

Great, just great.

Not happy... :l

refraction

novax9: I doubt when the time comes you will need to get the 500mb package at all. The program is still in beta, so i imagine a lot of that contains updates and changes that are required that havent been released yet. For example there may be some beta .NET updates which have yet to be released by windows update.

Just wait instead of getting grumpy. Anyway, nobody said we were ditching VS2008 yet, only somebody who isnt part of the team and has no say in the matter.

nefer...

so far the redistributable necessary to is 4.4mb, where did you get the 500mb from Oo

zantezuken

I can't compile GSdx with msvc2008 anymore!!11111oneonone

noez :O

:D

Jake.Stine

We will only "discontinue" VS2008 support if/when VS2010 Express is released, at which point there would be a freely available compiler supporting the 2010 project files. Until such time, 2008 will be the compiler of choice for building the win32 projects.

Furthermore, when the wx branch is soon finished, people will be able to use Code::Blocks for Win32 if they so please, and compile pcsx2 with MSVC compilers from 2005, 2008, or (I think) mingw. Code::Blocks supports all of them.

(that won't apply to GSdx tho, for a while, since it still has about 2.5k lines of code that gcc considers invalid C++ :p)

gabest11

I'm not familiar with gcc, but if it can use the libs from directx sdk then we could try fixing up those remaining incompatiblities.

Someone needs to guide me how to setup the environment :P

Jake:

Any hope to get faster compilation times for pcsx2? About 20 minutes on the server where I do the auto-builds.

2010 can compile files parallel (not just independend projects), but with whole program optimization important things happen when linking, and that's still single threaded :(

Jake.Stine

Gabest: 80% of LTCG slowness is caused by microVU. The other 20% is the new emitter. In mVU it seems to be two or three specific parts of the code that give MSVC's linker so much grief. They're hard to fix though -- when I fixed the problem by limiting some of the inlining and templating it caused a 1-4% performance drop in many games.

Norikumi...

I just tried vc2010 beta 1 and it blows. I'm not gonna use that POS for now.

Revision 1618

missing project files

Revision 1619

doh, so many missing files

Revision 1620

forgot to set function level linking..., that trims more unused code and dlls

deps, any good revision number ahead to reach? :D

Revision 1621

microVU:

- Cleaned up microVU_Compile

- Added file microVU_Branch

gianluso...

when the pcsx2, may use 100% of the quad-core processors?

gabest11

run it twice :D

electric...

:D

nexxus86

i don't think PCSX2 will ever use 100% of 4 Cores.

you can be lucky when the VU's are splitable to two cores like:

core1:EE rec/IOP rec/SPU2 | Core2:VU0 rec | Core3:VU1 rec | Core4:GS

but is it worth or even possible to split up both VU's?

mattme...

If you just add the following code to the right places, PCSX2 will always use 100% CPU time on quad core systems, even when you're just configuring plugins!

DWORD WINAPI Use100PercentCPUTTime(void *junk) {

while(1);

}

for (int i=0;i<4;i++) CreateThread(0, 0, Use100PercentCPUTTime, 0, 0, 0);

gabest11

you are doing it WRONG!

while(1) _mm_pause();

Revision 1622

Added some tag code in I was fiddling with. (Nothing uses it yet. I mainly

wanted a backup of what I was working on.)

Revision 1623

Link in Tags.h, use one of my new enums in various places, and move some code in

IPU.h to a new function of it's own.

arcum42

If the code I'm modifying seems like a bunch of variations on the same code, there's a reason for that. And that's a lot of why I'm looking at it...

Revision 1624

wxgui:

* Major cleanups and improvements to the Threading namespace.

* Created CoreEmuThread class framework, which currently runs the EEcore, IOP,

and VUs with threadsafe suspension, reset, and resume features.

Revision 1625

A bunch of IPU.cpp now uses Tags.h. Ironed out a few things in Tags.h.

arcum42

Hmmm... Noticed a silly mistake in here that makes no difference to the running of pcsx2. Some of my functions are misnamed. The only two times I used them, I was looking at the code and not the name, so didn't notice. :)

Revision 1626

Disable vsync when going from "limit" to "skip" framelimit mode.

nexxus86

doesn't GSdx use the display drivers own vsync or does it have an own vsync?

ramapcsx2

GSdx asks the driver to enable / disable vsync.

Revision 1627

Fix a silly mistake I made in naming functions in Tags.h.

arcum42

Surprised I didn't catch this when I made the IPU changes, but it was pretty much the last ones I made.

Oh well, at least I was looking at the code, not the function names when making the changes. :)

Added some comments to Tags.h, too, so it's easy to tell what the different flags are for.

kojikni...

Using Visual Studio 2008 I post quite a few warnings from this change.

"warning C4800: 'u32' : forcing values to bool 'true' or 'false' (performance warning)"

I receive approximately 10 of these warnings the lines in question are 121, 126, 134, and 137 all are in Tags.h

The file still compiles fine, and I don't seem to have any noticable performance hits, I figured I'd report this either way.

Revision 1628

wxgui: Begin work on some missing panels for the pcsx2 config dialog.

Makotech...

i forget, wasnt someone on vacation, the person who did the wxgui stuff?

max...

Hi Jake errors report

http://img18.imageshack.us/img18/7162/pcsx2wguierror.jpg

Jake.Stine

@maximu: thanks. Those errors are actually harmless, didn't know wx would report them. I'll see if I can't disable or avoid them somehow.

Revision 1629

microVU: minor changes

Revision 1630

microVU: Implemented some undocumented stuff which lets Champions Return to Arms

get in-game.

The game still looks ugly, I'm not sure if its problems are gsdx or pcsx2.

zeroGS just renders a black screen which it no help xD

Note: I still need to optimize this fix.

azte...

dont worry about return to arms: afaik the games related to everquest are ugly anyway. ;)

cottonvibes

heh well, the game was doing some tricky stuff which i wanted to emulate properly.

This fix could help some other game work, but i don't think it'll help that much games (its a very rare case)

cottonvibes

seems somewhere along the lines i've broken SO3.

not sure which revision, i'll be checking that soon.

cottonvibes

k it was this revision that broke it ><

i'll be checking to see whats bugged.

jfre1...

If the problem is a split screen issue, then thats an issue that affects several games and not just Return to Arms. Baldurs Gate Dark Alliance and 2 are also affected by this same issue.

jfre1...

They are all affected by this, as they all use the Dark Alliance engine to my knowledge.

cottonvibes

the split screen is fixed with SW rendering.

but there is in-game graphical corruption, most likely caused by vif, vu, or gs.

not sure which is responsible.

arcum42

Yeah, same goes for the original "Champions of Norrath"...

dozafix1992

Finally i had some time to compile and run it.

I would like to thank you for the awesome work you did :).

dint...

Champions are still not emulated?

What should I do, that would be comfortable playing together?

Warrior1...

2 years are gone and this game still don´t work can someone look at this game

please

Revision 1631

microVU: minor cleanups

Line...

Thanks again Cotton, for your increddible work in this project !!!

Revision 1632

microVU:

- Fixed a bug from r1630 (it was breaking SO3 and probably some other games)

Revision 1633

pcsx2: fixed some msvc++ compiler warnings

Revision 1634

wxgui:

* Removed some erroneous language error messages during first-time startup on

non-english systems.

* Cleaned up BIOS code a bit and moved all the scatterings from Memory.cpp,

Misc.cpp, etc. into a single BiosTools.cpp file.

* Implemented BIOS selector in the config dialog.

max...

Nice job

Error Pcsx2 COnfiguration ussing option documents (Recomended) Can not enumerate files in directory \documents\pcsx2\bios

Folder Bios Not exist on the rute

--------------

Other minor error explication select on the configuration EE cyclerate and vu cycle not change descriptation .

Revision 1635

GSdx:

Re-enabled capturing via F12 key. It was missing the callback entirely.

The videos I capture here turn out all blueish though. No idea why :p

nefer...

Seems to be confussing red and blue colors, otherwise it works again thank you :P

ramapcsx2

Yeah, as I said. I have no idea whats up with that :p

ramapcsx2

fixed :)

guessous...

Remark: it would be nice if all shortcut used by pcsx2 were systematically

documented on a help file.

Also maybe an "api", or interface to handle all kind of shortcuts, would be interesting. This way the user could assign to each shortcut a function.

And if there's a conflict (for instance the esc key is used differently by plugins & pcsx2), then it could be easily managed.

My 0.05$

ramapcsx2

Yeah, it'd be nice to consolidate this stuff a bit more.

On the other hand, we all kinda know which keys are free and which aren't :p

Revision 1636

GSdx: Fix for the bad colors when capturing.

juz...

is it just me, or does this look bit hackish fix.

bool IsRBSwapped() {return m_rbswapped;}

m_capture.DeliverFrame(m.bits, m.pitch, m_dev->IsRBSwapped());

STDMETHODIMP DeliverFrame(const void* bits, int pitch, bool rgba)

Isn't RGBA totally different thing than rbswapped? Isn't rbswapped BGR color. So are we getting wanted result by accident? :)

juz...

wish there were edit button...

My knowledge isn't enough to understand all stuff that happens inside "STDMETHODIMP DeliverFrame(const void* bits, int pitch, bool rgba)" so might just be bit confusing naming of variables too.

Anyways nice to see this fixed

gabest11

dx9 has bgra all others rgba, by default it should be false and set to true in the constructor of GSDevice9.

Going to check recording.

gabest11

yea, IsRGBASwapped was called something else before, with a complete opposite meaning, I forgot about DeliverFrame when renamed.

juz...

ah. That dx9 explains the swapping. Thanks for explaining and fixing it in next commit :)

Revision 1637

GSdx: corrected recording code.

ramapcsx2

Ok, I'd never thought of doing it this way.

Thanks for fixing this up :)

nexxus86

is it faster than recording with fraps? any way to get spu2 recording synced to this?

ramapcsx2

When using spu2-x, you get a perfectly fine audio stream.

You just need to mux the stream with the video, and speed the video up to 60fps.

I use virtual dub mod for this :p

2nats...

How I can download this pluigins pls helpppp mee

Revision 1638

Converted VifDma.cpp over to using Tags.h. Worked some more on straightening out

Tags.h.

Revision 1639

Minor correction to the last revision.

Alucard2...

I do not know since this version or from version 1638 but now game Growlanser Generations and Growlanser The Dual Darkness do not freeze when the protagonist gets to casual battle. Thanks!!! Also excuse for my bad English. :)

ntcong.it

Why msvc is so stupid, and warning about return bool as int.

Fixing it by adding "!!" made the code a little stupid too :P

Revision 1640

Improved the safe_delete / safe_free macros to avoid potential block scoping

pitfalls, and fixed what looks to have been a minor typo in Tags.h :)

arcum42

Thanks.

Put that function in for completeness, and I'm not sure if I'll use it. But, yeah, I did a quick copy and paste, and forgot to remove the extra equals sign...

gabest11

Funny that only the guaranteed to check for NULL deletes are double checked.

Jake.Stine

Eh, figures. The first online source I checked for it (which was a few months ago) said that checking for NULL is recommended prior to delete because some compiler implementations may not check. But everything else I check says otherwise.

Also, free double checks too, in that code, not 'just' delete. I've had problems in the past with various ansi c implementations that didn't do null checks on free (Watcom, borland, early GCCs, etc). I *think* everything does nowdays, but eh. It's not really a defined standard so I'm playing safe.

Revision 1641

microVU: Fixed a case where a cached microProgram was killed but was still being

used...

This fixes Suikoden III hanging/infinite loop problems, and possibly some other

games...

Revision 1642

microVU: Now prints some more Warnings to the console when unimplemented

features are happening.

Revision 1643

Removed duplicate null checks on safe_delete.

Revision 1644

Fix a foopah, and get rid of the useless imdct warning.

Revision 1645

Changed the MFIFO test and message because it spams too much now that it

actually does what it said it did before. Fixes the FFXII opening.

arcum42

That's what I get for changing the test to match what the message said it did. There are three modes the ps2 is supposed to use, based on 2 bits. 00 = normal, 01 = chain, and 10 = interleave. So the test that was there tested the second bit to see if it was chain mode or not.

I changed to print the message that it's not chain mode if the two bits aren't 01. Turns out the two bits are set to 11 in ffxii's opening. :)

Revision 1646

Convert Sif.cpp & Vif.cpp to use the Tags.h code.

Revision 1647

microVU: Now properly supports E-bit set on branch delay slot instructions.

(Gets rid of "Unknown Micro VU opcode called" errors in Dark Cloud 2, and

possibly fixes some other games)

240...

Def Jam Fight For New York now freezes as Loading screen (after character select). For previous revisions, it crashes directly :)

redshado...

Since ferrarinews doesn't spam for a long time, could you guy's fix gt4?

u034...

I got it,

redshadowfoxdie is ferrarinews's new neckname ...

I am joking ...

redshado...

nope, my nickname usually is mytik, this is my default email address :)

gabest11

nonono, before gt4 I suggest burnout 3 to be fixed

kaboo...

agreed BO3 is way more fun^^

jfre1...

Yes pls fix GT4. For the love of god.

And the sps issues in Ghost Hunter.

ramapcsx2

And the missing fmv in rules of rose in gsdx hardware.

ramapcsx2

And Fatal Frame 2 and 3 please!

resident...

Champions return to arms should be fixed too

no problem right? :)

ramapcsx2

No, since it's wishes day. Just add to the list of games you want fixed :p

gpoet...

No No No. I demand that Super Raibown Tea party 2000 is 100% functional before any other game that exist or will exist in the future is fixed.

kristel...

I want to play at Summoner 2! (freezing)

and "Gauntlet: Seven Sorrows" in hardware mode (as you know - it broken)

and clean "shadows" in Soul Calibur 3

please-please, oh-h... ,-) Please?

eve...

And pls fix shadows in Ico and Shadows of the Colossus in HW on GSDX ;)

ramapcsx2

Sorry cotton :p

Autor...

Just wanna ask, whak does mean VU0 perma-stall breaking execution...

messages after all?

ramapcsx2

It means vu0 is spinning (in c this would be simelar to while(1) ), and we stop running it (breaking).

jfre1...

Oh and since Summoner was mentioned, fix the mega slowness in that game :p. Easily one of the slowest games in pcsx2 for me.

mattme...

Also fix Duck Hunt. There's no reason Pcsx2 shouldn't be able to support SNES games and lightguns. The PS2 is faster than the SNES, afterall. And I want power glove support, dangit! Get on it, you lazy pad plugin authors!

kaboo...

errr... mattmenke.... aren't YOU a padplugin author......

mattme...

Hmm....now that you mention it... No wonder those pad plugin authors are so lazy... I demand I get right on it!

Dhalai.L...

Yeah, it's about time we could enjoy fatal Frame 2 and 3 on Pcsx2 =P

dint...

Champions are still not emulated?

What should I do, that would be comfortable playing together?

muko1...

Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)

muko1...

Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)

muko1...

Def Jam, New York için Fight şimdi (karakter seçtikten sonra) ekran Loading olarak donuyor. önceki revizyonları için doğrudan çöküyor:)

muko1...

Def Jam Fight For New York now freezes as Loading screen (after character select). For previous revisions, it crashes directly :)

Revision 1648

And we can add Gif.cpp to the list of files now using Tags.h

arcum42

If anything breaks, line 188 and line 289 are the main ones that would have slightly different behavior.

Line 188 can be changed back by changing it to

if (!(Tag::SafeTransfer("Gif", gif, ptag))) return false;

and

if (((CHCR::MOD(gif) == CHAIN_MODE) || (CHCR::MOD(gif) == UNDEFINED_MODE)) && (gspath3done == 0)) // Chain Mode

Is closer to how the old version of 289 worked.

Doubt either will be an issue, though.

arcum42

Never mind on 289. Looked closer, and what I did actually was the old behavior. :)

ramapcsx2

Testing all these changes along with my own stuff, so far its looking good :)

arcum42

Glad to hear it. :)

I've been trying to commit these changes in manageable chunks, because while a lot of the changes are straightforward, and shouldn't cause issues, occasionally I've been doing things like change code to what the comments say it did, when what it actually did was slightly different.

I like this so far, though. I think these changes improve readability, and also reduce the chances of mistakes in the code. And if we want to change how tags are handled at some point in the future, it should be a lot easier.

And I'm still surprised to find out that there is a 4th, undocumented mode besides normal, chain, and interlaced. Either that or both bits get set by accident on occasion. :)

ramapcsx2

Hmm, might be some sloppy code or whatever, that left the 2 bits low.

If it can happen on the hardware, I guess it's best to assume it will :p

Btw, we're planning a unified dma controller for the ee and iop sometime.

Chances are most of the dma code will have to go then.

No schedule for that though, it may take a long time yet.. :p

arcum42

I see what you mean. I'll have to confirm it with less hacked code, but I just found a case where ASR0 & 1 are both set in hwDmacSrcChainWithStack in the RET handling. It gets treated as if there are no addresses in the current code. (May have to fiddle with that; wonder if that's right?)

That's when you press start in Star Ocean 3, btw. It might act differently in Windows, given that there's a weird platform difference on that game anyways.

And no problem about the dma code going at some point. I may as well keep changing it when doing my changes in other areas of the code. It'll still be useful as reference code...

arcum42

May actually be a bug in my code on that one. I'll play with it more...

arcum42

Yeah, it was. Good thing I hadn't actually used that function in the code yet. :)

ninos.de...

tried to play Final Fantasy X-2 on rev 1653 (built by gabest) i noticed that yuna was running really funny like a meter would require 10steps when running like a cartoon :p

Figured i should try to see when it began and slowly tested previous revs by gabest and the weird run bug appeared on this revision 1648.

The issue shows it self on the bridge of the ship.

Hoped this helped and thx for a super emulator.

cottonvibes

arcum42:

This revision breaks Tekken 5.

After the intro, you just get a black screen.

I also tried the 2 line changes you mentioned:

if (!(Tag::SafeTransfer("Gif", gif, ptag))) return false;

and

if (((CHCR::MOD(gif) == CHAIN_MODE) || (CHCR::MOD(gif) == UNDEFINED_MODE)) && (gspath3done == 0)) // Chain Mode

They don't fix the problem.

arcum42

I rather gathered. See r1657.

cottonvibes

sorry about that, i thought i was updated to latest revision when i noticed the problem.

so i reverted until i found out this revision was the originator of it.

its indeed fixed in r1657

arcum42

No problem.

I'm starting to think I should buy Tekken 5 for testing despite not really being interested in it as a game...

Revision 1649

wxgui: All kinds of mess, but still not up to running games yet.

* Borrowed wxScopedPtr from wxWidgets 2.9

* Fixed up first-time startup procedures and folder selection

* Implemented most of the rest of the missing configuration options, and

cleaned up some ambiguities regarding bool types and bitfields.

kaboo...

big plusssssss!

sounds like not as much left as I thought^^

max...

Problem configuration folder

http://img268.imageshack.us/img268/8269/pcsx2configurationerror.jpg

Revision 1650

GSdx:

Initial pixel offsetting support via gsdx.ini.

Use pixoff_x = somevalue and pixoff_y = somevalue.

This can be used as a workaround for the various upscaling errors :)

Try these values for Takes of the Abyss for example:

pixoff_x=-8

pixoff_y=-8

ramapcsx2

Tales.. Ah well :p

xat...

Ah, this is the hack that you've been working on for a while? :p

kaboo...

for me it's

pixoff_x=-1

pixoff_y=-2

for TOA though the effect seems kind of pixelated (idk if that's even a word XD)

even though this is great 20 gazillion plussssssss

ramapcsx2

Yeah, this is part of the stuff I tried to workaround the upscaling problems :p

kabooz_k:

The values change depending on how you set the D3D res.

Makotech...

Is this to fix the sort of clone-shadowy type effect on ToA, and perhaps .hack?

Xeli...

Could this affect Shadow Hearts at all?

RebelliousX

Silly question, can we use floating point for the offset values..?

ATi cards will benefit from this afaik.. +1 for the effort..

RebelliousX

nevermind I see that you declared them as integers :p sorry..

nexxus86

works with god of war too?

ramapcsx2

No floats for that, sorry.

And yeah, it works on shadow of the colossus :)

ramapcsx2

Eh, I meant god of war. But it'll work on both games :p

ltrap...

It's better than nothing but not a perfect solution. (For example in SO3 it shows graphical garbage at the side of screen opposite to the shifting direction. =_=)

xat...

Is there no way to algorithmically determine the offsets based on internal res? The way the commit summary is worded, this is customized more on a per-game basis rather than a resolution basis.

ramapcsx2

Sure, this can be computed based on internal res. The thing is, this is indeed a game specific setting.

Autor...

funtastic work, GoW2 NTSC fixes with

x=-8

y=-4

kaboo...

but a good idea could be automaticly turning it of when native is checked Oo

ramapcsx2

Yeah, of course.

Also, it'd be way better if I knew which textures to offset, and which to leave alone.

Unfortunately I don't.

Hope Gabest can help :p

DKTron...

Why did it work ok in r1584 and before ?

Whats changed that now requires this workaround ?

xat...

I see :p

What about something like selectively upscaling everything except those layers which would otherwise be distorted due to upscale?

kaboo...

DKTronics... what are you talking about?

this effect never worked with custom res afaik

it was deactivated in r1354

but this workaround is the best tackle to the prob yet

lecskov...

AAAH this is really cool! made me really happy! Finally shadow of the colossus's fairy shading is in place.

DKTron...

Sorry guys, I didn't read the thread properly, I thought this was the same as this problem mentioned here

http://forums.pcsx2.net/thread-3031-post-67406.html#pid67406

I apologise, sorry, I've just been dying to test the newer builds, but keep getting that shifted image in games like ICO.

krazytru...

Rama, what settings did you use for Shadow of the Colossus?

hmao...

I get rid of blurry battle graphics in FFX with x=-34,y=-34, but with those settings I got 34 pixel width blinking borders on top and left side of the screen.

Screenshot:

http://foto.rambler.ru/users/hmao666/_photos/FFX/?res=upload_ok#

hmao...

I think of for image cropping settings like Pete's OGL graphics plugin for Psone EMUs does.

ramapcsx2

The amount to shift depends on the D3D internal resolution you set.

If you need to offset by 34 pixels, then the internal res must be way too high..

krazytrumpeter05:

Same thing really, it depends on what D3D internal res you use. Try -8 for both.

krazytru...

Well, I was just doing a double of the native resolution. Went from 512x448 to 1024x896. Is there a way to calculate or have a general rule as to what your offset needs to be?

I also noticed that using offset settings brought back the overbloom effect even with higher resolutions. Looks like I'll have to choose one or the other for Shadow of the Colossus.

keb...

this is one of those things that will work perfectly on the wiki, the wiki could even have a simple calculator where you introduce your internal resolution and it returns the proper shifting values for each game that needs it

Revision 1651

microVU: minor changes...

Revision 1652

microVU: 70% implemented Branch in Branch Delay Slots. Hopefully I'll finish

tomorrow.

Compare Star Ocean 3 intro with mVU vs sVU, and you can see mVU now correctly

renders the title menu/new game startup screen =)

Saif...

Using microVU for MGS2 solves the missing graphics geometry...

ramapcsx2

Great, it also fixes a problem in valkyrie profile 2 (the extra map for shortcuts, when you press circle on the world map).

ramapcsx2

void condEvilBranch(mV, int JMPcc)

xD

240...

This revision bugs Def Jam Fight For NY. Before the game goes into character select screen and only freezes after that (I already reported this)

Now all we get is a BLACK screen right at the beginning

Some things I saw:

------------

Channel 2 DMA is stopped and reached END tag

VIF1: interrupted

VIF1: interrupted stall in effect

VIF1: decoding VIF data

VIF1: LAST VIF code was 80000000

GIF: Intermittent mode

GIF: temporary stop

GIF: IDLE STATE

GIF: transferring from EE to GS

GIF: transferring from VU address 0x0 REGS 0x0 Loopcount 0

ramapcsx2

Is there any message about a branch in delay slot?

240...

Sorry no!

Actually, I missed out a revision - r1648. And it looks like that's the one which caused the problem as it concerns with Tags and Gif (as the command showed). I will revert and test it

Sorry cotton! :)

saku...

good job, cotton.

but Dynasty warrior 5 SPS still remains.

Revision 1653

Tags.h meets SPR.cpp. Plus some more work on Tags.h and Misc...

arcum42

Just as a note; functions in the namespace D_CTRL are not ready to be used yet. They are just stubbed out, and would in fact not return correct values at the moment.

Revision 1654

microVU: Finished properly supporting branch in branch delay slots.

nuku...

yay! 'finished' is always a good word. so what is left on microvu?

qqqq.2...

r1653 is stable

r1654 (this version)application crash!!

qqqq.2...

I have try DEVEL profile.

seem working OK,

but SSE2 profile, application crash....

cottonvibes

qqqq.2005:

there's some ugly IPU code that randomly causes crashes when other parts of the emulator are changed.

i'll see if i can can hack-fix it; but for now the DEVEL build should work fine :D

ltrap...

isEvilBlock, XD I presume next will be: isGoodBadOrUgly

kaboo...

prolly more increasing connotation like evil -> demonic -> Diabolic

Autor...

badBranch, EvilBranch lol

fajar.nu...

Naming is hard, but it doesn't mean that it can't be fun :P

Revision 1655

pcsx2: removed some warnings from the new dma tag code.

cottonvibes

i meant msvc++ warnings ><

Arcum42:

I think i fixed some typos in tags.h, not entirely sure if thats what you wanted so check it just-incase :D

qqqq.2...

still application crash when Run (including BIOS/CD/DVD...)

Problem signature:

Problem Event Name: APPCRASH

Application Name: pcsx2.exe

Application Version: 0.0.0.0

Application Timestamp: 4a8cbd1d

Fault Module Name: pcsx2.exe

Fault Module Version: 0.0.0.0

Fault Module Timestamp: 4a8cbd1d

Exception Code: c0000005

Exception Offset: 0019979c

OS Version: 6.1.7600.2.0.0.256.1

Locale ID: 1033

Additional Information 1: 0a9e

Additional Information 2: 0a9e372d3b4ad19135b953a78882e789

Additional Information 3: 0a9e

Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

PCSX2 Log:

Initialize VU0....

Initialize VIF0....

Initialize IPU...

than crash

compiler by VS2008 Team Suite.

Help!!! back to r1653

qqqq.2...

I have try reompiler to DEVEL profile,

it's work!!!

but SSE2 profile, application crash...why

cottonvibes

qqqq: check my comment on r1654

ramapcsx2

Gha, how annoying.

arcum42

Yeah, I'd just quickly sketched out those functions, and since I wasn't using them yet, hadn't really gone over them to make sure they actually did what they said they did.

I'd actually already straightened out most of the typos before leaving for work, actually, because I'd started to use one of those functions, but hadn't had time to commit yet.

That's definitely what I'd meant to put in there, though. Thanks!

Now I can concentrate on the issue with r1648. Think I know what caused that, but I'll have to test things...

Revision 1656

Disabled precompiled headers for release builds. This fixes the random crash

introduced 2 revisions ago (caused by some crappy IPU code we need to eventually

get rid of)

Since the IPU code randomly works/breaks with different changes to pcsx2,

eventually we'll be able to re-enable PCH.

qqqq.2...

THANKS!!!!

release SSE2 profile working again~~~

ramapcsx2

Hehe, magical voodoofix time again :p

Castrat...

Just curious, I've been compiling pcsx2 using the 2010 project file provided by Gabest a few revisions ago and have not experienced this problem. However, I notice most revisions only update the 2008 file. Am I missing out on any potential fixes if I continue to compile using 2010?

Revision 1657

Tags.h: 0x8000000 != 0x80000000.

arcum42

Gah. Simple arithmetic.

I'm starting to get irritated with how many typos I seem to be letting slip through...

arcum42

In any case, this fixes the timeout errors in the beginning of FFX-2. Wouldn't be surprised if it fixed the rest of r1648's issues, too.

pcsx2gu...

Nice catch arcum, also fixes Tekken 5 ;)

arcum42

Thanks.

I thought it probably did. I couldn't verify since I don't have a copy, though. I've thought about buying it before simply for testing purposes, sadly. :)

I really would think that having what would amount to random values in the Irq flag would break more then it did. :)

Oh, and I wouldn't have made that mistake if I'd started with any file other then IPU.cpp...

cottonvibes

this fixed tekken 5's black screen/hanging after intro.

Revision 1658

wxgui: Fixed most of the trivial bugs from the prev commit.

* Removed NoncopyableObject class and replaced it with a

DeclareNoncopyableObject() macro -- which reports saner C++ compilation errors

when the object copy is attempted.

* Improved first run wizard and several configuration panels.

* Moved the BIOS selector to its own menu item and dialog box, separate of the

Settings panel.

* Fixed various bugs preventing configuration changes from being saved.

max...

nice Job :)

Revision 1659

Correct fix for thread affinity in CpuDetect, and fixed commenting in

clean_msvc.cmd

Jake.Stine

This revision *should* finally fix this problem, without a need for the hacky forced-fix. Everyone check your cpu readouts and make sure things aren't locked back on Core 0 again or whatever :p

krazytru...

Works just fine here for me.

Revision 1660

wxgui: sync with trunk (boooring)

Revision 1661

wxgui: The Linux side compiles and runs again. Note: Removed "Open in Explorer"

buttons for folders since there seems no reliable way to do that in Linux.

Jake.Stine

In this revision I also fixed/streamlined a few things I noticed, such as using SetSizer instead of SetSizerAndFit for panels. (The latter is intended for top level windows only)

Jake.Stine

Now I can get back to trying to get a game running... :)

arcum42

And now I can actually test it... :)

Revision 1662

microVU: Changed some VU0 syncing stuff. mVU0 will only exit out early from

recompilation for syncing whenever mBit has been set, instead of all the time.

This is a nice speedup in Nanobreaker, as well as fixes the constant

recompilation problem.

If anything breaks with this let me know :)

Autor...

Cool fixes VU0 perma-stall spamming shit in console in MGS3

arcum42

Though I doubt we should really have people e-mail zero if the graphics are bad... ^_^

cottonvibes

lol

Revision 1663

microVU: minor change...

Revision 1664

wxgui: Additional fixups to linux behavior.

Revision 1665

wxgui: Changed the method of usermode storage so that it doesn't violate

/program files permissions; plus some minor bugfixes/cleanups.

Revision 1666

Added Vif Error flags to Tags.h.

arcum42

I might actually want to split this into multiple files, since I'm starting to put register flags in that aren't actually part of the tags.

We'll see...

Jake.Stine

You know if you're going to keep on this pattern it might be a much prettier solution to use structure member methods, instead of an external namespace.

for example:

struct VIFregisters { // this is the current struct

[...] // current contents

// If true, interrupts by the i bit of Vifcode are masked.

__forceinline bool MII() { return !!(err & VIF_ERR_MII); }

};

... and then in code you just do:

if( vif1Regs->MII() ) { [...] }

Jake.Stine

Note that yes member methods are perfectly legal on structs in C++, and they do not affect the storage of structs in any way. (in fact as long as you have "struct" as the qualifier C++ won't let you use virtuals or other members that normally change data layouts and such).

arcum42

That's a point. It probably would make more sense to put the methods in the existing structure.

Though that does eliminate the indication that the methods are part of the Vif error register. Suppose I could nest structures, to get:

if (vif1Regs->err->MII()) { [...] }

I'll also have to look closely at Vif0Stat, and Vif1Stat, as they have slightly different flags.

And it occurs to me that I maight be able to incorporate the checks on MII, ME0, and ME0 into INT, ER0, and ER1, since the first three mask the second three...

arcum42

Though not exactly like that example, obviously, since err is an existing member of VifRegisters.

And, handily, looks like all the differing flags between Vif0Stat & Vif1Stat are on different bits...

Jake.Stine

Actually it'd be:

if (vif1Regs->err.MII()) { [...] }

And really there's even a third option, which is to use bitfields:

union {

u8 allbits;

struct {

u8 MII:1;

u8 ME0:1;

u8 ME1:1;

};

} err;

That's how the cpuRegs struct is laid out, and also all the gifTAG parsing code in gsdx and zerogs (those also use nifty macros for making the struct/union redtape less taped). Using bitfields there isn't really any need for get/set accessors or enums or defines, etc.

Some people don't like them though because they don't trust them (C standard has no required bitfield order, so a compiler could store them randomly and be C standard compilant). But since the most popular use of bitfields is for mapping the bits of hardware registers since like the dawn of time, no modern compiler dares violate the sacred low->high bitorder.

... so I'm all for bitfield use. :)

(well, except for IBM's compiler, which does high->low to match the big-endianness of its target cpus, but hardly any concern of ours :p ).

Jake.Stine

You could even be especially clever and change the macro for vif1Regs from a pointer to a C++ handle:

#define vif0Regs ((VIFregisters&)PS2MEM_HW[0x3800])

#define vif1Regs ((VIFregisters&)PS2MEM_HW[0x3c00])

... and search/replace all 'vif1Regs->' to 'vif1Regs.' :D

Jake.Stine

(Welcome to Stupid C++ Tricks 101 .. Lectures begin on Thursday. Tardy students will be penalized).

arcum42

There's a reason why you mention these tricks in a revision with 666 in the number, isn't there?

I like bitfields. There are a few cases where having accessor functions might be more useful, though. I like the idea of building the masking of INT, ER0, and ER1 into the function, for example.

And rewriting lines like this to use bitfields might be a pain:

vif1Regs->stat &= ~(0x1F800000 | VIF1_STAT_INT | VIF1_STAT_VSS | VIF1_STAT_VIS | VIF1_STAT_VFS | VIF1_STAT_VPS); // FQC=0

(Though lines like that could probably use it...)

Jake.Stine

Eh, yeah. >_<

Using the union approach allows you to still operate on the bits directly, at least. But it means you'd still need the #defines and enums (which isn't really a bad thing, I suppose). So it'd become:

vif1Regs->stat.allbits &= ~(0x1F800000 | VIF1_STAT_INT | VIF1_STAT_VSS | VIF1_STAT_VIS | VIF1_STAT_VFS | VIF1_STAT_VPS); // FQC=0

arcum42

Just noticed something. For whatever bizarre reason, the last field on vif->stat, fqc, is 4 bits on vif0, and 5 on vif1. That complicates things...

arcum42

Though the extra bit is a reserved field on vif0. Not sure if it does anything.

Jake.Stine

The field would specifically be reserved because the VIF channels, at the HW level, use the same basic duplicated logic. So the HW design would want to ensure matching bitfields and, if one side doesn't need the bit, they would mark it as reserved to retain matching fields for both sides.

arcum42

Makes sense.

Real question is how to handle that if we do bit fields. Reserve it the full size on both, and make sure that vif0 doesn't use the extra bit?

Revision 1667

wxgui: More bugfixes to configuration saving/loading.

2nats...

how i can download pugins plss help me i new and i need help

Revision 1668

microVU: Finally fixed the Kingdom Hearts missing poly bug =D

Revision 1669

microVU: Cleanup of opcode lookup tables. (Removed the macros since multiple

instances of the tables aren't needed anymore)

Revision 1670

Odds and ends. Various defines involving vif->stat are now enums, and are now

used in various places. Added a new file to GSnull. Moved the new Vif functions

to Vif.h.

Revision 1671

Changed some more stuff to use the vif stat enum's; and some other minor

changes...

Revision 1672

Lets use the Gif stat enums, too. And set some of the dmac irqs to have more

accurate names, and misc other things.

david.jennes

I always wondered why you guys use so many 'magic numbers' in the code, it's hardly manageable, hard to update, etc... Glad to see that changing :-D

ramapcsx2

Some parts of the code are like ancient. They come from times when nobody was sure it'd ever run real ps2 software :p

arcum42

Or are mostly verbatim from the original pcsx, in some cases.

Magic numbers and hard to read code in pcsx2 have been a pet peeve of mine for quite a while, and I spend time every so often trying to get rid of them.

In a lot of cases, you have to have a decent understanding of what's going on in the code to get rid of them, so as I understand the code more, I'm able to take care of more of it...

Revision 1673

Some preliminary HID code that I may or may not build off of.

mattme...

Err... LilyPad, of course.

gigaherz

Heh. I checked how to use HID stuff from within RawInput only, instead of using the hid stuff + the setupapi lib (which IMO seems like the wrong place to have hid functions O_o). But there didn't seem to be any documentation about the descriptor data RawInput returns... :/

mattme...

The annoying thing about doing it this was is using ReadFile with overlapped I/O. Unnecessarily ugly, IMHO. I hadn't thought about using RawInput.

gigaherz

RawInput worked for reading packets of data just fine, I gt some C# code for it around somewhere... :P

Revision 1674

microVU: minor change...

Revision 1675

microVU:

- Started implementing VU macro mode (code off by default)

- Disabled Constant Propagation for Jump Addresses (this rarely was a speedup,

and it slowed down recompilation time a lot in some games causing bad slowdowns

(GoW))

Autor...

GoW and Killzone have a lot more stable speed now, thanks cotton

ramapcsx2

Macro mode on mVU seems to be very stable out of the box.

Try FFX with it btw, mVU is 10% faster in it :)

ramapcsx2

Oh well:

[14:21] <rama1> dawn of mana uses some physics engine, and it seems to run on vu0 macro

[14:21] <rama1> and yeah, its bugged :p

ramapcsx2

Bit of trial and error brought up it's SUB.

INTERPRETATE_COP2_FUNC(SUB, "SUB");

^Using this instead of the recompiler, and the game physics work perfetcly again :)

zantezuken

Oh...

So, cotteh, it will be macroVU first? :P

heatbla...

Whew... I can`t catch up with all those revs... I haven`t tested 1666 and it`s 1675... have a break guys :"D

gamez4windowz

@heatblazer dont mention the word break yet as there on a role and i'm hoping that one day all the ratchet and clank games will become playable with very few graphic errors as i broke my ps2 last week and can no longer play them. :`(. btw devs thanks for a brilliant emu.

micheles...

cottonvibes help dolphin team

azte...

[email protected] - why you made such a stupid comment as that?

Line...

Hu-u-uge THANKs again, Cotton !!! Many games runs faster now =)

But... can you explain what exactly gives new VU macro code ? :)

It is for compatibilty or for speed ?:)

micheles...

nice

Autor...

rama about this INTERPRETATE_COP2_FUNC(SUB, "SUB");, what exactly in COP2 is supposed to be changed?

zantezuken

replace rec func with intepr.

Revision 1676

Various changes that were accumulating. Broke off Gif.h from GS.h. Changed some

defines to enums. A few other minor things.

arcum42

This looks like more changes then it really is when you look at the list of files...

arcum42

Note: I'm aware of a number of errors in the commented out code that I'll fix later. Punctuation *and* using reserved words...

heatbla...

guliverki site does not support downlodas?

Revision 1677

Fixed up the bitfield code in Gif.h to the point where it will compile.

Positioning in memory may still be off, so it isn't used yet.

arcum42

A few silly errors in there originally. Think I started typing it out right after doing a bunch of enums.

Revision 1678

Added what should be the correct padding to gifRegs...

arcum42

All right, that *ought* to work now. Still needs testing, and I haven't hooked it up to anything yet.

Being able to say gifRegs->stat.P1Q instead of (psHu32(GIF_STAT) & GIF_STAT_P1Q) should be an improvement, though.

Revision 1679

LilyPad: bugfix that should (hopefully) make it more difficult to accidentally

bind an entire axis. May make issues with devices incorrectly reporting initial

state worse.

qqqq.2...

can't compiler with 4 error (VS2008 Team Suite)

HidDevice.obj : error LNK2001: unresolved external symbol __imp__SetupDiDestroyDeviceInfoList@4

HidDevice.obj : error LNK2001: unresolved external symbol __imp__SetupDiGetClassDevsW@16

HidDevice.obj : error LNK2001: unresolved external symbol __imp__SetupDiEnumDeviceInterfaces@20

HidDevice.obj : error LNK2001: unresolved external symbol __imp__SetupDiGetDeviceInterfaceDetailW@24

C:\PCSX2\\bin\plugins\LilyPad.dll : fatal error LNK1120: 4 unresolved externals

mattme...

Setupapi.lib isn't in your default include path? It is in mine. Also, you're complaining about the wrong revision. Seriously, if you can't even find the right revision to complain about in a case where it's this obvious, you're not in the SVN target demographic, anyways.

qqqq.2...

mm...

I can't edit my previous comment, so...create following message...

It seem still need Windows Driver Kit (WDK) to compiler

http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00

I'll try later.....

mattme...

Actually, you don't need that. You just need to add Setupapi.lib to the library list. You have the setupapi header files, so you have the library files as well. Committing a fix momentarily, should let you compile.

mattme...

Oh, and sorry for my first response...

qqqq.2...

setupapi.lib is in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Lib

you need add this path to VS2008

AND

add setupapi.lib to Link/Input in VS2008

qqqq.2...

It's OK.

I know your work is hard.

Revision 1680

wxgui: Prepped the R5900 recompiler for the new wxWidgets-enhanced dedicated

emulation thread design, and removed the old boolean-based re-entrant event

checking mess.

Note: Nearly have a successfully booting branch! (bios crashes when it reaches

CDVD api callbacks, should be a simple fix but it'll have to wait until later

>_<)

shadowladyngemu

Awesome work!

Line...

Jake, can you, please, revert or fix BIOS CDVD booting branch ? We need it for some games... Really...

Jake.Stine

The new built in CDVD system will work more correctly in the wxgui branch, and that's where I'm currently focusing 99% of my energy.

Revision 1681

LilyPad: Added setupapi.lib to release build. Was already correctly linked in

debug.

espresso...

Yay, I can build LilyPad again!

mattme...

Sorry about that

Revision 1682

wxgui: Redid a bunch of the wxWidgets assertion handlers so that they're thread-

safe, and fixed the wxLogError stuff to pipe through to the PCSX2 console

(better than it spamming popup errors, and also makes it thread safe as well).

.. oh, and it successfully boots the BIOS now, suing the 'Boot Without Disc'

menu option. :D

shadowladyngemu

Great, not so long from booting games now huh? :p

kojikni...

Great to here it, compiled a version not to long ago just to check out how the new GUI was coming and I'm really impressed. Everything is much easier to access and flows together very nicely. Keep up the good work as always.

max...

Problem report

Unhandled exception at 0x01013a34 in pcsx2.exe: 0xC0000005: Access violation reading location 0x00000018.

> w32pthreads.dll!pthread_setspecific(pthread_key_t_ * key=0x00c58a40, const void * value=0x74f03301) Line 160 + 0xa bytes C

Visual studios say line if (!TlsSetValue (key->key, (LPVOID) value)) in pthread_setspecific.c

Revision 1683

wxgui:

* fixed console log position/size saving settings

* Configure buttons in plugin selector work as they should now

* fixed devel/release builds broken in the prev rev

zantezuken

just note: tried to run BIOS with mVU and it breaks on:

void vsyncVUrec(const int vuIndex) { mVUvsyncUpdate(mVUx); }

Revision 1684

Major Fixes!

* Fixed like a gazillion bugs in the new CDVD system; memory corruption, memory

leaks, failed resets, and who knows what else.

* New commandline parameters!! Added -skipbios/-nodisc/-usecdvd/-elf [file]

options, intended replacements for the now obsolete -bootmode (bootmode should

still work as it used to).

* fixed a bug that kept -help from working, and updated -help to display all

the new command lines.

* -nogui command line now causes PCSX2 to close on escape, instead of escaping

back to the GUI.

Jake.Stine

I think there might still be some issues with CDrom access using the built in Iso loader. Will try and look into it when I get the chance.

cottonvibes

Fixes a few of my ISOs that were having problems before.

pcsx2gu...

Great work as usual Jake, seems like some fixes to disc changing too? Will test later.

Also in CDVDaccess.cpp:

ssprintf( fname, (fname_only+" (%04d-%02d-%02d %02d-%02d-%02d).dump").c_str(), ssprintf? Is that a typo or I'm just too noob to have seen that before? (prolly the latter hehe) :P

Some comment typos:

-->Al subsequent checks use the non-negative value here.

Assertion check for CDVD != NULL (in devel and debgu <-- builds)

RebelliousX

There is a function called ssprintf to print variable-content message to file.

Jake.Stine

@pcsx2guide:

Yes ssprintf is a custom printf implementation gigaherz and I put together quite a while ago. It uses std::string internally so that it's 100% safe from buffer overruns or similar junks.

arcum42

"#define SafeSysCloseLib( lib ) ((void)(SysCloseLibrary(GSplugin), GSplugin = NULL))"?

Oh well, I'll fix it while I'm fixing Linux up...

Autor...

Kingdom Hearts 2 crashes now right after start

pcsx2gu...

It's not this rev it's 1686 causing it. It only happens with Run ISO from menu

Autor...

thanks for info

powerzx78

run-execute hangs pcsx2

Revision 1685

* Added the missing cd image types to the iso browser (img, bin, nrg, etc)

* Minor fix when using cdvdiso in browser mode (keeps the browser from being

obscured by the GS window).

RebelliousX

Just wondering if anytime in the future going to support

*natively* CSO image type. now the only way to deal with compressed image is

using some CDVD plugin.

Jake.Stine

The CSO format is by my estimate very poor. It intended for being usable by PSP firmware itself, and it's doubtful it would provide very good compression on the large majority of PS2 images (anything with FMVs typically does not compress much). Furthermore, NTFS compression likely matches or exceeds it, and is "right there" already built into the operating system.

(.. unless you have linux ..)

So yeah if we do a native built in format it's only going to be if it can surpass the compression ratios of NTFS compression. Otherwise it feels like a lot of work for not much point. And for it to be useful it's going to have to be based on 7zip or something. It's doable, but certainly not a high priority

... unless someone else wants to do it and post it as a contribution/patch, of course. Noithing stopping that :)

valles...

Those compression formats are all a bottleneck anyways.

Nobody seems to be using LZO, which is the only algorythm that makes sense for disk images and the like, because of low CPU use.

http://www.oberhumer.com/opensource/lzo/

Compared to this, DEFLATE is a turtle. And NTFS seems to be using that too...

Jake.Stine

Speed isn't the problem really. The problem is getting a compression algo that is effective on more than 5% of available PS2 titles. LZO wouldn't qualify, it's compression ratios aren't even as good as gzip which itself isn't good enough to be of use on most titles.

A proper image compression algo should do two things:

* Compress the easily compressible data with high ratios.

* Store FMV data or other already-compressed data in original uncompressed form. (basically anything that compresses less than 10% or so)

This way the emulator need not waste CPU speed decompressing blocks of data that only scored 1-10% compression ratios.

If you implement it this way, you should actually have little impact on ISO reading speeds, because the time required to decompress the data is largely made up in the time saved loading less data from the HDD.

valles...

Things are seldom that convenient. For gzip and mostly anything else (which is mostly slower than gzip) stuff, reading is CPU bound, not HD bound, making the read actually slower, as HDs are *way* faster than DVDs anyways.

What could be saved is space, perhaps using somehting like LZMA, with decompression being maybe fast enough for DVD needs.

Revision 1686

Linux only: Preliminary fixups for supporting the new improved commandline and

g_Startup implementation.

Jake.Stine

@arcum42: Just noticed that I forgot to remove/replace all instances of "elfname" -- it's successor is g_Startup.ElfFile. So you'll want to fix that, in case you get to it before me (and you might, I'm back off to sleep now :)

arcum42

Yeah, I'm fixing it up to work right now. I'll probably wait on coding the other menu options till I'm totally sure how they work in Windows...

pcsx2gu...

Breaks Run ISO Image from menu.

Jake.Stine

blargh. It's broken in Release builds because of *taadaa* COROUTINE. The lovely random and mysterious and untrackable memory corruption mess.

I'll turn PCH back on later, should fix it. Or someone else can do it (cotton?) if you feel like it. I'm trying (and failing :p) to stay focused on work stuff here.

arcum42

Coroutine? Figures.

Note: We are completely open to patches that rewrite coroutine being submitted in the issue section. ^_-

Revision 1687

Corrected an issue when closing plugins, and fixed up Linux to compile (Though I

haven't made the gui changes yet).

arcum42

Note: I'm not sure at the moment if Elf files work in Linux, given the changes. I'll be checking that shortly, but I wanted to get it running with isos again first...

arcum42

Nope, they don't. Easy fix for it, though.

Jake.Stine

Oops, haha. good typo I had there in ClosePlugins >_<

Jake.Stine

Oh and yea I didn't realize the RunELF command also used the global elfname. It should have its own local elfname var, and *not* use g_ElfFile (which is meant to be a pointer to argv only)

arcum42

Yeah, thought something was off when pcsx2 was segfaulting when closed. :)

Easy mistake, though.

And I'll switch to using a local var in RunElf...

pcsx2gu...

pcsx2\pcsx2\HostGui.h(20) : fatal error C1083: Cannot open include file: 'CDVD.h': No such file or directory

Compiling under VS2008 fails,think it's caused by #include "CDVD.h" in HostGui.h

Jake.Stine

yeah in windows that needs to be prefixed: "CDVD/CDVD.h"

I could add cdvd to the global includes list but I think I prefer it prefixed and outside the global includes namespace. It's not something that's used that commonly.

heatbla...

There is a weird bug in Devil May Cry 1 in the sewers level - if you jump, Dante falls and passes trough the floor and disappears from the screen unable to move, you can still draw menus or hit or shoot but - consider it a dead loop. No speed hack and all Advanced - defaults.

Revision 1688

Fixed Elves in Linux, and implemented two out of three menu items.

arcum42

Haven't bothered about the iso menu item, since it'd take a bit more effort to implement...

Jake.Stine

ah, yeah that works too, although really the RunELF bit should probably just be using its own "const char* localtemp = gtk_file_etc()" thing, instead of g_Startup. :)

Jake.Stine

Not that it matters that we get things perfect. I'm just fixing all this up for one final good public beta for people to use for the next few weeks, before I go and break trunk in fun ways with wxgui re-integration.. ;)

arcum42

True. That's the other part of why I didn't bother to do the iso menu item.

And that definitely works for me, since I'm getting ready to do a precompiled Linux beta.

I'd actually been planning at looking more at the iso code. Think a rewrite was mentioned as being in progress, though.

I recall I'd found that it crashes if the demo "4 Edges" by "The Black Lotus" was loaded...

arcum42

And I still have yet to test the latest wx code in Linux. My copy of codeblocks got all messed up. It crashes the moment I load the project file. :(

I'm probably just going to redo my 32 bit chroot, since an uninstall reinstall didn't take care of it.

Jake.Stine

>> I'd actually been planning at looking more at the iso code. Think a rewrite was mentioned as being in progress, though.

>> I recall I'd found that it crashes if the demo "4 Edges" by "The Black Lotus" was loaded...

Do you mean the IsoReader or the ELF loader? I think the demo crashes because of ELF (makes more sense, it shouldn't be using the cdvd/iso stuff at all).

No rewrites are planned or in progress of ELF, and yea it's a slopfest. ;) I did clean up a few minor things in the wxgui branch relating to the GetPS2ElfName and loadElfCrc, but nothing in the ElfHeader class itself.

There's plenty of public docs available on ELF, so there's not much excuse for us not having an ELF loader that works, eh? ;)

arcum42

I meant the isoReader, and this particular demo was done as an iso, so it was going through the isoReader. It was actually crashing when IsoFS_findfile gets called with a corrupted elf file name, as I recall.

Works properly with the linuz plugin, for some reason.

And I agree on the elf code. I cleaned up parseCommandLine a bit ago primarily because I got curious how it worked, and because it was a bit convoluted. Seem to recall it turned out to have a fencepost error in it, too. :)

Jake.Stine

>> Works properly with the linuz plugin, for some reason.

Oh re-check it with the new iso fixes. There were a number of corruption bugs that cased a lot of ISOs to fail to run when using the built in iso loader.

Revision 1689

Use a local variable for the elf name.

Revision 1690

Fixed Windows.

arcum42

Presumably, anyways. I can't boot into Windows at the moment, and my 32 bit chroot is in the middle of a rebuild...

Jake.Stine

One of the nice things about the wx branch's codeblocks project files is that the include environments for linux and windows match exactly.

Of course the drawback is that if codeblocks devours itself in a fit of self-masochistic loathing, then you're screwed. >_<

arcum42

Yeah, that's the issue. :(

Fortunately, I don't consider the process of rebuilding the chroot difficult. (Though a lot of people would disagree with me...)

Moonra...

Hmm, Arcum fixed Windows. Quite a feat, actually, although I thought you were fixing PCSX2.

Sorry, couldn't help myself there. :)

Jake.Stine

I personally consider it a much more impressive feat when we fix Linux ( r1478 )

max...

hi , brocken pcsx2 in plugin.cpp lasts rev's

> pcsx2.exe!OpenCDVD(const char * pTitleFilename=0x00000000) Line 861 + 0x5 bytes C++

pcsx2.exe!OpenPlugins() Line 987 + 0x22 bytes C++

pcsx2.exe!SysPrepareExecution(const char * elf_file=0x00000000, bool use_bios=true) Line 405 + 0x5 bytes C++

pcsx2.exe!MainWndProc(HWND__ * hWnd=0x0022063e, unsigned int msg=273, unsigned int wParam=40004, long lParam=0) Line 727 + 0x9 bytes C++

user32.dll!756d8817()

[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]

user32.dll!756d898e()

user32.dll!756d8921()

user32.dll!756d8ab9()

user32.dll!756d90e3()

pcsx2.exe!RunGui() Line 412 C++

pcsx2.exe!WinMain(HINSTANCE__ * hInstance=0x00000000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00422432, int nCmdShow=1) Line 65535 C++

pcsx2.exe!__tmainCRTStartup() Line 574 + 0x1d bytes C

kernel32.dll!75f6eccb()

ntdll.dll!7725d24d()

ntdll.dll!7725d45f()

CDVD->newDiskCB( cdvdNewDiskCB ); <-- This error

Grettings.

Jake.Stine

I can't reproduce that error. It looks like you're trying to boot into the BIOS, and that's working fine for me here (well it works fine in debug/devel modes -- release mode is currently broken for other reasons).

arcum42

In case anyones curious, my chroot rebuild is mostly done now. It would have been done before now, but I went to bed after my last comment on this commit.

At this point, I can run pcsx2, and I can open the wxgui project in codeblocks. Can't *compile* it, but I don't think I chose the right options on wxwidgets when I installed it (as I let codeblocks pull it in), so I'm reinstalling it.

arcum42

Ah, never mind, you broke wxgui on Linux again anyways, by adding more naked code in...

arcum42

Got it working somewhat by hacking DispatcherEvent in. It doesn't detect any plugins that have anything after .so, which is most of them, though. (File format for the plugins is usually lib<pluginname>.so.<version>

Jake.Stine

Oh sorry, that's just a temporary hack. I'm going to remove it soon.

Jake.Stine

Or well, maybe not. Changing the dispatchers to use the emitter is the eventual plan but I don't want to futz with it until games are running on my end. ;)

arcum42

No problem. At least I've got codeblocks working.

Besides that, the issue I was running into was that the include directories in the Utilities project on the Debug target need to be on the other targets for Utilities as well...

arcum42

For the moment, I think adding:

.extern recEventTest

.globl DispatcherEvent

DispatcherEvent:

call recEventTest

jmp DispatcherReg

to aR5900-32.S, wrapping recEventTest in extern "C" {}, and adding DispatcherReg to NakedAsm.h would make Linux happy as far as the dispatchers go...

Jake.Stine

Yeah sounds about right. If you want to made those mods (or have already) then go for it. I'm not in a mood to redo things using the emitter and I may not be in such a mood for quite a while.

As for the plugin enumerator, hrmph. Guess we'll have to add a non-win32 define that additionally enumerates *.so.* (should be non-win32 because I think linux and OS-X both would want that behavior)

arcum42

All right, no problem, I'll go ahead and commit my current changes.

And I think Mac OS X would want that behavior too. Usually for actual system libraries, the way it works is that you have libraries with that file format for each one installed, then a link named lib<name>.so linking to the currently used version.

Not behavior we want here, of course, but that is why the naming scheme is like that, to my knowledge.

arcum42

Committed.

Revision 1691

* Re-enabled PCH in release builds; fixes various mysterious crashes.

* Restored Run->Execute's old behavior when the emu is in a reset condition

(plain jane bootup using CDVD plugin).

* Fixed some CDVD init stuff on the Linux side of things.

Revision 1692

wxgui: A few Linux related changes.

arcum42

Spotted a mistake or two after committing this.

I just meant to comment out OnAssertionFailure, since Linux wanted an actual function for it if it was there.

And I don't think "../../common/include/Utilities/Dependencies.h" was supposed to get into pcsx2.cbp...

Revision 1693

wxgui: Correct r1692.

Revision 1694

microVU: Made the flaghack safer by accounting for some problematic case.

It fixes the few games I have that were having problems with the flaghack (but

the speedup the flaghack offered in those games has been lessened).

The speedup on games that weren't having problems before should be around the

same as before; (in other words: games that were compatible with the hack should

still be as fast as before, and games that had problems with the hack will

probably be fixed but the speedhack won't do as-much)

ramapcsx2

Great stuff. Katamari Damacy and Radiata Stories are fixed :)

Revision 1695

wxgui: Connected up the CPU panel controls so that they do something, and

fancied up the "Apply" button so that it ungrays only after changes to the

config have been made. :)

zantezuken

and again, just some remind notes :P

1. If I will remove pcsx2.ini it doesn't says that I need to reconfigure it, just makes default one.

2. There is no changes between options microVU and SuperVU (same value in the conf)

3. Value 4 for "VUCycleSteal" directive crashes PCSX2 @ General Setting dialog on:

::DispatchMessage(msg);

(green arrow)

4. Values for Other Hacks doesn't saves correctly. Well, their state isn't loading actually.

5. Gamefixes dialog doesn't saves/loads any value.

6. Logging dialog windows doesn't save the vales too (well, it was so since the first runnable release :P)

zantezuken

Also, why it tries to create folder pcsx2/ in user's Documents folder but makes it instead in AppData/Local/ ? :P

Jake.Stine

>> why it tries to create folder pcsx2/ in user's Documents folder but makes it instead in AppData/Local/ ? :P

It should use both. The appdata/local/pcsx2 folder contains the usermode information for whatever locations you run pcsx2.exe from. I needed an operating-system defined universal location for this info, and it was either there or the registry. Initial revisions of wxgui were storing a usermode.ini in the current working dir, but that had the same problem the 0.9.6 release have: violates Vista/Win7 permissions in program files. ;)

arcum42

In Linux, compilation currently errors out saying that GetWindowChild is 'not declared in this scope'.

If it gets past that, it complains about OnAssertFailure not being defined...

zantezuken

> I needed an operating-system defined universal location for this info,

> and it was either there or the registry.

I hope it wwll be a lone ini-file in specified static location ;p makes life easier for 3d party software :P

Jake.Stine

OnAssertFailure errors are related to it only being avail in debug builds somehow. I'm not sure offhand why.

GetWindowChild .. well.. I dunno. I thought I was using it other places already. I'll look into it.

Jake.Stine

Aha, it's FindWindow, not GetWindowChild. I'll fix in a jiff.

arcum42

Odd, I was building a Debug build...

Jake.Stine

Yeah I don't know what's the matter. It's clearly there in the generic headers and stuff. Wait, actually maybe you're missing one of the new files from your project! The function is defined in....

/pcsx2/gui/AppAssert.cpp

Might be missing from the cbp.

arcum42

Yep, that's what it is.

Ironically, if I'd done the search with Scite, which I use on the main branch, it doesn't know what's in the project and what isn't, so I would have found where it was defined.

Codeblocks is nice enough to limit the search to files in the project, though. ^_^

Jake.Stine

@zantezuken:

>> I hope it wwll be a lone ini-file in specified static location ;p makes life easier for 3d party software :P

Hmm, yeah I hadn't really given thought to 3rdparty stuff, though the ini file in AppLocal probably isn't something a 3rdparty software should care to look at anyway, I think. It simply specifies the location of the pcsx2.ini file for whatever source folder you run pcsx2 from (that way you can have different configurations for different dev copies and/or versions of pcsx2 :)

Most of the current 3rdparty apps assume either Current Working Directory or have you manually specify your pcsx2 location. Don't think that'll change. Tho, if the user installs using the installer, there'll be registry keys that a 3rdparty app can use to find pcsx2.exe automatically.

Revision 1696

wxgui:

* synched with trunk to pick up all new cdvdiso fixes.

* configuration wizard now starts if pcsx2.ini is missing/deleted.

* changed GetWindowChild (MSW specific?) to FindWindow.

Revision 1697

More CDVD and cdvdiso bugfixes: cd-rom images should work now (ie, the old

school non-DVD sort!), and improved the error and async read handling (possibly

affects people running games from dvdrom)

arcum42

Ironically, the very first game I loaded with this game 30 or so CDVD READ errors[1] on startup. Works perfectly fine afterwords, though, and it's the same game I had to hackfix in the iso code before, Final Fantasy X-2...

[1] CDVD READ ERROR, sector=1944435

Final Fantasy X gives a bunch of these (with a different sector) right before crashing at the "Auron, Look!" screen, too, but I expected that... :)

Jake.Stine

I can't reproduce that error here. Is there anything special I have to do? :)

Jake.Stine

Never mind, I don't have FFX-2 .. I read it as FFXII (FF12). Bleh. So confusing.

Anyways if it doesn't crash and runs correctly then I'm inclined to believe it's correct emulation, and that the game is, for some reason, intentionally trying to read invalid sectors. The original gigaherz implementation ignored the error and invalided the pTransfer buffer pointer (bad). I fixed it so that the transfer buffer remained valid, but I still ignored the error and returned a pointer to whatever the last successful read was. The new code properly handles the error, and does not read any data or raise any read-completed interrupts.

arcum42

Not particularly. They actually happen before the opening even really starts up. Could be a bad spot on my rip of the iso or something, though.

I did have a bunch of changes in my local branch[1], but I just tested with a clean copy of svn, and got the same errors. Not a big deal, since it continues on afterwords.

Crashes if I try to make blockdumps, too. Could be Linux specific.

[1] Namely, I've been converting a bunch of code to use bit fields, including all the chcr code I put in...

arcum42

Yeah, that's the trouble with the Final fantasy series. And I test with all 3 routinely, too...

And it's likely that it's actually trying to read invalid sectors, since FFX does the same thing. In fact, I was testing FF X-2 because the invalidated pointer broke it originally, before I put a test for a NULL pointer there, so I knew there were potential issues in that spot.

arcum42

Taking a closer look at the Blockdump crash right now. It's at line 295 of CDVDaccess.cpp, somewhere when it's getting the filename...

arcum42

In fact, it's because the function it's calling to get the iso name is mapped to NULL in the CDVDapi_Iso struct in CDVDIsoReader.cpp, not ISOgetUniqueFilename...

arcum42

Just noticed: this revision fixes that issue with that 4 Edges demo I was mentioning...

Revision 1698

A quick fix to prevent creating dumps with the built in iso code from crashing.

Jake.Stine

Ah, good. does dumping work correctly now? I fixed the main bug that was breaking it earlier, but never actually tested it ;)

arcum42

It seems to. Haven't made a large enough dump file to really test, and in Linux, they appear to get saved at /, but the files are actually created, and it no longer segfaults if you tell it to create a blockdump...

arcum42

Actually, looks like the dump won't load. It acts like it's going to, says that block 257 isn't found, then says it can't open "cdrom0:\MODULES\IOPRP310.IMG;1".

Thought that was too easy. Oh well, at least part of the problems taken care of.

Revision 1699

It fixes the compilation error in Windows, or it gets the hose again.

arcum42

I'd be surprised that that didn't give me an error in Linux, but I've noticed in the past that gcc can occasionally be generous with that sort of thing when it shouldn't be...

Jake.Stine

Yeah I had the same thing happen to me in gcc 4.0 on the wx side.

Norikumi...

I'm looking down the code, you're looking up at me

You're cold and tired, that is easy to see

Lower the cpp to you, a bug on the file

Your building will be soft and smooth and your plugin will be mine

//offtopic.

david.jennes

That sounds seriously wrong... :-P

Norikumi...

I blame the lack of an edit button.

zantezuken

Lol NorikumiSubs

Revision 1700

Fix a typo causing *.dump files not to appear in the "Run ISO" file browser.

Jake.Stine

hey I was about to commit that!

cottonvibes

too slow xD

Revision 1701

More CDVD fixes. I *think* this revision might provide some noticeable speedups

when running games directly from cd drives. Also built-in CDVD blockdumps work

now (DVD images only, legacy CdRom games still don't blockdump right unless you

use the cdvdiso plugin).

Jake.Stine

Someone do a few blockdump tests for me and make sure this still works. I made a few last minute code changes right before commit and I'm too exhausted to test it right now after having done ilke 200 consecutive blockdump tests already.

If it works I'll de -1'ify myself. I just did that to get yall's attentions :p

mattcallaghan

Kinda rushing my tests but I made a dump of FFX (PAL) and the dump seems to boot and goes into the opening video.

mattcallaghan

Just tried making a dump of Oni aswell, which I believe is a CD based game and that seemed to work just fine.

Jake.Stine

Ok, thanks. It's possible the block dump incompatibility is specific to the one CD game I have available for testing. In any case it's stable enough for me for now. I'm going to leave it be.

I would also like someone to give direct-from-CD play (using cdvdghz for example) a try and see if it feels a bit faster now.

arcum42

Just noticed that this revision causes Final Fantasy X-2 to stall out on the CDVD READ errors, rather then going past them...

arcum42

What FF X-2 currently is doing is this:

CDVD READ ERROR, sector = 0x001dab73

CDVD READ ERROR, sector = 0x001dab53

CDVD READ ERROR, sector = 0x001dab63

CDVD READ ERROR, sector = 0x001dab73

CDVD READ ERROR, sector = 0x001dab53

CDVD READ ERROR, sector = 0x001dab63

CDVD READ ERROR, sector = 0x001dab73

CDVD READ ERROR, sector = 0x001dab53

CDVD READ ERROR, sector = 0x001dab63

CDVD READ ERROR, sector = 0x001dab73

CDVD READ ERROR, sector = 0x001dab53

CDVD READ ERROR, sector = 0x001dab63

CDVD READ ERROR, sector = 0x001dab73

CDVD READ ERROR, sector = 0x001dab53

CdStandby : 2

CDVD READ ERROR, sector = 0x001dab73

CdStandby : 2

CDVD READ ERROR, sector = 0x001dab73

<the last two lines keep repeating>...

arcum42

Works properly with the linuz plugin, btw, which rules out some of the changes being the culprit...

Jake.Stine

Rama has FF X-2 and can't reproduce this error. It could be region specific or your image might actually be corrupted. The only thing I changed in this rev was to fix a bug that caused PCSX2 to "issue" the read anyway even when it failed (it would retry 16 times, and then just act like it read the data).

So all it was doing all this time was lying to FF X-2 that it could read the sector.

If the game literally tries to read unmapped or special mapped sectors on the inner tracks of the DVD, then an iso copy may be lacking those sectors if the ripper didn't know it needed to include those blocks.

arcum42

All right, must have been a corrupted image, since I reripped it and it's fine. Guess the earlier version was just more forgiving of a bad image.

Strange, though, because I reripped it exactly the same way I rip all of my dvds, which would have been how it was ripped in the first place. Wonder how it got corrupted?

(The way I normally rip isos, btw, is "dd if=/dev/dvd of=<iso name>.iso")

arcum42

Incidentally, the "Auron, look!" bug is now more amusing after these changes. Instead of crashing, Auron and Tidus glance at each other a bunch, pace around, then Tidus hides behind Auron and stays there. :)

Jake.Stine

... I think that's an improvement? lol

arcum42

You could say that... ^_^

The fundamental issue is still there, it's just that now the dvd stalls if it gets instructions to read to a sector that doesn't exist, instead of actually trying to jump off the dvd and crashing. And when it's stalling, all the tricks they use to make the characters seem a little more alive become evident...

Jake.Stine

oh! I forgot to address this one:

>> Works properly with the linuz plugin, btw, which rules out some of the changes being the culprit...

Yea! Linuz has a hacky fix in it that 'ignores' certain types of invalid sectors. Gigaherz smartly removed it, and it was prolly masking over other errors

Revision 1702

More Macro VU work

Revision 1703

microVU: Removed the use of an offset-register for referencing VI regs.

It didn't make any noticeable difference speedwise, and removing it will make

mVU macro code simpler.

Revision 1704

mVU Macro: Implemented more instructions...

Revision 1705

Changed the chcr stuff over to bitfields, and got various other bitfield stuff

ready for later on.

arcum42

All right, I'm done with big commits for the weekend. I was debating on whether to even do this one, with everything else going on...

arcum42

In fact, if you want me to merge this into the wxwidget branch myself, Jake, just let me know.

Don't think these changes would cause much in the may of merging issues, though.

Jake.Stine

not a problem. I doubt any of those files will have anything more than a logging conflict or two (due to unicode compliance stuffs). I'll merge later when I'm ready-ish. :)

arcum42

All right, cool.

And, yeah, I decided you were right about the bitfields. They look a lot better in this revision then the namespaces I'd set up previously...

Revision 1706

Fixed typo.

arcum42

Don't know *how* I didn't catch that.

arcum42

The heat's been messing with me the last few days, so that might be part of it. Bloody 107 F temps...

Revision 1707

mVU Macro: Implemented more stuff and did a big cleanup.

Line...

And again - BIG THANKS !!!

Mr.Hen...

Eee, this may be kinda stupid question, but what exactly Macro is for?

Jake.Stine

VUmacro is technically known as the COP2 unit (using MIPS terminology), which is the "Co-processor 2" of the R5900 (EEcore).

It allows the EE to execute individual instructions on the VU0.

Thus:

* VU0 micro mode runs entire programs on the VU0

* VU0 micro mode (COP2) runs a single instruction

nexxus86

so is mVU in some games faster than ZeroVU now?

ntcong.it

some games faster, some game slower, but I think mVU emulate the VU more correct than zerovu

metroidp...

I thank you, speedups in tekken5 and more stability, or sc3 and pes09 more stably in the last builds

when the cleanups is in the command window, stuttering occurring now in these latest builds is a greatly reduced cleanup lines in command window, this makes it much more stable.

continue the great work.

Wagnar...

Working great here. little speed up in tekken 5.

Cant wait for Microvu to get multi-threaded. if it ever get ....

Autor...

Yea it's great, tekken5 only 2-3 fps slower on microVU than ZeroVu for me now mVU 49fps against 52 on Zerorec on slowest arena *T5(PAL)

btw can you include Interpretate SUB instruction fix in COP2 some games like Rumble Roses, Smackdown vs Raw, and Munhunt 2 really needs this

also can't wait for threaded VU

thanks cotton

Mr.Hen...

Oh, thanks for answer.

Revision 1708

mVU Macro: Some changes for a more correct interlocking behavior again VU0 micro

programs.

Revision 1709

Installer Improvements:

* installer will automatically version itself to the svn checkout

* default installation folder, filenames, and links all contain the revision

number now.

* Plugins are optionally included into the package (details in txt)

* VC++ Redist detection: the Redist installer is only extracted/invoked if it's

not already installed.

Jake.Stine

Note to self: I still need to check and make sure I'm including all dependencies, and make decisions about the dependencies needed by gsdx/zerogs.

azte...

for such a cool change you SURELY will get +1. :)

arcum42

Come, now, this is google code. A -1 is just as likely for a cool change. ^_^

Revision 1710

Finished mVU macro, and set it on by default.

Basically this means whenever COP2 recs are used, its calling mVU instructions

instead of sVU instructions.

Note: Theres a very-minor incompatibility problem when using interpreters/sVU

for VU0 with mVU Macro. But I'll fix it later (and it probably doesn't effect

much).

zantezuken

VU0 issues described in Issue 170 still happens even with macroVu+microVU.

Does macroVu is still pretty the same as SupeVU? ;P

Autor...

MacroVU is for VU0 only or MacroVU1 will be in the future too?

Jake.Stine

There is no macro mode for the VU1. It can run full programs only (micro mode).

arcum42

As I recall, VU1 doesn't use the coprocessor or macro instructions...

cottonvibes

VU0 has 2 modes, Micro Mode and Macro Mode.

When its in Macro Mode its also called COP2 (it works as a co-processor to the EE).

VU1 only has Micro Mode, and doesn't have a Macro Mode.

mVU's Macro Mode should hopefully have the same compatibility as sVU's Macro Mode.

If not, report problematic games that broke in this revision, and I'll see if I can fix them.

cottonvibes

Also it'd be nice to get some speed comparisons between this revision, and the one before it.

I think mVU Macro should be faster.

Autor...

BTW Killzone and Gow games still have some instability in speed

zantezuken

Well... tested few games - didn't notice any difference in speed and compatibility as well. I can say that new macro isn't slower than old superVU macro.

Rhei...

I have tried this rev out and it makes strange things in FFX-2 happen like the blue spinning ball deal in the deck of the ship when you first start is gone pretty much. and there is strange yellow lines accross the screen too just before leaving the deck to the elevator. and other odd looking bits of floating color. It does however address the major slow down I had in r1708 it is running smooth again just weird stuff going on. so it is back to r1707 for now.

Rhei...

Oh my bad, visual studio was updating intelisense at the time. 1708 speed is fine. the visual isses are definitely still there though.

Jake.Stine

Hmm, there's a thought. I wonder how many other complaints of jerky fps on specific revisions is because of intellisense updates in the background. ;)

shadowladyngemu

Primal (E), shows some 3D now with microVU0 enabled, it's still unplayable thou and it will eventually hang but a great improvement over hanging on the "loading" screen :P

Rhei...

mm I usually close VS after a build but this time I went and compiled each revision so i could find which one did the graphic glitch, and left it on :/

kimoki...

Well I tried "WWE SmackDown! Here Comes the Pain" players cannot attack each others.. you can move through the other player. NO collision :D.

cottonvibes

Rheikon and kimokimo1, can you guys see if r1713 fixes your problems?

kimoki...

cottonvibes r1713 fixed it yes, good work man.

Revision 1711

wxgui: another sync with trunk to pick up more of those cdvd fixes.

Jake.Stine

the syncs are getting huge because of the TortoiseSVN properties updates (it manages merge information, which is a lifersaver really). But that's why a merge that should have only modified about 15 files ends up modifying 80. :)

kaboo...

+1 because it's dull work and your explanation for the size

Revision 1712

wxgui: Enumerate all the plugins on the Linux side. (And expose a nasty segfault

problem.)

arcum42

Note: If you put all the standard Linux plugins in the plugin folder, and go to the plugin screen, it will segfault the moment it tries to load either ZZOgl or ZeroGS.

I got past that issue by only including GSNull as a graphical plugin. :(

arcum42

Not that I managed to run the emulator with null plugins, either. I can see getting Linux to work is going to take a while...

arcum42

Backtrace I got from the crash on loading the graphics plugin was the following, btw:

#0 0xf0089ba0 in ?? ()

#1 0xf77afe4a in __nptl_deallocate_tsd () from /lib/libpthread.so.0

#2 0xf77b0fd9 in start_thread () from /lib/libpthread.so.0

#3 0xf7735b5e in clone () from /lib/libc.so.6

Looks like a threading issue.

Jake.Stine

Actually it looks to me like a C++ exception handling issue, maybe.

_deallocate_tsd should only be invoked if the thread is attempting to terminate. And the thread should only be attempting to terminate if it generated an exception because of some invalid plugin error.

Anyways, I should be able to reproduce that here. I can test plugin enumeration fine. I just can't run games. :p

arcum42

Yeah, reconsidered after posting that comment...

Just keep in mind that you'll need to disable segfault catching to be able to get a backtrace.

What bugs me is that it likes GSNull. I'd be able to understand it better if it was all Graphical plugins. Might be that GSNull "implements" some optional function that ZeroGS doesn't or something, though.

Jake.Stine

Actually I take back what I said, I did some tests and multiple wildcards seem to work fine here. I realized I hadn't actually tried to use one since like the DOS 3.xx days, and who knows what I used to screw up and blame on something else, when I was 11 yrs old :p

arcum42

Yeah, I thought of that too. When I first encountered the problem, I reverted the change, and set up symbolic links to the plugins that all ended in .so. Same issue. Then I started dragging links out one by one, and that's when I pinpointed that it was just ZeroGS and ZZOgl causing the issue.

At that point, I put the code back the way I had it, got rid of the symbolic links, and verified that all the other plugins showed up if those two weren't in the plugin folder...

Revision 1713

mVU macro: I forgot to enable some flag updating code I did in my last commit.

This probably fixes a lot of the games that were having problems.

Autor...

Fixes munhunt2

zantezuken

> Fixes munhunt2

What exactly it fixes in Manhunt 2? It is still the same for me, except it is lags much more now.

Also, Issue 170 still here.

Autor...

It was the same problem as in the Smackdown games, but in munhunt player was about 1/4 fall through the floor

Rhei...

This fixed part of the graphics issues from r1710. still some missing graphics and some floating bits are around.

cottonvibes

Rheikon: Where in FFX are the floating bits?

I have the game, but don't have any gamesaves or anything. I can test the beginning though. Will I be able to see it there?

If-so I'll try debugging the problem tomorrow.

Rhei...

FFX-2 is the game. and its right on the celsius ship the ball in the middle area of the bridge is mostly gone. and if you go back to the elevator you can see the glowing parts that were supposed to be for lights I think just kind of floating off to the side. I can't remember any other specific places at the moment. and if you have this then yes it is right at the beginning pretty much.

Autor...

BTW what kind of problem is this?

http://img171.imageshack.us/img171/3876/gsdx20090726014437.jpg

http://img65.imageshack.us/img65/6827/qud6avqwss.jpg

Revision 1714

wxgui:

* Moved some files around in an attempt to improve CoreEmu and UI separation.

* Major upgrade to the UI's handling of savestates

* Maintenance work to the C++ exception handling

* Some improved error handling and message popups here or there

Jake.Stine

This commit almost certainly breaks GCC in some horrible C++ sorta way. I'm too tired to test it tonight though. I'll give it a whirrl tomorrow.

(and this huge commit just started out as me trying to fix up the thread so that it was properly suspend/resumable and could handle errors nicely with yes/no type prompts)

arcum42

It's mostly in a "files need to be added/deleted, and declarations are missing" type of way. It has issues with CDVD_API, for example. And the extern of DoCDVDreadSubQ in CDVDaccess, for example (which either was renamed, or no longer exists).

Jake.Stine

That's odd. I didn't think I touched anything to do with CDVD this time around. O_o I'll check it out.

arcum42

Actually, looks like that was because of me adding #include "CDVD/CDVD.h" into System.h, which I did because you added enum CDVD_SourceType to it...

Jake.Stine

Looks like there's also a million warnings, at least in GCC 4.0, regarding the exception classes. I need to revisit the C++ docs and decipher what the actual behavior is in that situation since I can't trust my fav website anymore (it's written to be understood by regular humans, but it itself does't always understand the C++ standard)

arcum42

Yeah, noticed those. I just got distracted by the errors before I got to a point where I was going to look at them...

Jake.Stine

I'll fix the warnings. The proper fix is an annoying one. I need to get rid of the C++ initializers, basically... which means using a common initialization function. I'll be a bit of a copy paste job.

I'm still not sure what's up with the include file troubles you're always having. I hadn't had to change anything except case in include files when migrating from msvc over to wx -- well and remove some old out-dated ifdefs from the old trunk that were needed to fix its weird-ities :p

Jake.Stine

... but yea if you can update the project files and get the errors fixed, up it. I'll commit a warnings fix in a bit. :)

arcum42

Most of those exception errors look rather silly. It just wants you to reorder things a bit, like from:

explicit AssertionFailure( const wxString& msg_eng, const wxString& msg_xlt ) :

LogicError( msg_eng, msg_xlt )

, BaseException( msg_eng, msg_xlt ) {}

to

explicit AssertionFailure( const wxString& msg_eng, const wxString& msg_xlt ) :

BaseException( msg_eng, msg_xlt )

, LogicError( msg_eng, msg_xlt ) {}

I'm actually on the verge of going to bed, though, so I doubt I'll commit anything right now. Sundays a work day for me, and I rarely have much coding time on workdays. :(

Jake.Stine

right, but even if I reorder it, the actual initialization order will be wrong and things will get effed up in some cases. Plus it's a lot of ugly duplicated code >_< ... I need to get rid of the initializers entirely and replace them with an Init() function.

arcum42

Ah, point.

And I managed to get it to compile by:

a) throwing a

# define __unique_stackframe

into CoreEmuThread.cpp for Linux,

b) Moving the definition of enum CDVD_SourceType into System.h, and

c) adding the missing files.

While b) works, it's probably not the best way to go, so I'll wait till the morning to commit, and see if I think of a better way to handle that...

arcum42

Morning in this case defined as past noon.

Jake.Stine

ok, no problem. I'll look into the enum thing. I used a forward declaration and that *should* be legal. Hrm.

metroidp...

good luck guys

arcum42

Well, this is irritating:

http://stackoverflow.com/questions/684670/why-doesnt-c-allow-forward-declaration-of-enums

arcum42

Not really seeing a better solution at the moment. Including CDVD.h in System.h seems to cause too many issues, and I don't really see a better place to move it.

I'll put it there for the moment, and if we come up with something, we can move it then...

Revision 1715

Fixed Issue 384 - minor compilation error in linux when using local inis.

Revision 1716

wxGui: Get Linux compiling again.

Revision 1717

Added some diagnostic messages to a hackish part of the EE recompiler.

Revision 1718

Reset and recompile the current block on constant buffer overflow. (Some other

checks should be changed to use this if this isn't immediately reverted.)

Revision 1719

microVU: minor changes...

sunnydra...

uhh i feel very uneasy when i use float in simple math of integer code.... C++ typecast is blessing and damnation.

cottonvibes

sunnydrake7:

Don't rate if you don't know what you're talking about.

Negging a commit because you don't like decimal numbers is retarded.

And FYI, compilers optimize out constants. There is no "float", the compiler see's (0x100000 * 0.5) is a constant, and then converts it to "524288" which is an integer at compile-time.

Wagnar...

Cottonvibes your right of not be happy with the -1.

But I cant believe you just said he was a retard... He was very polite in his commit and even if the -1 is not justified, I don't think he deserved that treatment.

I'm neutral with your commit but -1 for your attitude. Sorry.

Castrat...

I disagree. It's like someone walking into my job, looking at my gear, stating his discomfort with Canon cameras with no explanation, and then turning to my client and telling them not to use me.

It's simply unprofessional to just say "I don't like this, and is therefore wrong and shouldn't be used" without any rational explanation. I'd consider it downright aggressive.

cottonvibes

Wagnard28:

If my commit broke something or effected any game negatively a -1 would be justified.

But negging commits for fun, or because you personally don't understand simple multiplication by decimal numbers obviously doesn't make me happy (especially because I've warned people about this stuff before).

The rating system is a great tool, but I hate when people abuse it.

Also because of stuff like this we're going to be disabling comments and ratings when we merge the WX branch to trunk.

It may be that I over-reacted a bit, but when someone devotes ALL their free time working for a project with no pay, its very-arrogant to criticize their work without a good reason IMO.

haobiao...

Take it easy cotton~

And sunnydrake7, please never '-' a reasonable change just because "you" don't like it

sunnydra...

ok set to neutral if it caused so much personal retaliation, but i have a lot troubles with compiler typecast optimizations/conversions - it's not so dependable as it seems and more dangerous if you use it complex projects which use recompilers/register/memory and if code must run on different compilers, this was just my personal exp..

Wagnar...

I totally Agree with you cotton. you shouldn't have got a -1 for the reason you said.

But at least you know you maybe over reacted. I don't think the guy deserved to be called a retard because I know your more brilliant than that :)

Sorry for my English (2nd language) I may not have express my thought clearly in the first post.

trigunflame

No, cotton was right. The guy pretty much is a retard.

+Inf

Revision 1720

wxgui: retooled exception handling, should eliminate warnings in GCC and remove

previous initialization ambiguities. (ended up being a nice code cleanup too,

yay)

Revision 1721

microVU: Normal clamp mode clamps a little more stuff (fixes some very rare sps

I found while playing kingdom hearts)

Autor...

Cool Thanks

Rhei...

Hi cottonvibes , the commits so far have not fixed it but I have taken some screen shots and maybe they can help you determine what is going on.

good/odd 1

http://i25.tinypic.com/9rhbeo.jpg

http://i31.tinypic.com/28ti0sm.jpg

good/odd 2

http://i26.tinypic.com/10pc6xh.jpg

http://i29.tinypic.com/fbf337.jpg

pcsx2gu...

That looks like the usual GSdx transparency bug and probably has nothing to do with microVU...

Rhei...

it only happens after using r1710 the ones before it are fine. and the only thing that changed at that point is the microVU stuff so it seems at first the logical choice. Also one of his commits did fix some of the graphics issues so ya...

cottonvibes

Rheikon:

I'm going to have to get FFX2 sometime this week so I can debug it and find out whats wrong.

Bositman: Rheikon said the game broke when i enabled mVU macro by default.

If you have the game can you also confirm this for me?

pcsx2gu...

Will do, seems this one has to be added to my permanent ISO game list since it loves to break :P

kaboo...

pcsx2guide == Bositman ???

nice²

I think I'll go and test it too since I wanted to test macro anyway^^

less SPS is always better^^

pcsx2gu...

Yeah stupid google code does not late you change username, it just uses the prefix of your gmail address, which sucks.

kaboo...

I have the same problem with FF-X2 exactly

Rhei...

good to know it is not just me. Also my bad calling it micro when its the macro stuff that was changed :/

cottonvibes

when i change clamping it also effects mVU macro stuff (because both mVU macro and micro use the same opcode implementations).

I'm not sure if the FF-X2 problem is related to clamping or not though...

Rhei...

Well when i turn the VU recs clamp to none the screen starts flashing strangely but you can see the missing parts again. they still however show in front(ontop) of everything else. If i put clamping up higher the globe and some other stuff in the bridge is compeltly gone. By the elevator the two lights inside it are atleast aligned properly it seems but the ones not behind anything do not light up still and the one set that does still shows ontop of everything else.

ramapcsx2

SUB opcode again. Must be some flag handling :p

Revision 1722

Quick fix for GCC versions 4.2 and earlier, which lack the __COUNTER__ define.

Revision 1723

Command line fixes ( Issue 331 ):

* I had incorrectly documented -usecd as -usecdvd (oops)

* Skipbios now defaults to OFF is was intended

Revision 1724

Issue 331 - let's also fix the "double initialization" issue when booting cdvd

plugin from the commandline.

Revision 1725

wxgui:

* Improved thread safety of file logger (needs work yet)

* Debug builds automatically open the console log during the first time wizard.

* Added terminal logging to linux builds.

* Linux: Bugfixed plugin configuration dialogs being unable to receive input.

Revision 1726

microVU/macroVU: When subtracting a reg by itself, its safer to just set the reg

to 0, instead of actually doing the floating point subtraction.

This fixes the problems in FFX2 introduced in r1710.

Also thanks to rama who found out it was SUB that was breaking the game. (Saved

me a lot of debugging to narrow down the problem ;p)

Rhei...

yep it is all fixed now. nice job!

kaboo...

let's hope this doesn't break something^^

cottonvibes

nah it shouldn't break anything.

any number minus itself should be zero.

this doesn't always happen in floating point arithmetic though, because of NaNs/INF.

pcsx2gu...

Nice :) So how do you catch the cases where the number is Nan or Inf and you have to subtract it by itself? Just set it to Nan/Inf instead of 0?

Jake.Stine

On the PS2 Nan/Inf are just normal numbers, so they end up as zero. This may have very well been the issue. Under IEEE:

Inf-Inf = Inf

Nan-Nan = Nan

On the PS2, both would equal zero.

kaboo...

thanks for the insight guys +1

gigaherz

The only issue here would be WHICH zero? (-1)-(-1) = -0 or +0?

Jake.Stine

Does the PS2 have +0 and -0? If it doesn't have NAN or INF, I'm not sure it would have +/-0 either.

gigaherz

Well +-0 are "necessary", cos the sign bit is independent of the value. It's anther question if it considers this bit in its calculations in a predictable way.

One test would be if 1/(-0) gives -MAX or +MAX, and I would guess it goes to -MAX like a normal fpu woudl go to -INF, ... but oyu never know unless you try :P

Wagnar...

Thanks working perfectly.

You guys are brilliant !

cottonvibes

The ps2 does have positive and negative zero.

I know that (-0)-(-0) = +0 though on the ps2.

I assume its the same for all negative numbers subtracted by them-self, but I'm not 100% sure since I haven't tested.

kigar...

This is also fixed several bugs in FFX like not showing land on the map (upper-left corner) when moving through some locations, like north side of Thunder Plains or Calm Lands from center to Monster Arena. And missing animation like in the beginning of summoning Anima (just black screen instead of sky). Also probably some other screen flickering, but don't remember where it was.

Revision 1727

wxgui:

* Added /gui/AppRes.cpp : contains resource management code that used to be in

/gui/App.cpp.

* Redid disk/linux console logging to be both thread safe and crash-safe.

* Cleaned up plugin init/open exception handlers

* Was forced to implement a manual version of wxEventLoop because of a critical

design flaw in wxWidgets' message loop exception handler.

arcum42

Looks like it's giving me issues with the new code in main.cpp.

In member function 'virtual int pxEvtLoop::Run()':

pcsx2/gui/main.cpp:337: error: 'm_shouldExit' was not declared in this scope

pcsx2/gui/main.cpp:340: error: 'OnNextIteration' was not declared in this scope

I'm assuming this has to do with both being protected members of wxEventLoopBase...

It also doesn't like passing wxStrings to fputs, but that part's easy to fix... ^_^

Jake.Stine

To detail the exception handler foopah of wxWidgets ... wx has four main tiers of message loop handling:

* The EntryPoint (called once per app)

* wxApp::OnRun() (called once per app)

* The MainLoop (called once per app)

* The EventLoop::Run procedure (called from many points, including modal dialogs and stuff).

EntryPoint has an exception handler that performs a catch-all (...), and runs OnExit(). This ensures proper cleanup of resources on unhandled exceptions (good!).

wxApp::OnRun() is what you're *supposed* to override if you want to implement your own custom exception handling. Fair enough, except read on:

MainLoop simply defers to EventLoop::Run. It's purpose is probably to give platform specific implementations of wxWidgets an opportunity to do differing OnRun setup code (which should be in the always-platform-specific Entrypoint handler anyway, so it's pretty well useless).

EventLoop::Run() performs the meaty goodness of dispatching messages (the heart of any user interface). And here's the problem. EventLoop::Run contains a catch-all (...), that *mandates* the execution of OnExit().

Translation: My exception handler in OnRun() was useless, because the exception handler in EventLoop::Run() was already doing OnExit() cleanup, under the assumption that the program was going to terminate itself. But I didn't wnt the program to close. I just wanted to popup a dialog and move on in life. And since there was no way to disable that exception handler, I had to write my own EventLoop::Run from scratch based on the wxWidgets source code.

Jake.Stine

Protected members should be fully accessible. Only private members would be inaccessable :/

arcum42

Correction: I'm assuming it's doing this because gcc hates me...

Jake.Stine

Anyways I'm compiling locally here to see what I can figure out.

arcum42

Cool.

Make sure to change:

fputs( L"PCSX2 > ", stdout );

to:

fputs( "PCSX2 > ", stdout );

in ConsoleLogger.cpp...

Jake.Stine

Ok, in looking I realize that the EventLoop::Run function is much more platform specific than I thought. I'm actually better off hacking out the exception handler from PCSX2's local win32 version of wxwidgets. Why?

*The GTK Version doesn't have the same problem!* It only has a catch-all in the Entrypoint code, as it should. Nothing in the message handlers.

This further confirms my suspicion that this is in fact a bug and not a feature.

Jake.Stine

And my previos rant is unjustified. Turns out there's a HandleEvent override designed for handling exceptions at the message level. Of course the docs told me to use OnRun(), which is where the whole mess started. Thankfully I stumbed across it in continued browsing of the wxWidgers sources.

arcum42

Hate when the documentation turns out to be wrong or outdated...

Revision 1728

wxgui: better fix for universal message-level exception handling.

Jake.Stine

This should fix Linux compilation errors. Lemme know if not.

arcum42

That did it...

Jake.Stine

isn't this fun? :p

I'm still not sure what to think on that plugin enumeration crash. I doubt it's a threading issue since it's isolated to a specific plugin. And the only things being run are PS2getLibType/Version/Name. There's really no possible chance for corruption *except* at the stage of loading the DLL itself (which is an operating system action).

Anyways my suggestion is to comment out everything except the code that actually loads the plugin, and see if the crash persists. If so, then the next step will be de-threading the enumerator and seeing if that fixes it.

I purposefully threaded the enumerator because it's a "heavy" action to thread, and was a good test of wxWidgets thread safety. I didn't run into any problems here so I thought we were in the clear. I'll code in an #ifdef to dethread it, so we can test without.

(tho really typically threaded crashes are much more random than even this -- ie if it were really related to threading you should have a reasonable chance of complete success .. but it always crashes, which seems to point to something else)

arcum42

I've been adding Logging in virtually everywhere, to try to see exactly where it crashes. Which is driving me stir-crazy. Of course, I still haven't really been able to dedicate as much time as I like to it. That'll change when I get to Thurs.

And, yeah, it'd be bizarre for the threading to be killing it predictably. It'd make more sense if it was loading bad data into a combo box or something...

Revision 1729

pthreads: Added <excpt.h> to pthreads.h since SEH requires it; Added versioning

to the project/output filename (currently V2, which is SEH-enabled)

Jake.Stine

The SEH version of w32pthreads should be fully compatible with any other MSVC-compiled binary, whether it be C or C++, SEH or not. SEH is conveniently flexible in that way :)

Jake.Stine

also, forgot to mark this as wxgui branch specific, which it is.

Revision 1730

wxgui:

* Fixed thread classing so that detached pthreeads are handled safely, and so

that virtual functions in C++ destructors are explicitly specified.

* Added some helper functions to Pcsx2App for safely executing menu commands

form any thread in the emu.

* Fixed several minor bugs in settings / config handling.

Jake.Stine

@arcum: This revision may fix linux thread crashing problems. I'm pretty sure there were some issues with the thread class referencing detached threads by handle -- which is bad because once the thread is detached the pthread_t handle becomes invalid.

arcum42

No such luck.

In fact, actually, it now crashes if I choose "Current Working Folder". The line:

if( UseDefaultSnapshots ) Snapshots = PathDefs::GetSnapshots();

seems to crash it in the Apply statement in Paths.h, for some reason.

Of, gcc didn't like Panels::g_ApplyState.ApplyAll(), so I just set it to Panels::g_ApplyState.ApplyAll(true). Beats me why, though, since I saw that true was supposed to be the default value...

arcum42

(Just to mention, it crashes in the normal spot as well. This was just a new spot...)

Jake.Stine

Ugh. There's got to be something wrong with your wxWidgets library build. :( The only conceivable way code like the Snapshots assignment could be crashing is if wxString is unstable or thread un-safe -- which would be the case if wxWidgets isn't built with wxUSE_STL 1

I can't think offhand of anything else that could instigate crashes like that. I'm not even using any threading stuff in that first panel at all.

I'll check my linux build here, but I have a hunch it's going to work fine >_<

arcum42

I think I'll try downgrading my copy of wxwidgets a bit, and fiddling with the options to see if it makes a difference.

I could be an unstable copy of the library. We'll see.

Come to think of it, what version of wxwidgets are we using on the windows side?

Jake.Stine

The Windows side uses 2.8.10.

The ApplyAll thing is some kind of GCC bug I guess. If I import the Panels namespace and remove the Panels:: qualifier on the call, it fixes the error. No way that should make/break default parameterization tho.

(unless the C++ Standard somehow defines this behavior, in which case I will lose whatever minimal amount of lack-of-disdain I have left for the C++ standard ... I'd say "minimal amount of respect" but I stopped respecting it a while back and I now measure my opinion only in synonyms of dislike.. lol)

Jake.Stine

ok the good news (?) is that I can reproduce the Settings crash here in Linux. Still haven't a clue what could cause it since I'm pretty sure I didn't change anything related to that area of the code. But who knows.

arcum42

I'm assuming gcc bug, because that *should* have worked...

And I rolled back from wxGTK-2.8.10.1-r3 to wxGTK-2.8.10.1-r1. Not sure why Gentoo calls the package "wxGTK", but the version scheme for Gentoo packages is basically <program-version>-<package-version>.

That took care of the weird Snapshot thing, though the other behavior is still there.

Think I'll mask off the other version, so I don't accidentally reinstall it...

arcum42

Either that, or if you're able to reproduce it, something fixed it without me noticing. I'll have to fiddle with it; see if I changed something without noticing it.

arcum42

I'm recompiling with the other version to see if that's honestly what the difference was.

Jake.Stine

I had it crashing here for a bit, same spot.. and after I made 2-3 changes and undid them, it didn't crash anymore. I think this is a GCC bug somehow that is (was) fixed by forcing a full rebuild of sources. Specifically, FirstTimeWizard.cpp needed to be rebuilt I think.

Jake.Stine

Well not so much a bug as a missed dependency, so important files weren't getting recompiled and were using mismatched structure/header data -- causing oddball crashes.

arcum42

Yeah, I did a full rebuild in there, too, so that's probably what it was. I thought it might have been the library because I spotted what looked like a bug in the ebuild for the later of the two versions, that I thought might have prevented some patches from being applied when it was built.

Glad that wasn't the issue... :)

Jake.Stine

Indeed. Now only remains the stack corruption crash in the plugin enumerator that I can't seem to reproduce, that's apparently only caused by ZeroGS/ZZogl. That one's got me stumped. I'll include a de-threaded version of the enumerator and hope that works, but who the hell knows :p

arcum42

Even if it doesn't, it'll probably give us a better idea of where the issue is, at least.

I've just been going over some of the changes I had sitting in my copy of the normal branch, looking for bugs, and trying to decide whether to commit them or wait till after the merge.

Mainly because I needed change gears for a few hours before going back to wxgui...

Revision 1731

Relaxed loadstore cycles a bit on the EE.

This hopefully lets a few regressed games work again.

Also a speedup, specially in fmv..

Autor...

Increase cycles, thanks few fps here and there :D

saku...

FMV speedup, good!!

lemuel2010

Good :)

Revision 1732

Minor changes to how the commandline auorun feature works, so that it

initializes in the same general order/pattern as using the GUI. May fix some

spotty problems.

heatbla...

Long time no see. I`ve had a lots of jobs to do. I`ve tested the latest revs and I have to report that the bug from Devil may Cry when jumping and fall into the terran glitch i s gone.

I`ve tested Romancing Saga - good begining, but when finishing with creating the character and when you start - it freezes.

I`ve testet Steambot Chronicles - crashesh as usual.

I`ve testet Mana Khemia 2 - perfect for playing.

Hope it was helpful, keep it up guys!!!

eve...

r1708-1713 some of them broke the ICO, in the second room, the camera flies up. clamp configuration does not help. sVU & mVU same.

Revision 1733

Might as well copy some register code from GSdx to GSnull, so I have a starting

place on register handling in it.

arcum42

One of these days I want to get GSnull so that it handles everything a normal GS plugin handles except actual graphics, and it's easier to do that if I already have the register information in there.

The changes I had to make to the code to get it to work in Linux should be a good reference for any ports of GSdx in the future, too...

Revision 1734

Added more logging to the plugin management process (init/open/close). Added

SVN_REV info to the console log.

alifrahm...

PCSX2 0.9.6 - compiled on Feb 27 2009

Savestate version: 8b400004

x86Init:

CPU vendor name = GenuineIntel

FamilyID = d

x86Family = Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz

CPU speed = 1.797 Ghz

Cores = 2 physical [2 logical]

x86PType = Standard OEM

x86Flags = bfebfbff 0000e39d

x86EFlags = 20000000

Features:

Detected MMX

Detected SSE

Detected SSE2

Detected SSE3

Detected SSSE3

Not Detected SSE4.1

Hotkeys:

F1 - save state

(Shift +) F2 - cycle states

F3 - load state

Resetting...

Ready

Bios Version 1.60

**************

rom2 NOT FOUND

**************

**************

erom NOT FOUND

**************

Framelimiter rate updated (UpdateVSyncRate): 59.94 fps

MTGS > Thread Started, Opening GS Plugin...

MTGS > GSopen Finished, return code: 0xffffffff

Revision 1735

Patch r1734 for Linux.

arcum42

Linux doesn't use svnrev.h. It does, however, import SVN_REV in the build scripts...

Jake.Stine

Is the SVN_REV auto-determined from the repository, or does it have to be manually specified? As far as I remember, the subversion commandline tools for checking revision info are pretty crude. I don't think they do proper recursive revision checking, unless you make a script to it. But maybe that was fixed in a recent subversion update?

arcum42

I added this code to configure.ac a while back:

svnrev="`svn info | grep Revision:`"

if test -n "${svnrev}" ; then

AC_REVISION("${svnrev}")

AC_DEFINE_UNQUOTED(SVN_REV,"${svnrev}",

[Define to be the subversion revision number])

else

AC_REVISION([$Revision: 0 $])

AC_DEFINE(SVN_REV,"$Revision: 0 $",

[Define to be the subversion revision number])

fi

So Linux gets SVN_REV from there...

Jake.Stine

Admittedly, that's totally incomprehensible to me. ;)

But yeah it uses svn info. The drawback of svn info is that it gives the same revision number for all subfolders. So PCSX2, plugins, etc. all get r1735, even if the plugins haven't changed since r900 or something. It's not a big deal but it is a difference from the win32 build method that you'll probably want to be aware of.

Jake.Stine

Oh good news! You can grep for "Last Changed Rev" instead of "Revision". That'll allow you to match the Win32 SVN_REV monikers. That's apparently new, but it should be in subversion 1.6 or above.

arcum42

Yeah, I'm aware of it. Never got around to having the Linux version of the plugins track svn version anyways, though...

arcum42

That might be worth changing. I can always fall back on the old behavior...

Jake.Stine

Yeah.. having it incorporated into wx branch would of course be most useful. I assume it would be the same basic idea except done as a pre-build step or something.

arcum42

Presumably. I haven't played with the build features in codeblocks much yet. I'll have to look into that.

Revision 1736

Some more changes to use dmaRegs and gifRegs in various places.

arcum42

dmacRegs, that is.

arcum42

Forgot to add a few jNO_DEFAULTs in here. Not a bit deal; I'll add them later. They aren't really needed here, anyway, it's just good practice.

I'll probably be doing passes like this periodically. It'll take quite a while to get all the old code converted over, and occasionally it might be easier to keep the old version...

Revision 1737

wxgui:

* Redid 'Run' menu as separate 'Boot' and 'Emulation' menus (implementation is

still spotty as always)

* Fixed some more bugs in config/settings Dialogs

* Fixed a nasty bug in memory cards (no more magic memorycard deletion, yay!)

* Renamed a lot of variables, because I just like refactoring code...

* Fully implemented emulation commands: Pause, Close, Reset.

(no it still can't do anything more than boot the bios, yet >_<)

Jake.Stine

Still planning to dethread that plugin enumerator. Just had some other things on the list to finish up :p

arcum42

No worries.

I just got my keyboard working on the bios and boot loader screens again, so I've been busy booting into other partitions I haven't been able to access for a few weeks...

Revision 1738

SPU2-X:

5.1 support is back!

Currently for XAudio2 only, and it's not doing much (Simple copy of the stereo

source to the other speakers).

Gigaherz is already working on a nice, semi - prologic II upmixer though ;)

Jake.Stine

Too bad it never left for me :p

ramapcsx2

Yeah, the mystery never stops :p

Revision 1739

SPU2-X:

Fixe the dsp (winamp plugin) crashes. Thanks to Gigaherz for this one, too :p

Revision 1740

SPU2-X: Minor cleanups and updated DLL/resource versioning info (which never got

updated for v1.2, oops)

u...

It needs correction to savestate code, if you wanna stick to pre-wxgui release.

Thanks.

Here is a patch.

Index: RecoverySystem.cpp

===================================================================

--- RecoverySystem.cpp (revision 1740)

+++ RecoverySystem.cpp (working copy)

@@ -252,7 +252,7 @@

u32& pluginlen = *((u32*)g_gsRecoveryState->GetPtr(0));

u32& gslen = *((u32*)g_gsRecoveryState->GetPtr(pluginlen+4));

- gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4), gslen );

+ gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4 +4), gslen );

}

else

gzSavingState::gsFreeze();

@@ -262,6 +262,7 @@

{

if( (freezer == gsSafeFreeze) && (g_gsRecoveryState != NULL) )

{

+ FreezeTag( name );

// Gs data is already in memory, so just copy from there into the gzip file.

// length of the GS data is stored as the first u32, so use that to run the copy:

u32& len = *((u32*)g_gsRecoveryState->GetPtr());

2 line-by-line comments

/trunk/pcsx2/RecoverySystem.cpp  

r1740  

line 255:

255: gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4), gslen );

Need correction.

Current code raises problem:

# Encountered an error while loading savestate from slot 0.

# Since the savestate load was incomplete, the emulator has been reset.

#

# Error: Savestate data is corrupted or incomplete

# Filename: Tag: mtgs

Maybe good with:

gzwrite( m_file, g_gsRecoveryState->GetPtr(pluginlen+4 +4), gslen );

/trunk/pcsx2/RecoverySystem.cpp  

r1740  

line 266:

266: // length of the GS data is stored as the first u32, so use that to run the copy:

Need correction.

# Encountered an error while loading savestate from slot 0.

# Since the savestate load was incomplete, the emulator has been reset.

#

# Error: Savestate data is corrupted or incomplete

# Filename: Tag: GS

FreezeTag( name );

Revision 1741

wxgui: Test revision for Arcum -- with the plugin enumerator running in a single

threaded model.

Jake.Stine

@arcum: The way it works, it queues up all the gui messages still during ExecuteTask(), so none of the messages are handled until all plugins are enumerated and control is returned to wx's message loop.

arcum42

All right, got the same place, but now I have a location.

The crash is actually in PersistentThread::Cancel, when it gets to pthread_cancel.

And, in fact, I went into Panels::PluginSelectorPanel::OnEnumComplete, and commented out safe_delete( m_EnumeratorThread );, and all the plugins showed up without a segfault.

arcum42

Of course, it then segfaulted when I click finish, and once I open it back up, if I choose plugins, it segfaults when I hit ok. But then, commenting out safe_delete is a workaround, not a fix.

Still, means I can play with pcsx2 a bit more in the wx branch.

Jake.Stine

That crash in safe_delete is unrelated, actually. I kind of half expected it to crash in win32 here, but since it didn't I went with it. The calls to pthread_join/pthread_cancel are using an uninitialized thread handle, since I never create the actual pthread. w32pthreads does a sanity check on the thread handle before diving off a cliff tho, so no crashes here.

Jake.Stine

Finish and Ok are also segfaulting for the same reason, most likely. The thread is canceled out from the destructor of the dialog box as well from OnEnumComplete.

So my guess is the unthreaded version works fine. I just need to correct it so that it checks the pthread handle for validity before trying to join/cancel it.

I checked the thread safety rules on loadlibrary, and it's supposed to be thread safe. But on the other hand, Linux doesn't apparently have thread safety on libc implementations, so that could be an unforseen complication.

arcum42

Yeah, it seems like it's working without threads.

I tried inserting a thread-check, but it crashed on the threadcheck. :(

Inserting a few 'if (!DisableThreading)'s around got rid of both crashes, though.

Revision 1742

wxGui: Lets not delete the Enumerator thread if we aren't threading it.

Revision 1743

wxgui: improve single-threaded plugin enumerator for Linux (still a bit buggy)

Jake.Stine

Somehows the plugin enumerator manages to crash Xming on my CoLinux install with relative certainty when trying to enumerate in single-threaded mode (sigh). Seems to work fine in threaded mode. So I'm committing what I have, and I think it should work, and I'll double check it in windows.

arcum42

Without the if (!DisableThreading) safe_delete( m_EnumeratorThread );,

it still crashes for me in PersistentThread::Cancel.

Now, if you add:

if( !m_running ) return;

to the beginning of PersistentThread::Cancel, that's enough to get it working for me. Don't know if I'm messing anything else up by doing that, though.

Jake.Stine

Woops, yeah that was supposed to be in there.

arcum42

Figured, since you did that for PersistentThread::~PersistentThread, and it looked like the point of that variable was to keep track of whether the thread was started or not.

BTW, I was noticing the VU Clip Flag hack was missing from the list of game fixes. Is it being taken out, or does it need to be added?

Jake.Stine

I think it needs to be added. Initially I was eliminating sVU-only hacks since I was hoing to discontinue sVU support, but it's still wanted by cotton and rama. :)

arcum42

All right. I was thinking of adding it back in, but didn't want to do anything that would have to be undone. Don't think they're hooked up right now anyways.

Wonder if I should add in the Mana Khemia hack in, while I'm at it? I'd like it in, but I don't really want too many game fixes in there...

Main issues I've noticed right now are that Linux will not load the bios (as far as I can tell, it's being fed '/' for the plugin paths; something went wrong around LoadPlugins, I think), and that the bios path doesn't change when you change the main path.

In fact, if you play around with it enough, you can get the same bios listed twice in that window. :)

Jake.Stine

Mana Khemia .. I think that was another sVU specific hack? I know one or both of them were anyway.

Jake.Stine

On LoadPlugins: Chances are the plugin paths aren't being save or loaded from configuration ini correctly, and so they're probably duds when it goes into LoadPlugins.

On BIOS: No clue. Haven't toyed with it that much. :p Admittedly I'm not a huge fan of wx's implementation of the wxDirPickerCtrl. It has some odd behaviors.

arcum42

Mana Khemia is a Mpeg.cpp hack; it's related to the coroutine mess.

In the function mpeg2sliceIDEC, it keeps track of whether so_resume() has been called, and if it hasn't been called by the end of the function, calls it before finishmpeg2sliceIDEC.

It fixes Mana Khemia's crashes when going outside, and breaks Digital Devil Saga. It's a hack I came up with as an alternative to an earlier hack that just caused mpeg2sliceIDEC to never be called. Right now, to enable it, you have to uncomment a define in Mpeg.cpp.

The main reason why I've wanted to make it a gamefix is that right now, a number of people have hacked copies of pcsx2 specifically for that game. It's easier to manage if it's in the official version. (And, admittedly, it makes it easier for me to play Mana Khemia. ^_^)

Loadplugins: I'd assume loaded from, because the paths look right in pcsx2.ini.

Bios: Not sure either. I noticed because I switched it to local directory on the main screen, and it was still pointing to ~/pcsx2/bios on the bios screen till I checked and unchecked it. Not a big deal, though.

Revision 1744

wxgui: Add in a missed check on the threading. Update the game fixes panel.

Revision 1745

wxgui: Runs games. 'nuff said.

* Fixed some deadlock conditions by adding a message pump to semaphore waits

ont he main/gui thread.

* Many more config and init bugfixes.

* Implemented most of the new Boot menu.

Jake.Stine

Lots of issues still like, for example, no keyboard input, no working savestates, some crashes on exit, etc.

But besides that, it's pretty nice-workin.

arcum42

Hmmm...

Doesn't look like isoFilterTypes is defined anywhere. I'm assuming it should be something like:

const wxChar* isoFilterTypes = L"*.iso;*.bin;*.dump";

?

Jake.Stine

Oops! I deleted it by accident just before I committed. Will up in a second.

arcum42

No problem. I'm still trying to figure out what's wrong with the paths, anyways...

arcum42

As far as I can tell, BaseFilenames.Plugins[pluginidx] is returning '/' under Linux. Doesn't seem right...

ramapcsx2

Milestone! :p

Revision 1746

wxgui: removed dependency on afxres.h, added resource/manifest versioning info

to w32pthreads.v2.dll, and fixed a compile error.

Jake.Stine

Keep forgetting important things... >_<

Revision 1747

wxgui: bah msvc and its tendency to save everything *except* vsprops files when

you do a Save All.

Revision 1748

wxgui: my excitement in getting a game to run for the first time in months

clearly has shattered my ability to commit.

Jake.Stine

Still missing files here too.

arcum42

Some days you just can't win... :(

Revision 1749

wxgui: fail.

crushtes...

patience...

shadowladyngemu

win :3

Castrat...

I remember gabest going on a similar spree before mysteriously vanishing-

Revision 1750

wxgui: minor plugin binding fixes; this gets Linux booting to the point that it

gives me the standard "OpenGL Fail" error (co-linux limitation)

arcum42

All right, I was able to boot into the bios with this revision, though the graphics were mangled.

Also, I had to go to the pcsx2 plugin screen before it would boot; it must not be enumerating them before that.

Telling it to run any iso also boots the bios. ^_^

arcum42

Note: it has to be run from the command line, and not from codeblocks to actually have the ZZOgl window come up.

(And, of course, the GSnull plugin should work just fine in CoLinux, though you won't see anything. You could probably hear the bios sounds, at least... )

Jake.Stine

Yeah the plugins are currently loaded on the Core thread, which is probably bad. My next commit will have PCSX2 load them on the gUI thread instead, which Linux should be happier with. ;)

arcum42

Given that gtk is picky about threading, that's probably for the best.

Irritating thing on not loading the iso is that it displayed the full location of it in the menu, so I know it knows where it is...

Jake.Stine

Currently everything boots through the BIOS. Tho if you still get the BIOS menu and no recognized DVD image, then that's a problem. If you get a memorycards + DVD screen (and you can try and re-run the DVD) then it means your bios doesn't like your DVD image -- like a PAL/NTSC incompatibility that might happen with v2.0 bioses.

Same thing should happen on regular old trunk pcsx2 tho.

Jake.Stine

Oh! And is Linux on your side reporting complete bupkis for CPU speed and core counts? I'm not sure if the crap values I'm getting are because of co-linux or something else.

arcum42

No, they look about right.

And looks like it was just the "configure your bios" screen that was screwed up. Wouldn't be surprised if that's screwed up in the main branch, too.

I think it wasn't loading the isos because I hadn't set that up (since I didn't realize it was going through the bios right now.)

Now that I set it up, it segfaults, instead. Time for me to check the segfault handling code...

arcum42

On second thought, given the message, that's in place. I'll try a different game.

arcum42

Heh.

It was game specific. Guess Baroque doesn't like being booted through the bios. Disgaea started up without an issue.

arcum42

BTW, I suspect before the merge that it'd be a good idea to tag the current main branch...

Oh, and exiting pcsx2 or resetting pcsx2 segfaults, btw, but I think you knew that.

The one on exiting is in ProgramLog_PostEvent when checking to see if m_ProgramLogBox is NULL. Got to love it when it crashes on safeguards meant to prevent it from crashing. I'd presume it's trying to do something with the console window after it's gone...

arcum42

Yeah, it's trying to do something with the console *after* ~Pcsx2App was called.

arcum42

Specifically, it's trying to do the SysReset in ~Pcsx2App, which has a console message in it.

Jake.Stine

>> The one on exiting is in ProgramLog_PostEvent when checking to see if m_ProgramLogBox is NULL. Got to love it when it crashes on safeguards meant to prevent it from crashing. I'd presume it's trying to do something with the console window after it's gone...

Close. It's actually trying to do something with the wxApp and it's been deleted too by then. ;) I can add a test against wxTheApp != NULL and fix it.

arcum42

Yeah, changing:

if( m_ProgramLogBox == NULL ) return;

to

if ((wxTheApp == NULL) || ( m_ProgramLogBox == NULL )) return;

in ProgramLog_CountMsg and ProgramLog_PostEvent does the trick.

fullw...

hey Jake, I was wondering if you're going to resume your work on the R3000 Air compiler after wx?

Revision 1751

wxgui: sync with trunk (microVU + ee loadstore cycles + improved plugin

logging).

* Fixed crash on exit, caused by logging.

* Updated versioning in main window and console.

Revision 1752

wxgui: Hack in game fixes support. Fix a few minor compiler warnings. Fix Linux

after the last revision...

arcum42

Sadly, I tested the game fixes by verifying that turning one of them on breaks one of my games... ^_^

arcum42

And, yes, there are better ways to do the game fix support. For example, if we had the game fixes set up as a union as well as bit flags, the code to set a game fix could have been one line...

Jake.Stine

All of the options should be unions, in fact. I used handy macros to define them as such. :)

And I see that I haven't added the EmuConfig to AppConfig, so the emu options aren't being managed correctly by the App yet anyway. I'll get that fixed in a bit. (yes there will be 2 copies, the global one used by the emulator, and a local one managed by App hich it "applies" to the global EmuConfig only once the emulation state has been safely suspended and such).

Also I created some wikis for basic wx coding guidelines and stuff. I'll get those posted now. :)

arcum42

Oh, right, like the ones in GSdx. Didn't notice that.

Oh well, this works for the moment. We can always recode it later.

My main motivation for changes to it is to make it easy to add and get rid of game hacks. The fewer places you have to change for it, the better...

Revision 1753

wxgui: Get the savestate menus ready to be hooked up.

arcum42

While I didn't actually hook it up, everything's ready for it. I figured that if hitting Reset crashes pcsx2 right now, hitting save would, too, so I didn't bother.

But the codes all there, and even picks up on which savestate to work with.

And I arbitrarily changed the number of savestates in the menus to match the number available through the function keys. Since the f-keys aren't available right now, it seemed appropriate...

arcum42

Just realized that I forgot to remove the (id == -1) stuff. It isn't necessary; I figured out what I'd been doing wrong, but forgot to remove the check...

Jake.Stine

1 line-by-line comment

/branches/wxgui/pcsx2/gui/MainFrame.cpp  

r1753  

line 200:

200: ConnectMenu(i, Menu_LoadStates_Click);

wx has built in range support in Connect(), so you can do this instead of using for():

Connect( MenuId_State_Load01+1, MenuId_State_Load01+10, wxEVT_COMMAND_MENU_SELECTED,

wxCommandEventHandler(MainEmuFrame::Menu_LoadStates_Click) );

We should create a ConnectMenuRange macro for it since we're using it a bunch now (there are three other instances at the top of ConnectMenus)

Jake.Stine

My first line-by-line didn't really come out like I wanted. I wanted line 199 and got 200. But it was fun to try! heh

arcum42

Ah, right. Hadn't had to do that before, and the docs are pretty slender on Connect...

Revision 1754

wxgui: Fixed a crash when configuring the Firewire plugin from the Firewire

menu.

Revision 1755

wxgui: Get the speed hacks squared away.

arcum42

It was functional, but the sliders weren't working properly on the top, and the checkboxes would clear themselves. Both have been taken care of.

Revision 1756

wiki: Added new pages for wxWidgets tips and other coding guides/strategies.

Jake.Stine

The Translation Guide is effectively a draft, but since I was committing several wikis at once I figured I'd roll it on in, so that we can see it as it is.

Revision 1757

wiki: Added some links and minor fixes to the RevisionReviewEtiquette

xat...

Just some minor grammar/spelling stuffs:

line 4: it's->its

line 12: an->and

Revision 1758

wiki: Fix unicode quotations, which showed up properly in the wiki preview box

but broke once the wikis were put on svn. >_<

Revision 1759

wxgui: Some quick cleanups of my earlier commits.

arcum42

And with that, I'll stop committing for a few hours...

Jake.Stine

My next commit will probably break linux, because I'm removing the .h files for bundled images and setting up a script to generate them from the .png/.jpg originals. As soon as that's committed, I'll swap branches, and then we can work on getting the scripts re-set for Linux.

(shouldn't be hard, the build script is very simple, a 2-line bash script do the job)

arcum42

All right. Seems like we could just make an image directory, and load them dynamically, though.

Jake.Stine

I don't really like that method because most of the images are pretty well fundamentally important to the emulator's running, and especially as we fancy up the GUI more with toolbar icons and such it will be more important to have built-in resources.

Right now the only things *needed* to have PCSX2 load are:

PCSX2.exe

w32pthreads.dll (win32)

null plugins

Everything else is pretty well optional.

For example, it really annoys me when some programs "Require" language files and then if for some reason my english language file is missing or is outdated I get crap messages like "@5012" instead of text. And likewise I'd rather not have the PCSX2 gui come up blank as a white chalkboard if, for some reason, it can't find the resources needed for icons, background, and other GUI buttons and stuff. :)

arcum42

There are points to that, I suppose.

I suppose I just like things easily skinnable. I could see the potential issues with the way it can be configured to look for files, though.

Jake.Stine

Oh it's already going to be skinnable.

In fact if you drop resources into a resources folder of some naming scheme I forget immediately, I'll use those instead of the built-ins. :)

arcum42

Ah, so these, essentially, are the default images. Cool.

You know, it wouldn't be that difficult to set it up so that you could have multiple skins, and choose between them in pcsx2.

Not high priority, but could be fun. We could include some of the runners up to the background that won that way...

Revision 1760

wxgui: Updated to the new logo and about box pic (about box layout still sucks

tho). Redid the built in resources so that they're automatically compiled from

the original images, instead of having the bulky .h files on SVN (includes

updates to bin2cpp tool).

Revision 1761

wiki: uploaded images for a new compilation guide (work-in-progress) as provided

by n1ckn4m3. :)

Revision 1762

Goodbye old GUI. For you served us well!

... well not really.

Jake.Stine

I'm upping the new merged trunk now. It'll take a while tho (possibly up to an hour) because of all the changes and my slow upstream. >_<

arcum42

No worries.

I just did the minor changes necessary to port bin2cpp.cpp to Linux. _stat to stat, _fcloseall to fcloseall, and replacing strupr, really.

I did contemplate rewriting it in Ruby for a few minutes, but decided I didn't really need to add a dependency, even if it would look nicer...

arcum42

And it's up...

Revision 1763

Reintegrated wxgui branch into trunk.

Revision 1764

wiki: Completely re-wrote Windows Compile guide to be current, including all

current dependencies and SDKs, configuration of VS2008 Standard, screenshots of

the process. VS2010 and VC++2008 forthcoming.

pcsx2gu...

Awesome work n1ckn4m3, I'm amazed by the detail and the clarity of your wiki :)

Thanks for the help

ramapcsx2

Awesome indeed.

Revision 1765

wiki: Wouldn't be a first commit without a typo :P

Revision 1766

Get bin2cpp to work on Linux. (Linux compilation is still broken.)

arcum42

Basically, rebuild.sh has to be run before opening codeblocks, or it will complain about a bunch of missing files.

However, compilation will error out on the line:

EmbeddedImage<res_BackgroundLogo> temp;

Claiming that res_BackgroundLogo is not declared in the scope.

arcum42

Because the shell script names them the wrong names, because I based it off the other one. All right, I can fix that...

Revision 1767

Correct the script, so that Linux is compilable. (If rebuild.sh is run before

compiling.)

Revision 1768

wiki: Updated compile guide for Windows to include all instructions necessary to

configure a build environment based on the freely available Visual C++ 2008

Express Edition and enable PCSX2 to run in the debugger of it.

Revision 1769

pcsx2:

Made mVU Macro ON by default again (got turned off by wx merge).

Added microVU speedhacks to GUI.

Deleted microVU_Alloc.h from project file.

Note: No speedhacks appear to be working yet during emulation.

cottonvibes

Forgot to mention I Added microVU_IR.h to the VS2008 project file.

Revision 1770

Fixed a crash when clicking "Exit" while emulation is in progress.

Revision 1771

Created project files for all the null plugins, and added them to codeblocks.

arcum42

These haven't been extensively tested, beyond being sure they build.

And I haven't gotten them set up for Windows, though Code::Blocks is cross-platform, and could theoretically be used for both.

arcum42

Still have to do this for the various Linux plugins that actually do things.

I already did OnePad, and tried on ZeroSPU2, but didn't get it picking up on soundtouch properly.

I'll probably create a project file unofficially for ZZogl at some point, after I do ZeroGS, and send it off to Zeydlitz, if he doesn't do one first.

Revision 1772

Reanming Tools to tools (better fix this now while the folder is insignificantly

small)

arcum42

in case you're curious, I didn't even bother with a makefile to compile bin2cpp.cpp. I just typed:

g++ bin2cpp.cpp -o bin2cpp

at a command prompt. ^_^

I figured with such a short program that there really wasn't a need for anything more elaborate then that.

Jake.Stine

Yeah, I noted .. but I couldn't really put the neat "dependency" check mark in the pcsx2 project file so that it'd automatically get rebuilt as needed. Except apparently it doesn't work anyway in Code::Blocks. Oh well.

Revision 1773

... and because svn can't do direct casing changes, it requires 2 commits. -_-

Jake.Stine

I'm going to fix the linux build system now. I have a plan!!

arcum42

A cunning plan? ^_^

Revision 1774

Linux: Using Code::Blocks Custom Compile option to generate embedded resources

now. :)

Jake.Stine

Ok, I set bin2cpp to be a dependency of PCSX2, but it didn't seem to want to work for some reason. Not sure why. So bin2cpp might not be automatically built as it should, prior to PCSX2 being built. In that case manually build it. ;)

But it would be nice to get that part working. Then the whole build should be fully automatic.

Revision 1775

Linux: Remove code::blocks layout files (those are client/user files, not

intended for svn).

Revision 1776

wiki: removed the old compilation guide.

Revision 1777

wiki: and today is the day I learn that I've always misspelled Deprecated as

'depreciated' and didn't know I was spelling it incorrectly.

Revision 1778

* Added preliminary keyboard support back in (probably doesn't compile in

linux)

* Fixed a deadlock in thread cancellation.

* Muted some folder warnings when running pcsx2 for the first time.

Revision 1779

* Implemented Skip Bios (settings still not saved tho)

* Fixed a bug in how I was (not) handling pthreads return codes. It's errno

you need to check, *not* the function's return value. ;)

* Changed MTGS over to use the pthread_cleanup api.

arcum42

Just tested, and on Linux, checking 'Skip Bios' and starting a game results in:

PCSX2 > # Initialize Scratch Pad ...

PCSX2 > # Restart Without Memory Clear Done.

terminate called after throwing an instance of 'Exception::ExitRecExecute'

(Don't have time to fiddle with it at the moment, though, unfortunately...

)

Revision 1780

Linux: Fixes some of those pesky linux compilation errors that keep cropping up.

;)

Revision 1781

Linux: More fixes, because I got impatient and didn't wait for the compilation

to finish last time.

Revision 1782

Got rid of that old 'params' mess on console logs. Not needed anymore since

wxwidgets has nicer built in formatting options (never liked it anyway)

cottonvibes

yeh i didn't like it either xD

ramapcsx2

same :)

arcum42

Yeah, don't know how many times I forgot a param or two...

Revision 1783

Upgraded PCSX2 core and utilities to GPLv3.

pcsx2gu...

Nice. Did you check if updating the GPL conflicts with the license of other open source libs we are using?

Jake.Stine

It's fine with wx, soundtouch, zlib/bzip2, and pthreads. I think that covers all of them.

(actually I don't think there's any scenario where v3 is more limited in license compat than v2. v3 is compat with almost every known open source license while v2 was actually incompat with all Apache licenses and various versions of the BSD license >_<)

pcsx2gu...

OK good to know :P

Revision 1784

Updated to the new icon! So sleek...

Revision 1785

Use right AppIcon.png

Revision 1786

wiki: wxWidgetsCodingStrategies - Added note about sending events properly.

Revision 1787

Added / Changed some descriptions

Jake.Stine

Yay tooltips.

And yes I know tooltips need some text wrapping features. It's on the eventual todo list :)

ramapcsx2

That one ling got a bit long, I know.

Didn't want to screw up the layout :p

arcum42

Actually, with regards to the MPEG Hack, it is already working. I changed it over from the define to the bitfield when I added it in...

ramapcsx2

Ah ok, I just didn't want people to go all like

"Get this wx revision, it has a mana khemia hack!!"

and then it doesn't work :P

Revision 1788

* Better icon! Transparency in Windows Taskbar icon is still bad, but I can't

figure out how to fix it (documented in code)

* Cleaned up the code of the Gamefixes a bit.

* More svn:native props -_-

Revision 1789

Update libpng.

Revision 1790

Fixed Linux up to compile in codeblocks again. Added Onepad plugin project file.

arcum42

And yes, that change to interface.c in onepad is a hack. I figure the next time I change the interface on it will probably be to redo it in wxwidgets, anyways.

Revision 1791

Added libjpeg (version 7!)

Jake.Stine

Obviously this is a Win32-only kinda thing, since these sort of 3rdparty libs usually come in convenient shared linkable form in Linux already.

Jake.Stine

@arcum: I know gamefixes aren't working again I'm fixing it so that the ApplySettings command in CoreEmuThread works as it should, and then applying settings from dialogs will be thread safe :)

arcum42

No problem. I know things are likely to break right now.

While were in the middle of the wxwidget changes is a good time to break safefiles, in fact, if we want to change any of the frozen variables, or get rid of anything legacy.

I know there are a few ints I've been meaning to change to bools for a while...

Revision 1792

Win32 project fixings: Removed the dysfunctional ZeroPAD from the Suite

solution, and cleaned up some options in the wxWidgets projects.

Revision 1793

Implemented plugin override command line options, and preliminary support for

proper EmuConfig ApplySettings.

Jake.Stine

doh, this revision will break configs in Linux >_<

... I was in the process of tring to troubleshoot some odd problems with Lilypad's configuration. Turns out LilyPad uses SetTimer (WM_TIMER stuff) and for some reaosn it's busted in wxWidgets.

Revision 1794

Fix for GSdx's config panel making PCSX2 minimize itself. (also revert

accidental linux config panel breakage)

Revision 1795

May or may not fix certain failure to bind issues. May or may not cause issues

in canceling binding when using mouse/keyboard to navigate the bind window when

the corresponding mode is set to disabled. May or may not result in Armageddon.

Probably not. I hope.

mattme...

LilyPad, of course. No other part of PCSX2 could possibly be capable of causing Armageddon.

Jake.Stine

Works here in wxpcsx2. Hopefully it doesn't break anything in regular old pcsx2. ;)

ramapcsx2

Lol, I wonder what's with the ambiguity.

Works fine here on wx :)

mattme...

Lack of MS specifications. I want to cancel binding if, for example, mouse mode is set to disabled and you click on another control (Like the ListView or something).

The old code used random extra WM_NOTIFY messages to help detect this. Microsoft doesn't provide any clear cut tampering with other control event.

Revision 1796

mVU: Experimented with some code to clamp every ADD/SUB/MUL/DIV operation.

Code is off by default, broke a lot of games...

This confirms my theory that the best way to handle clamping is to limit the

clamping to places we've tested fixes games.

cottonvibes

"This confirms my theory that the best way to handle clamping is to limit the

clamping to places we've tested fixes games."

Yes it may sound hacky, but the whole idea behind clamping is a hack since we're effectively dealing with a loss of information.

And another point to make is that if a reg holds a NaN value, we don't know if that reg was initiated with the NaN as a valid value, or if another part of pcsx2 computed the NaN as an invalid result value.

For this reason, using double-floats or any other attempt will still have problems.

The only way to rid us of the horrible nan/inf/clamping problems, is either:

1) Every possible floating point operation was software emulated (ensuring that no NaN was due to an invalid floating point exception).

2) We have a CPU architecture that doesn't support NaNs and Infs, or allows us to turn it off.

Neither seems likely anytime soon.

So IMO, pcsx2 will have NaN/Inf problems possibly forever.

Which brings me back to my statement, the best way to handle this is on a game-to-game basis with testing.

And if clamping something fixes one game, and breaks another; then we will have to have special game fixes or game-clamp-profiles.

Nne...

I feel a tad bad commenting on this since I haven't been doing anything Pcsx2-related in a long while, but:

It seems to me like functions that use the clampOp macro do not necessarily have an allocated 't1' reg - which is used by clampOp, leading to a bug.

Anyway, clamping worked fine in sVU (aside from the small issue where the clamped values were being written back to the source registers) so I don't see any reason why it shouldn't work fine anywhere else.

As you said, it's important to distinguish between "large PCSX2 values" and "actual NaNs", but this is easier than it sounds:

If an ADD/SUB/MUL/MAX/MIN operation has non-NaN and non-INF values as its operands, the result will be at most an INF, never a NaN.

For example, ADD/SUB only return a NaN in the "INF - INF" case (or when one of the operands is already a NaN) and MUL only returns a NaN in the "0 * INF" case (or when one of the operands is already a NaN).

For division and the like, special care for division by zero is needed, but that is already treated as a special case.

By the way, ADD/SUB/MUL/MAX/MIN will never even generate an INF if the rounding mode is 'zero' (which rounds overflows towards zero, producing the largest possible value instead of infinity), so no result clamping is needed then.

AFAIK, if all VU operations are operand-clamped and no bugs with the clamping exist, the results should be always better than with no clamping: a large incorrect value is better than a propogating NaN.

cottonvibes

"It seems to me like functions that use the clampOp macro do not necessarily have an allocated 't1' reg - which is used by clampOp, leading to a bug."

when t1 is -1, then my clamp functions use my regAlloc class to allocate a temp reg.

also to confirm its not a reg-trashing problem, i also tested my clamp mode using just mVUclamp1(), which doesn't use any temp registers (and the problem is exactly the same).

so i know the clamping works, the problem is for some reason clamping on a few cases is breaking games.

(SSE_ADDSS and SSE_MULSS seem to be the picky ones).

"AFAIK, if all VU operations are operand-clamped and no bugs with the clamping exist, the results should be always better than with no clamping: a large incorrect value is better than a propogating NaN."

That was my thinking as well with this experiment, but so far its proving to not work out good.

There are still a few more cases where I haven't clamped, so I will finish implementing this idea and see how it works out.

But you also have to remember that even Extra clamp modes on sVU don't clamp everything.

"By the way, ADD/SUB/MUL/MAX/MIN will never even generate an INF if the rounding mode is 'zero' (which rounds overflows towards zero, producing the largest possible value instead of infinity), so no result clamping is needed then."

Yeh I remember what you told me about that; mVU using "normal" clamp mode only clamps operands (and not results) due to this.

(But it only clamps on selected instructions that have proven to fix games)

Revision 1797

Got rid of various obsolete files, and moved the codeblocks workspace file.

Jake.Stine

Yeah moving the workspace to the top-level folder was on one of my eventual todo lists. :)

arcum42

I thought I remembered seeing it there, and, well, it makes more sense there and is more convenient.

I thought about moving pcsx2.cbp to the pcsx2 folder, but it seemed like too much hassle for the moment...

arcum42

<disambiguation>

I thought I remembered seeing it on your to-do list, and, well, it makes more sense at the top level and is more convenient.

</disambiguation>

Revision 1798

Fixes some warnings and a compilation error in Intel C/C++.

Jake.Stine

We *really* should have CALLBACK specified on all the plugin CB functions, but it'd break backward compat with existing dev9, usb, and spu2 plugins. The point of using CALLBACK on all the plugin bindings is to allow a plugin and/or PCSX2 to pick their own default calling conventions for functions. But that methodology fails due to the lack of CALLBACK on the plugin callback functions. >_<

Revision 1799

Added more plugin project files.

arcum42

Note: ZeroGS compiles, and appears to run from codeblocks.(I'd do ZZogl, but it's not in the tree, unfortunately)

SPU-X doesn't compile under Linux right now.

ZeroSPU2 compiles, but won't load in pcsx2 if you compile it from Codeblocks, because it isn't linking with soundtouch properly yet.

arcum42

They way I determined it was a soundtouch issue, for reference when trying to get things like, say, spu2-x working, is that when it enumerates the plugins, it gives the following error:

wx > /usr/local/src/pcsx2/bin/plugins/libZeroSPU2.so.0.1.0: undefined symbol: _ZN10WavOutFileC1EPKciii

If you then run:

c++filt _ZN10WavOutFileC1EPKciii

it returns:

WavOutFile::WavOutFile(char const*, int, int, int)

Which is the unmangled name of the function it can't find. Which is in SoundTouch.

Revision 1800

Emulation options (speedhacks, CPU, etc) should work now, and fixed a few

memleaks on exit, and crash-on-close bugs caused by more mis-used pthreads

timedwait parameters.

Revision 1801

Two more lockup fixes, and changing plugins takes effect without restarting now.

:)

Jake.Stine

I broke something in the either 1798 or 1800 that seems to be corrupting memory, and I have no idea what. I'm leaving for 2 days, so hope someone else can figure it out.

Whenever I hit esc and *usually* when I close the emu, it crashes in GSdx with memory corruption issues.

Revision 1802

Re-fixed bios skip hack, and fixed stack overflow when using CDVD plugins.

Revision 1803

Cleaned up Path namespace and moved it and wxDirName to /common/Utilities.

Revision 1804

Re-ordered the MSVC folder structure to split PCSX2 into two definitive

sections: [App]Host and [Emu]Core (the bracketed names indicate the "long"

versions which are generally used in the code to differentiate the functions and

classes). If the tentative layout is good then I'll sort the files on SVN to

match that layout.

(note: Patch.cpp/Patch.h is still the odd child out in this commit, as it's

destiny is to become a plugin)

Jake.Stine

Notice also I finally got rid of Misc.cpp and Misc.h -- a long-overdue clobbering of some fairly sloppy source files. ;)

Revision 1805

wiki: Added troubleshooting to catch 99.95% of build environment errors.

Removed C# from default install, added to troubleshooting/workaround section.

Removed reference to deprecated wxGUI build workaround. General clean-up.

Revision 1806

Fixed a compiling error.

Revision 1807

Fixed a compilation problem for release builds. I assume the functions in

GSState are currently supposed to be dev-build only? :)

Revision 1808

Did a cleanup and organized EmuCore's virtual folders.

Jake.Stine

@cotton: I think instead of putting MemoryCard and BIOS in their own folders we can leave them top-level and just put all the .h files in an Include folder (since at least for me the only time I ever load .h fils is through the msvc intellisense -- Ctrl+F12 and/or right click and going to references).

... Unless there was another reason besides display brevity for nesting them inside BIOS/MemoryCard folders?

Revision 1809

Corrected some missing GPLv3 headers that somehow got missed in my first pass.

Revision 1810

Highly experimental DS3 support added. Use newly added features at your own

risk. Requires libusb installed and DS3 set up as per instructions at

http://forums.pcsx2.net/thread-7582.html. Doesn't require

sixaxis64.exe/sixaxis.exe, but might have to fool around with starting/stopping

Pcsx2 or LilyPad's test device screen and the PS button on your controller until

the "1" light turns on.

mattme...

One of these days, I'll remember to prefix my commits with LilyPad....

mattme...

SixAxis probably won't work, since I have the product id hard-coded.

Revision 1811

LilyPad: Fixed DS3 motors being flipped, setup default motor bindings on

creation, and reduced delay to make sure pads have been initialized when testing

force feedback (Probably get rid of it all together once I implement a

workaround).

Revision 1812

wiki: CompilationGuideForWindows updated image - removes c# as a

suggested/required dependency.

Revision 1813

gui: Now uses new plugins to check if selected plugins when clicking "Apply" on

plugin config screen rather than the old selected plugins.

mattme...

*To check if selected plugins can be loaded

Revision 1814

Gui: Fixed fix. Last fix was close, but a couple lines too high. Oops.

Jake.Stine

Almost, yeah. It should just be before the if( pi->shortname != NULL ) check. My bad.

mattme...

I wasn't sure if it was mattered while cleaning up the plugins or not. Thought not, but really didn't feel like spending the time figuring it out, as you'd probably know instantly.  :)

Jake.Stine

It's probably better yeah if I set LoadPlugins() to use a customized/specified conf source. Might be useful for other things down the road, like command line ops or something.

Revision 1815

LilyPad: DS3 no longer disconnects when vibrating. Partial workaround for a

DirectInput threading issue when vibration is triggered at the same time devices

are being added/removed - probably do something better at some point. Some

other DS3 related changes - change names of some controls, increased sensitivity

of boolean buttons values to more closely match the DS3 as well. Poorly

calibrated analog axes bound to the d-pad (Or buttons) may cause issues.

Revision 1816

Fix a few Linux things.

arcum42

I'm sick right now (been so for a few days), but wanted to at least patch Linux up to compile again. I left a few changes I'd made before then, too, since I was doing a bit more prep work on getting spu2-x to work on Linux.

Hope nothing breaks, because I'm getting ready to head back to bed. (In fact, there are more changes that need to be made to spu2-x before it'll compile in Linux, but I left them out, because I didn't want to risk breaking anything)

I'm headed back to bed, though...

Revision 1817

Fixed a bug in BiosTools.cpp that caused Bios-Not-Found errors.

MemoryCard / Multitap Renovations:

* Memorycards should now support multitap (somewhat untested)

* Implemented a memorycard plugin interface, using the new API defined in

PluginCallbacks.h (still prelim and hackish)

* Memorycard settings are saved to ini!

* Multitap is now controlled by PCSX2 instead of the pad plugin (which means no

multitap until we implement the gui toggles to enable it)

Jake.Stine

I'm fixing some Linux compilation errors now.

Revision 1818

wiki: Made all screenshots clickable thumbnail links to make the Windows compile

guide about 900% more readable. (Thanks bositman + JakeStine :))

Revision 1819

Linux: Fixed compiler errors from my prev commit, along with a few verbose

warnings and a compile error in SPU2-X. (note, moved Linux's define of SVN_REV

macro to PrecompiledHeader.h for now, until a proper solution is implemented)

Jake.Stine

Oh, forgot to mention, this fixes the bin2cpp dependency problem too. bin2cpp will always build before it's used by codeblocks to generate embedded resources. :)

Jake.Stine

@arcum: btw lemme in on the secret to getting alsa to compile and I'll help on spu2-x sometime (it can't find the header file, and I sunno if it's a missing package or a missing compiler define -- I installed just about every alsa package I could find...)

arcum42

Well, I use Gentoo, where they give it the obvious name of "alsa-headers" (and where you usually automatically have the dev files for anything you install...), however, I think that in Ubuntu it is 'libasound2-dev'.

In the build options I set asound up as the library to link to, so I'm pretty sure that would be it.

The other issues I run into compiling it are that it doesn't like inlining MulShr32, StereoOut32 clamp_mix, & SPU2_FastWrite (which is an error in debug mode, as you might recall from microVU), and sprintf_s & swprintf_s are Microsoft's.

Once that's out of the way, it compiles. Of course, it won't load, so long sessions using c++filt are in order...

It'd be great to get spu2-x multiplatform, though, and when we're giving pcsx2 a makeover is probably a good time.

arcum42

Of course, I started working on it again because I was setting up project files for all the buildable useful Linux plugins. Otherwise I still have to keep the batch file around...

Revision 1820

Rewrote _gifTransferDummy for Path1 transfers (VU's xgkick), now it properly

supports wrapping around VU memory without any hacks (hopefully fixes some

games).

Path2 and Path3 still use the old function since I need to do more research on

them and how pcsx2 is emulating them...

If this commit breaks anything let me know.

Jake.Stine

As far as I know, GIFtag transfers along Paths 2 and 3 can be partial, so the logic needs to consider both size (DMA-controlled) and nloop/eop factors. But that's just based on the old code, and I'm really not sure if that's handling real game logic sense, or just some mumbo jumbo that got coded in because everything else was so buggy.

Jake.Stine

Also, I see no errors in this code. Logic paths all look infallible from here.

refraction

Yeah that side was fine. i had written all the stuff required on the PCSX2 side, however a change is needed on the GSDX side for path1 transfers for it to work correctly, else it does startaddr - memend on the vu's which is incorrect for activision games like tony hawks and guitar hero 3+.

If you want to look at the change required, just look for the path transfers stuff in gsdx and make path 1 do the same as the others :P

Jake.Stine

That shouldn't be a problem. The code in GSdx is only invoked if the "size" parameter is incorrect (ie, mismatched to the actual concatenated/wrapped packet size). Cotton's implementation measures the size correctly and so GSdx doesn't cut the packet short or decide to do its own manual wrap-arounds.

ramapcsx2

So work on this has started :p

Revision 1821

LilyPad: Force feedback threading fix. DualShock 3s initalize much more

nicely.

Still have issues with DS3 rumble - looks like only one motor can be enabled per

communication (Otherwise, always lose connection to the device and have to re-

enable it), and enabling one kills the other. Not sure what to do about this,

currently just flip between the two.

Revision 1822

LilyPad: DS3 tilt support. Why? Because it's there. Can't think of a sane

use for it, though.

Revision 1823

legacy ui: tweaked pay/keyboard handling, might fix some cases where esc

wouldn't work with certain pad plugins.

Revision 1824

legacy ui: merged cottonvibes' new GIFtag handler so that it's more testable. :)

ramapcsx2

Alright, it's indeed better to test it with the familiar gui (and savestates ;) ).

I'll be running my games when I get the time. Lots of real life stuff atm :p

Jake.Stine

Speaking of savestates, I'm working on those now! Along with other major revamps of memory and resource management. >_<

Revision 1825

wiki: Cleaned up a formatting error, fixed a typo in a command name (great place

for one), and removed Team System references.

Revision 1826

LilyPad: Minor improvement writing to DualShock 3 device - lights should

generally be updated fairly promptly now, rather than depending on how/when the

device is initialized. Also removed CRT dependencies, so the MSVC 2005 release

build compiles again.

Revision 1827

gifTransferDummy() now handles path2 and path3 transfers.

Hopefully doesn't break anything :)

cottonvibes

eh I meant the new gifTransferDummy function.

The old one already handled those paths of course xD

ramapcsx2

PATH3 at least is broken, good luck on that one :p

ramapcsx2

Oh, games that use PATH3 include Persona3/4 and Suikoden5.

Ref will know tons more :p

Jake.Stine

(nevermind, forgot that I set it so PrepDataPacket didn't do the copies itself)

Jake.Stine

Oh I see, the Path3progress status vars *were* used in the other transfer. That's what broke things. You removed those on the premise they always get set to STOPPED, but that was when you assumed all transfers process until an EOP like on PATH1. But PATH3 can stop anytime, EOP or not, so the Path3progress status var updates need to be re-included.

ramapcsx2

Ok, so that was a rather small fix. Didn't think it'd be :p

Revision 1828

Reimplemented Path3progress status var, and set incPmem to count in QWCs

(cleanup).

Jake.Stine

Dah, I did the braces wrong in the macro. Supposed to be (x)*16, not (x*16). Won't matter anyway since none of the inputs cause order-of-operations problems... but yea. Macros. >_<

(the sad part is that MSVC treats templates the same way)

ramapcsx2

Yep, this fixed my test games.

And the code still looks clean :)

cottonvibes

hmm i see, yeh i forgot about partial transfers with path3 making the status var != Stopped xD

Revision 1829

Added some missing logic to gifTransferDummy() which takes into account

completing partial transfers.

For example, if a path3 transfer has a giftag with nloop = 30, and we only

'looped' 20 times, then the next time gifTransferDummy() is run for path3, it

will treat the incoming data as the rest of that gs primitive (instead of a new

giftag), finishing the rest of the 10 loops. (Then it just continues normally,

treating the next 16bytes of data as a new giftag...)

Its odd that I wasn't doing this before and games seemed to work fine, but might

be needed for a few games...

cottonvibes

Sadly these changes made the function more complex; but I guess that's expected when you need it to account for more stuff.

ramapcsx2

Was the old dummy handler doing it this way?

And iirc GSdx does the same logic as well, what about that one?

Sounds reasonable to me though it should account for partial transfers this way.

ramapcsx2

Ah yes, lemme guess:

The old handler did this, and a bit more? :p

The game gran tourismo 4 crashed on going ingame with the rev before this.

With this rev, it goes ingame, but many graphic elements flicker.

It looks like before Ref made changes to vif1, just worse.

Other games I ran were all fine so far.

Jake.Stine

VIF1 is PATH2. There could be some bugs in how PATH is handled, both on VIF side and/or in cotton's new code. Cotton said that PATH2 was behaving erradically, and not getting EOPs (which is very bad -- on the real PS2 hardware that would have caused the GIF to perma-stall on PATH2, basically).

Jake.Stine

I'm going to remove the hasRegAD "optimization -- it's created way more code than it's worth. I think the whole of GIFtag will be faster without it now, and more importantly we'll not be able to use that opt with the new GS pluign anyway. ;)

Jake.Stine

Ok, I'm having trouble getting this to work and I don't have time to work on it right now.

But these are the problems I've noted:

a) we need to re-add the old code for StepReg(), because transfers *can* be partial all the way down to any arbitrary qword. path.StepReg() was there to serve the purpose of retaining that value.

b) We need to have a copy of nloop in GIFpath, and use that to retain nloop status between calls to dummyPacket.

c) We need to use that nloop value to decide if/when to load a new tag, and get rid of all the pathContinue hackery in the process.

I have most of this coded locally, but I've missed.. something. It can't boot the BIOS.

Revision 1830

Applied GIF PATH2/PATH3 fixes from trunk, and unbroke STGS from the last legacy

rev. ;)

Revision 1831

Legacy GUI: Revert to use sVU for VU0 macro for now, since mVU is missing some

clamping yet.

ramapcsx2

There's too much stuff going on at the same time currently, and we know the missing mVU macro clamps cause a few games to hang or error.

Proper clamping should be thought out a bit, brute forcing all those MUL and MADD opcodes would be slow ><

Revision 1832

Yay, craploads of fixups for the new gui:

* Lots of crashfixes and threading rules compliance (like using wxYield instead

of ProcessPendingEvents)

* Killed off some memory corruption

* Better error handling and reporting

* Much speedier suspend/resume during emulation

* Revamped entire savestate system to use a RIFF-style file format (untested,

will work on it soon)

Revision 1833

wiki: Removed instruction to add PCSX2_TARGET_COPY to System Variables

(unnecessary). Added information required to ensure gsDX debug builds are

enumerated and usable in PCSX2.

Revision 1834

Let's save the SkipBios hack setting, because people hate me enough already for

putting this off a week.

cottonvibes

yay

Jake.Stine

Don't spam the comments!! >_<

ramapcsx2

yay

Jake.Stine

Don't spam the... ! eh, nevermind. :|

ramapcsx2

Wait, it doesn't work! :p

mattme...

Huh? Spamming the comments seems to be working fine.

Revision 1835

Fixed a compiler warning from pcsx2.

Fixed some bugs I noticed in my gsDummyTransfer() funct; idk if it fixes GT4

since my game isn't running on pcsx2 anymore (its always been a pain for me to

get my version to work)

Anyways, going to rewrite the function again using a simpler algorithm thats

less likely to messup.

Revision 1836

Linux: Fix some of the standard issue compiler errors that come with any

changes. :)

Revision 1837

wxWidgets: Hooked up plugin config menus in main window.

LilyPad: Couple very minor string/menu changes, no functionality changes.

Revision 1838

LilyPad: Fix for some bizarre issue with wxWidgets involving property sheets,

Microsoft, spec violations, and gremlins.

Revision 1839

Re-fix win32 builds. Stupid C++ templated class inheritance fail.

Revision 1840

Added a GSopen2 call to the GS plugin API, which is used by PCSX2 to specify its

own window handle.

Revision 1841

Branch made for working on proper implementation of the new GSopen2 into GSdx.

arcum42

I might make changes in this branch to implement GSopen2 in other plugins as well, if you don't mind...

(Yes, I'm thinking of setting up GSnull to use pcsx2's built in window...)

Jake.Stine

Yea sure, go for it.

arcum42

Thanks. It's less hackish then the ways GSnull usually gets a window handle. (And it needs one for pad plugins to work.)

Looks like GSnull doesn't compile right now in Windows, and pcsx2 doesn't compile in Linux at the moment after the GSFrame additions.

The latters probably easy to fix, but I'll get some sleep before looking at it...

(The formers probably easy to fix, too; I just rarely check on it.)

Revision 1842

GSopen2: Current status...

* Software mode seems to work fine. Suspend and resume emulation work nicely,

without flaws.

* Hardware DX9 mode suspends but displays only black after resuming.

* Hardware DX10 status is unknown.

Jake.Stine

Drk or Feal87, I need some help on this if possible. I'm not very good dissecting D3D API behavior and I'm not sure why it's getting blackness when recovering from a suspended state.

Jake.Stine

yay!

pcsx2gu...

Nice change but GT4 NOT WORK!! WHY???? Black screen video no work cannot live without gt4 video :(

Other than that, will try it out on DX10..oh wait does this gsdx still need those crappy ogl dependencies?

ramapcsx2

Pause in dx10 mode works, resume causes the GSdx window to do nothing.

Reset after all this recovers the GS window.

Pause in dx9 mode works, resume causes the vga driver to crash (from the looks of it).

PCSX2 crashes after that.

Revision 1843

Minor fixes for interlocking against the threaded plugin loader (running a game

too quickly could cause crashes)

Revision 1844

Linux: added missing files, and switched from my own WindowDisbler hack to wx's

built-in wxWindoweDisabler hack. :)

Revision 1845

Linux: IsRunning was crashing pcsx2. Also, jNO_DEFAULT isn't a good idea in

these two spots.

arcum42

IsRunning was crashing on pthread_kill when you told it to start an iso before this change.

arcum42

And jNO_DEFAULT isn't a good idea when the values can be changed by hand in an ini file.

Jake.Stine

Indeed, you are correct sir.

Revision 1846

GSdx: Fixed GSDialog so that it doesn't cause PCSX2 to minimize into the

background when closing the config box.

PCSX2: Reloads plugins a little less often.

Revision 1847

Hook up the save/load menus and make the Linux console output somewhat less

insane.

arcum42

Not that saving/loading works properly in Linux, but now the menus act exactly as badly.

And the console change was because on Writes, it was writing "PCSX2 >" before every character...

Jake.Stine

that will dump 'PCSX2 >' to the emuLog.txt as well as the Linux console, which really wasn't my intention. I'm not even sure if the 'PCSX2 >' is that useful for avg linux folk. On CoLinux I have only one console and Code::Blocks likes to spam it as well, so I had to add some tag to identify it. :)

Jake.Stine

Oh, yeah, I forgot about the EE/IOP log dumps. Those write per char instead of per line. -_-

Jake.Stine

Err, by that I mean the actual DECI2 log output from the emulated EE/IOP kernels. And admittedly it'd be nice to have those prefixed differently anyway, with a "PS2" or something to know it's coming fromt he PS2 virtual machine and not PCSX2 itself.

arcum42

Point; I was just getting irritated at at constantly dealing with output like this:

PCSX2 > Write-protected page @ 0x00259

PCSX2 > Write-protected page @ 0x0020c

PCSX2 > Write-protected page @ 0x00204

PCSX2 > rPCSX2 > ePCSX2 > aPCSX2 > dPCSX2 > /PCSX2 > wPCSX2 > rPCSX2 > iPCSX2 > tPCSX2 > ePCSX2 > PCSX2 > aPCSX2 > lPCSX2 > lPCSX2 > oPCSX2 > cPCSX2 > aPCSX2 > tPCSX2 > ePCSX2 > PCSX2 > mPCSX2 > ePCSX2 > mPCSX2 > oPCSX2 > rPCSX2 > yPCSX2 > PCSX2 > 4PCSX2 > 0PCSX2 > 0PCSX2 > 0PPCSX2 >

PCSX2 > oPCSX2 > pPCSX2 > ePCSX2 > nPCSX2 > PCSX2 > nPCSX2 > aPCSX2 > mPCSX2 > ePCSX2 > PCSX2 > rPCSX2 > oPCSX2 > mPCSX2 > 0PCSX2 > :PCSX2 > RPCSX2 > OPCSX2 > MPCSX2 > VPCSX2 > EPCSX2 > RPCSX2 > PCSX2 > fPCSX2 > lPCSX2 > aPCSX2 > gPCSX2 > PCSX2 > 1PCSX2 > PCSX2 > dPCSX2 > aPPCSX2 > PCSX2 > aPCSX2 > PCSX2 > 4PCSX2 > aPCSX2 > 1PCSX2 > 7PCSX2 > 8PCSX2 >

PCSX2 > oPCSX2 > pPCSX2 > ePCSX2 > nPCSX2 > PCSX2 > fPCSX2 > dPCSX2 > PCSX2 > =PCSX2 > PCSX2 > 2PCSX2 >

Jake.Stine

Yeah since I can't actually run games yet I never got far enough to see that. :p

arcum42

I saw it, and figured it wasn't urgent, but it's been on my to do list.

There are just a lot of other things on the to-do list, like the bios skip hack not working, so it hasn't been a priority...

Revision 1848

GSopen2: synched with trunk to pick up various gui fixes.

Revision 1849

GSopen2: Fixed GSdx so that it complies with the implied intent of the PS2E

plugin API, where GSopen and GSclose retain the current GS emulation state.

This required a couple significant changes:

* Removed GSTextureFX classes

* Built shaders right into GSState classes, using GSStateDX as an interface, so

that all shader caches get auto-destroyed along with GSState.

In addition to being a bit of a code cleanup, it should be a bit more efficient

too since all of the extra dereferences to GSState from GSTextureFX have been

removed. :)

ramapcsx2

Wow, where did you pull this one from? :D

It seems to work exactly like the old version and in cpu limiting scenes it's 5% faster.

Great stuff :)

Jake.Stine

Nickname reports that sometimes pause/resume won't quite "catch" and he has to resize the window for it to start updating again. Have you experienced similar issues at all?

ramapcsx2

Nope, no oddities like that.

Jake.Stine

OH I should mention that oddity was specific to DX10 only.

ramapcsx2

Yep, no problems so far.

I didn't test much though, so should it ever pop up, I'll complain :p

Revision 1850

LilyPad: Switched to using pre-compiled headers, just for kicks. Compiles

significantly faster, though it's not exactly the limiting factor in batch

builds.

Changed intermediate debug build directory, for consistency.

Added another LilyPad-only build option, to compile without CRT dependencies, as

manifests are evil.

Finally nuked the VC 2005 project.

Revision 1851

Same changes to ZeroSPU2 & spu2-x's projects. ifdeffed out a few things in

spu2-x.

arcum42

Er, "some" changes.

Mainly, I figured out how to use SoundTouch properly in them.

Jake.Stine

I wonder why forceinline causes funny problems in SPU2-x, but never really caused any issues in pcsx2 up to know.

Jake.Stine

oh, also! Try Linux with threading enabled in the PluginSelectorPanel -- I fixed some mem corruption a few revs back, it might work now.

arcum42

Well, it has on occasion, but I don't normally test everything in debug mode, and debug mode is where it starts generating errors about forceinline instead of warnings.

Also, I think that having a few levels of compiler optimizations in the project (whch I haven't set back up) gets rid of some of the forceinline errors when things get optimized out.

Realistically, we should probably have a define that sets up forceinline for Windows and inline for Linux, for cases like these, though.

Oh, and spu2-x is compilable right now. The generated plugin will error out when the plugins are enumerated, but that's because there are a few functions that need implementing...

arcum42

Seems like threading works in the Plugin selector panel now, as far as I can tell...

Jake.Stine

>> well, it has on occasion, but I don't normally test everything in debug mode, and debug mode is where it starts generating errors about forceinline instead of warnings.

Ah, that's why yes. __forceinline in MSVC is stillignored in debug builds. GCC should be configured to macro it to nothing if NDEBUG is not defined.

Revision 1852

wiki: Added some new screenshots, courtesy of submissions from the Screenshots &

Videos topic on our forums. :)

Revision 1853

wxWidgets: Clicking on the sliders on the hacks screen now works.

Scroll rate is very inconsistent, but that's just wxWidgets doing what it does

best (worst?)...

Also fixed a minor bug in LilyPad version labeling.

Revision 1854

Re-re-re-re-fixed the BIOS skip hack saving on exit (plus lots of code cleanups

and some API changes to saving/loading settings -- more to come).

Linux/GCC: Disabled __forceinlining in debug builds. This is the intended

design, fixes many GCC errors in debug builds, and also mimics MSVC behavior.

Revision 1855

Disabling microVU (enabling superVU) gets saved to ini now. :)

Revision 1856

GSopen2: Added GLEW as a static library dependency. We decided it's small

enough to merit being packaged with PCSX2's 3rdparty libs, and it fixes GSDX

from needing GLEW32.dll.

Revision 1857

Small fix to remove an assertion in XAudio2.

Revision 1858

GSopen2: Fixed a bug in gsdx where it didn't properly handle changes to the GS

base register memory pointer.

Jake.Stine

I also removed a lot of windowed/fullscreen mode mess, although that part is a WIP. Time to finish that up now, hopefully.

Revision 1859

Moved the GIFtag from MTGS instance status to static status, since it needs to

be preserved as part of the PS2 virtual machine state (fixes problems when

pausing/resuming)

Revision 1860

GSopen2: Simplified the multithreaded and irq callback parameter passing scheme,

and made them more "robust" so that they can be changed dynamically without the

GS exploding (important with the new correct GSState preservation across

open/close).

Revision 1861

wiki: Added a screenshot of some other game to our front page, upon request.

Dunno, maybe someone else has heard of it...

Revision 1862

GSopen2: Fixed legacy mode compat and STGS operation.

Revision 1863

wiki: Updated DirectX SDK to August 2009 in documentation and links.

Revision 1864

GSopen2: Detect GSRenderer changes across GSopen/GSclose calls, and preserve the

GSState at the same time. Also added proper window closure code, so that STGA

mode (legacy gui only) doesn't cause the GS window to be frightfully sticky. >_<

Revision 1865

wiki: Added that Cg documentation and example source code were not required.

Revision 1866

GSopen2: synced with trunk, so that I can reintegrate. :)

Revision 1867

GSopen2: Merge failed to record these revisions for some reason.. >_<

Revision 1868

After hours of frustration getting my gifDummyTranfser() function to work the

way pcsx2 wants path2/path3 transfers to occur, I decided to just rewrite it

again using the old gifDummyTransfer() as a base.

Fixes GT4 corrupt textures.

Again tell me if this version breaks anything...

ramapcsx2

- SMT Nocturne works again

- GT4 glitches are all gone PLUS it doesn't seem to hang anymore in specific situations :)

Revision 1869

fixed a bug from my last revision...

cottonvibes

this gif dummy crap really killed me.

its not even very complex but for some reason i keep bugging stuff :(

Revision 1870

A few dmacReg & gifReg changes.

arcum42

Forgot to take out the line:

psHu32(GIF_STAT) |= GIF_STAT_P3Q;

in Gif.cpp. I'll have to remember to remove it in my next pass.

Revision 1871

Reintegrated GSopen2 branch. Rundown of new features:

* Implemented proper shader management, fixes several bugs where video would be

lost or crash, and is a small speedup.

* Retains GS state across open/close, same as every other PS2E plugin now.

* Implemented GSopen2(), which is used by wx-pcsx2 to bind the GS output to a

window handle of pcsx2's choosing.

* Retained full backwards compat with the current legacy gui. :)

Zeydl...

Question, what is GSopen2 API for GS plugin? What should I implement?

Revision 1872

A few more baby steps toward cleaning/fixing the GIFtag parser:

* used UPPERcase to denote the original hw register tag values from the

"running sum" copies in GIFPath.

* Renamed PrepRegs to PrepPackedRegs, and optimized it so it's only run when

needed (which is anytime new set of packed regs has come into play)

* Create a copy of NLOOP, so that we leave the original intact for possible

later referencing.

* Simplified the XGKICKs use of sizes. They just pass 0x400 now.

arcum42

Linux doesn't particularly like GIFTAG tag being constant, btw.

/usr/local/src/pcsx2-1/pcsx2/MTGS.cpp:66: error: uninitialized member 'GIFPath::tag' with 'const' type 'const GIFTAG'

Commenting out the const takes care of it, but I thought I'd run it by you, especially since I still have to straighten out some changes in my current trunk that clobbered Kingdom Hearts...

Jake.Stine

Oh it just needs an empty constructor again, like the consts in the x86emitter a while back.

arcum42

Oh, right, forgot about those.

Should be easy enough. Have to rebuild my current trunk first, though. Something got foobarred in it, completely outside of the changes to rbor and rbsr I was making...

arcum42

Further testing reveals that Kingdom Hearts 1 is just broken in the trunk... :(

Revision 1873

GSdx: Fixes GSReplay renderer selection, and adds support for using -1 as a

renderer (uses the GSdx configured renderer, but only works if the current

working directory is set properly, otherwise the ini file won't be found).

Revision 1874

ZeroGS: Remove compiler errors under DXSDK Aug 2009.

Revision 1875

wiki: Updated to remove hard-coded table of contents to use googlecode's auto-

linking table of contents. Links are all the rage these days.

Revision 1876

wiki: Reformatted to make it much easier to read and easier to click through if

you're looking for something specific.

Revision 1877

legacy_gui: removed the localized plugins folder and replaced it with an

svn:external that checks out the trunk plugins instead (since only pcsx2 itself

has a gui branch).

Revision 1878

Disables MMX register allocation in the EErec; fixes instances of random TLB

misses in games like SMT:Nocturne and FFXII (initial benchmarks show it to be

same speed or faster anyway, heh)

Revision 1879

legacy_gui: synced GIFtag parser bugfixes from trunk. Fixes many problems

introduced in recent legacy gui revs, most notably some issues in Gran Turismo

4.

Revision 1880

legacy_gui: Disable MMX register allocation the EErec. Fixes instances of

random tlb misses and hangs in several titles (synced from trunk)

Revision 1881

legacy_gui: previous 2 revs had a failed half-merge of GIFtag code (tortoisesvn

bugs.. >_<). Re-merged, and removed plugins external because they weren't

compiling anyway (also removed all plugins from the pcsx2 solution).

Jake.Stine

Plugins need 3rdparty and common dependencies that only have projects in the trunk, and it was too much work for me to merge them over just for the sake of compilation convenience. So I axed them. Use trunk to build plugins. :)

Revision 1882

More GIFtag bugfixes; PATH1's VU1 memory wrapping was measuring the end of VU1

memory incorrectly.

Revision 1883

legacy_gui: sync with trunk to pick up GIFtag fix. Hopefully the last of these

for a while >_<

Revision 1884

legacy_gui: helps if mVU isn't broken to the point of not working at all.

Revision 1885

xgkick fix for main trunk

Jake.Stine

This was pretty comical. All of us devs had mVU disabled today and none of us realized it, since typically we never disable mVU. So we didn't even know anything was wrong and we couldn't reproduce reported errors. :p

Revision 1886

MTGS:

- Optimization for gsTransferDummy to reduce idle loops.

- Added needed variables to _mtgsFreezeGIF().

Revision 1887

Rbor, rbsr, and other such things.

Jake.Stine

I assume FFX and stuff is all working fine for you again? Sorry about that. :(

arcum42

Yeah, when I switched over to Windows, and was still having issues, I figured it couldn't be me. r1885 took care of it, though.

Though I never got around to fixing the const tag flag, come to think about it, since I'm working in Windows at the moment...

Revision 1888

legacy_gui:

Revert all changes involving the GIFtag parser rewrite. It was not bug-free yet,

so we'll handle it later in wx.

ramapcsx2

Arcum:

This reverted a few of your cosmetic changes as well, sorry for that :p

arcum42

No worries.

To be honest, I don't think I did any cosmetic changes to those files recently anyways (though I think Jake did.)

All my recent changes have either been wx related or DMAC related...

Revision 1889

LilyPad: Fixed not adding manifests in debug builds, removed them from CRTless

build.

Removed the keyboard disabled option, as using two different pad plugins is

really just a bad idea. Also finally got sick of people saying "I have keyboard

disabled, and the keys don't work! I urgently need help!"

Also will no longer let you enter config mode (And thus crash the program) when

emulator is running.

Revision 1890

fixed the arc the lad gif problem...

Jake.Stine

1 line-by-line comment

/trunk/pcsx2/MTGS.cpp  

r1890  

line 298:

298: if((path.numregs * path.nloop) < (size-1)) {

Forget a "!path.hasADreg" here? Or am I missing something elsewhere that makes it unnecessary?

Jake.Stine

I'm like 99% sure it's supposed to be there, but I've been so wrong myself already on GIFtag "fixes" that I'm afraid to make the change. lol

Revision 1891

LilyPad: "WM Keyboard" now actually uses GetAsyncKeyState(). Just simplifies

some dependencies on the window thread. Note that WM Mouse and raw input still

have those dependencies, and they can't really be worked around, unfortunately.

Also, just for kicks, made pausing while pressing "escape" check the pause

button in the menu.

Revision 1892

Some minor IPU changes.

arcum42

Not absolutely sure a minor savestate bump was needed, but I figured it couldn't hurt to be sure.

I'm also not sure if checking for a sif stall is needed. Figured adding the code was easy enough, and I could take it out again if necessary. It just seemed logically like it should be there. I'll check and see if it ever gets called later.

Jake.Stine

@arcum: since savestates don't even work yet, no bumping in state versions is really needed. But! They will be working soon. I'm working on them now. :)

Revision 1893

Took out the optimizations in gifTransferDummy.

They broke games still (so3, same stuff as arc the lad earlier).

With this simplified version all the problematic games found so far work.

Revision 1894

Implemented keyboard accelerator tables and a hashed global command table

(should be ideal for eventual GUI extensions via plugin, and toolbars and other

fanciness). Removed Pause menu and replaced it with a Suspend/Resume menu.

Closing GS window behaves more nicely.

Projects: Removed FrameworkVersion descriptor, don't think it matters for C++

code. Removed all translation files, since they're grossly out-dated and need

to be remade anyway.

Revision 1895

int -> bool.

arcum42

Since Jake indicated that savestate bumping isn't needed right now...

Revision 1896

LilyPad: Reverted keyboard messages back to windows messaging.

New method of ensuring thread safety. Device update code should always run in

GS thread, even if the emulator really doesn't want to let me (Basically ancient

versions of Pcsx2...Or any 3rd party emulators with their own version of MTGS).

Updates on PADpoll, PADkeyEvent, or PADupdate, if one is called in the right

thread. Updates in thread's WndProc otherwise. Overkill, perhaps, but I prefer

to keep things compatible.

Removed "Update in GS thread" option.

Windows Messaging/Raw Input keyboard event queuing should work a little better.

Revision 1897

Win32: Added stdout and stderr pipe support for the ConsoleLogger; such that

plugins using printf or fprintf will have their messages show up in the new-

style console log and in the emuLog.txt file.

Jake.Stine

I'm fixing Linux now. :)

arcum42

No worries.

I'm still looking over the dmac area of the code to see if I missed any obvious changes...

Revision 1898

Linux: Fix compilation errors and warnings. There's still a lot of new warnings

in x86Emitter due to __forceinline being disabled in debug builds, but the

proper fix for those will come later.

Jake.Stine

I'd like to fix those warnings and fix the -zmuldefs problem at the same time (apparently GCC on the mac lacks the -zmuldefs option, but MSVC requires multiple definitions for __forceinline on templated class members to work .. sigh)

arcum42

Look on the bright side. We don't even need -fpermissive any more; all the code that required it got rewritten at one point or another.

-zmuldef is a pain, though...

arcum42

Oh, most of the "defined but not used" warnings can be suppressed by liberal use of __unused, btw. I snuck that attribute into the definition of __forceinline at some point, IIRC, so the lack of forceinlining may be bringing back old warnings I'd supressed...

Jake.Stine

Yeah it's really MSVC's fault for not properly utilizing LTCG. Even with it enabled, MSVC won't properly inline class members unless I make 100% sure the code is included into the source files that reference the class (which defeats the purpose of LTCG!).

I should check if VS2010 has the same problem. If not then maybe I'll hold off until VS2010 goes final, and just do a simple fix. The fix for current GCC/MSVC to be happy will require a bit of header file trickery that I don't look forward to.

Jake.Stine

Ok, yeah, VS2010 will completely resolve the MSVC failures on optimizing C++ classes. I tested it here and the codegen is a lot better. Constants are propagated as they should have been all along. So I'll be able to just define classes in a single file without the __forceinline, and it should be fine.

I may do it sooner than later. The real performance benefits of the emitter using forceinline is minimal at best.

Revision 1899

Legacy_gui: Some cleanups

Revision 1900

Same general cleanups (mostly to the VU interpreters), but on trunk this time.

:) Also Fixes Issue 417 (I hope)

Revision 1901

GSdx: Update delay load DLLs to match Aug2009 DirectX SDK (and yes you need the

new SDK to build GSdx)

Revision 1902

Fixes Issue 419 by checking validity of StdHandle values. Also:

* handful of minor code cleanups, and some warning removals for ICC.

* replaced the dualshock.png with a dualshock.jpg (120k smaller!)

* Updated the About Box, and added Zeydlitz / ZZogl to the plugin author

credits.

Revision 1903

Fixed a re-entry condition when trying to use the SysCoreThread::ApplySettings()

directly; and fixed some threading issues in the resume code too.

Dev Note: EmuConfig is now *const*, and can *only* be modified by a call to

ApplySettings(), which itself cannot be called from its own thread. This

protects against accidental thread-unsafe on-the-fly settings changes.

Amazingly we had only one such settings change in the existing trunk. I fixed

it ;)

Revision 1904

win32pthreads: Changed from _beginthreadex to CreateThread, which is the

preferred method of creating threads when using dynamic CRT linking.

PCSX2/Win32:

* Assigned names to the threads so that they show up nicely in the debugger.

* Added more error checking in the new stdout/stderr PipeRedirection code,

hopefully fixing Issue 422 (but can't reproduce the error here to be sure).

Jake.Stine

Note on the pthread change: there's no functional or API changes, so the version number of the DLL wasn't modified.

Revision 1905

LilyPad: Quick fix to bug in the thread stuff from last update.

mattme...

This apparently broke LilyPad's DirectInput handling with wxWidgets, according to rama. Removing the stateUpdated[0]--; supposedly fixes this (Though it will, of course, result in a lot of redundant reading of input).

Revision 1906

LilyPad: Another pair of fixes for related bugs in the thread safety stuff.

First could cause crashes when stopping/resuming/restarting emulation, second

would cause devices to fail to restart properly (Or, more accurately, restart

too early) when doing the same.

Revision 1907

wxWidgets: Added multitap toggles to config menu. Note that currently have to

enable multitap both in Pcsx2 and LilyPad for extra pads to work.

Also added suggested interface for plugins for whenever the plugin apis are

updated.

Revision 1908

Improved MTGS (added better suspend/resume support), and work on savestates a

bit (still not working tho)

arcum42

SysThreads.h?

Revision 1909

SPU2-X:

Just changed the config dialog a bit to prevent performance seeking users from

disabling timestretching (and then posting threads about bad sound :p ).

Revision 1910

Fix compilation errors from my prev commit.

Jake.Stine

Note 1: I took a poll on IRC and we unanimously decided to scrap the "Emu" attempt and replace it with "System" (or Sys for short). Currently there's still some ambiguity with some of the Sys functions that are defined in App, because I was getting myself confuse don what prefixes denoted what. Will clean it up eventually.

Note: I've added a System folder, which is where we'll house the Sys/Core emulation files. The ideal being that eventually /pcsx2 will be mostly just two or four folders: System, gui, and possibly Windows and Linux (for project files).

Files in GUI will have to prefix to include System includes:

#include "System/SysThreads.h"

... and files in System simply won't be able to include GUI includes. (by design)

Revision 1911

Fix compilation on Linux.

Revision 1912

Removed two redundant/unneeded conditional checks from GIFpath processing.

Jake.Stine

Did this as a separate commit since GIFpath changes love to break things. But it should be fine. The one conditional was redundant on PATHs 2 and 3, where the vuMemSize is set out-of-range anyway (never reached). And the other was optimized to use a NULL lookup table for register indexes 0x63 -> 0xff.

gigaherz

Uhm......!

s_gifPath.Handlers[handler&0x3]((const u32*)pMem); << handles is masked &3, so it will never go >3, only entries 0..3 will be used. So if some game tries to use reg 0x64, it'll get reg 0x60 instead. I'm not sure if that's what you intended, or if it will actually affect anything, but I had t note it.

Jake.Stine

Oops, yeah that should be -0x60 now, instead of &3.

Revision 1913

Renamed memzero_obj to memzero. Been meaning to do that for a while. Also,

Savestates *almost* work, but it's just not going to happen. See everyone in 5

days or so. -_-

Jake.Stine

<JakeWork>sorry I couldn't get savestates working

<JakeWork>and like the code's all hacked up because I was in a hurry and terribly sleep deprived

<JakeWork>needs an overhaul to not suck :(

ramapcsx2

It's cool. Savestates are half working.

Make the best of your trip :p

Revision 1914

LilyPad: Experimental deadzone code. Old pressure sensitive button bindings

must be rebound (DS3 buttons, XInput triggers).

Currently anything below deadzone is mapped to 0. deadzone and above are mapped

as if the control's true zero is 0 and 1/sensitivity is fully down (As opposed

to deadzone being zero). May change in the future.

Modified precompiled header to fix no-CRT build.

List of bindings noew automatically jumps to new bindings.

mattme...

Yes, I can't type.

ramapcsx2

Hmm, I've been getting this for a while now:

Opening PAD

Closing GS

PAD plugin failed to open. Your computer may have insufficient resources, or incompatible hardware/drivers.

Other pad plugins are fine ><

mattme...

Make sure your GS plugin does *NOT* support GSopen2. There's a bug in Pcsx2 so that it doesn't give me a window handle when using a plugin that exports it.

mattme...

Erm...Or maybe it's the other way around, anyways, pDsp is never initialized, so I get passed a HWND pointer.

mattme...

Just checked...Looks like it's plugins *without* GSopen2 that are buggy. Pcsx2 tries to open the pad plugin before the GS plugin has even opened a window.

I check that I am passed in a valid HWND, as I actually need a handle to the window. Not all input APIs need it, but raw input and Windows messaging do, as well as most of the extra stuff: Disable screensaver, savestate number in title, etc.

Revision 1915

LilyPad: Give "credit" where credit is due...

ramapcsx2

xDD

Revision 1916

Workaround for bug in plugin loader with GS plugins that don't support

GSopen2().

ramapcsx2

Alright, that fixed it for me.

The question now is why my GSdx doesn't seem to support GSopen2 ><

mattme...

Dunno. I only managed to duplicate the issue because I had an old (r1763) SSE2 versions of GSDX around. The one that I actually use (r1894 SSSE3) supports it.

ramapcsx2

Alright, figured it out. My linker was set to drop GSdx in some other place, forgot about that :p

Revision 1917

Legacy_gui:

Added warnings in case speedhacks are enabled.

ramapcsx2

Trunk probably has better tools for this.

And yeah, I know that enabling patches overrides the warning (Too much hassle to care for that, too :p )

pcsx2gu...

Lol evil but nice :P

Finally got fed up with the crap reports with hacks on huh? :P

ramapcsx2

Sure, last thread was like 10 replies until the op finally mentioned "I turned haxx off, and now it works!!11".

Sigh :p

mattme...

Great idea. Made a lot of changes myself to minimize pointless support requests.

Revision 1918

LilyPad: Fix for non-pressure sensitive buttons with dead zone < 0.0625 or so.

mattme...

Sensitivities, rather

Revision 1919

LilyPad: Less sensitive (Higher pre-set deadzone) for copying analog state to

d-pad state when in digital mode.

Revision 1920

LilyPad: Default deadzone increased. Note that will only apply to new

bindings, or ones from inis made before I added deadzone support. Hope it's

high enough for most cases, but not high enough to break anything...

mattme...

Yes, I know dead zone is not one word.

Revision 1921

Assorted header cleanup.

arcum42

And, yes, one or two of these changes are totally pointless. Just didn't notice that I hadn't done anything else in those files when looking at the diff...

Revision 1922

Legacy_gui:

Trying out different interrupt timings to fix a few games.

This is all pretty much voodoo, hence the tag in the source ;)

Fixes:

-Digital Devil Saga Videos (IPU died, had to skip vids)

-Ecco the Dolphin now boots again (froze on loading)

-Silver Surfer Pad detection works (had a timeout before)

ramapcsx2

Trunk will get these changes once they're confirmed and tested.

Revision 1923

GSdx: Force the plugin to terminate via PostQuitMessage() when running GSReplay

(fixes bug where GSdx would remain loaded in the background indefinitely).

Revision 1924

w32pthreads: minor optimization using _declspec(thread) for internal thread

handles, instead of TlsAlloc.

Revision 1925

w32pthreads:

* Implemented a combination static link and dynamic link system; threads still

benefit from DLL-level thread management, but speed-critical actions (semaphore

and mutex locks) can now inline their "accelerated" interlocks properly. Should

be a nice speedup.

* Implemented a highly optimized pthread_testcancel(), that typically performs

its test in a single cycle. :)

* Disabled static mutexes. They aren't needed in C++ code, and reduce mutex

locking overhead nicely.

* Use intrin.h for Interlocked functions, instead of pthreads' built in ones.

* Reverted my previous commit, since TLS isn't safe in DLLs. (oops!)

* Disabled pthread_spin API, it's not entirely cross-platform and shouldn't be

used anyway (bad threading model for modern computing)

Revision 1926

w32pthreads: add the missing project file. (thought for sure I added this >_<)

Revision 1927

More explicit C++ style type definition for PSXCLK, to ensure compilers avoid

mathematical overflows. :)

Revision 1928

Implemented 64-bit writes for Counter registers -- Fixes uLaunchELF!

Revision 1929

(work in progress -- some of this stuff still doesn't quite work as it should)

* Rewrote Savestate code, fixed lots of stuff in PersistentThread, and renamed

most "Emu"s to "Sys".

* Removed wxScopedPtr and whipped up our own ScopedPtr that doesn't use boost's

fail-style function names (and made it more thread-safe).

* Handling exceptions across threads: Added Clone() and Rethrow() methods to

BaseException, and added a Rethrow() to PersistentThread.

* Go rid of AppInvoke macros (those were nasty!)

Revision 1930

SPU2-X:

* Potential Bugfix: Core1's DMA IRQ trigger was being ignored in some

instances; might fix some hangs.

* Major code cleanups, using C++ structure member methods and functions.

* Improved gui / plugin api / core emulation code separation -- hoping to

switch to wxWidgets eventually.

Revision 1931

Not particularly tested, but fix Linux.

arcum42

The reason why this wasn't well tested was that my home file servers acting up. I'm going to replace a hard drive during the weekend, but that's where all my ps2 isos are. (The hard drive that's acting up isn't the one with the isos, but the one with it's os, so I won't need to rerip them...)

I'm re-ripping a few of the ones I test the most to my local system, but I'll still be testing with less games then usual for a few days.

Revision 1932

Legacy_gui:

Bring over the counters fix, and also make dev builds a bit more verbose on

unknown hw writes.

Revision 1933

SPU2-X: Fixed a huge bug in my last commit that broke most everything except the

bios -- Core indexes were set to -1 instead of 0 and 1 (heh). Also a Speedup:

Switched to a lookup table for dispatching SPU hardware register writes.

Revision 1934

wxWidgets (Win32): Disable debug trace logigng of Windows Messages, because it's

really! slow. And not! useful.

Revision 1935

GIFpath: Making a note about the BIOS using the packed register address 0x7f,

and disabling logging for that address, since it spams.

ramapcsx2

Code reviews are enabled for the general public again.

trigunflame

let the retarded comments commence once more !

--

nice work on the recent changes jake.

krazytru...

Yep, someone's been very busy, again.

aleing...

before some commits like 6 o 7, i got almost perfect speed in many games, now i have the half of speed or less, but your work is amazing, please back the speed again :D

pcsx2gu...

Gasp, let the spam begin...

pab_rally83 don't use the latest SPU2-X as said in 2 revisions already, it's bugged to death.

ramapcsx2

Nah, 2 bugs in it. One we already fixed, the other needs a bit more investigation.

aleing...

thanks pcsx2guide :D, good luck

lemuel2010

Continue with Gifpath increasing the compatibility.Thanks

Revision 1936

Fixed SPU2null.

Revision 1937

Legacy Gui: Get Linux working again.

ramapcsx2

Whops :p

arcum42

np. Just hadn't been testing legacy_gui regularly, so hadn't noticed...

airmake...

Do you get the wxWidget version of PCSX2 on linux working, arcum? I always have problems with the wx-headers. :< Don't really know if it's a distro issue (Arch), or pcsx2 issue.

arcum42

It builds.

Currently, building a Debug build requires the debug version of wxwidgets installed, and a Release version requires a non-debug version of wxwidgets. I've been meaning to see if I can do something about that, because it's a bit inconvenient. (And as a result, I've been doing almost all testing on Debug builds.)

Issues you'll note with the Linux version currently: It crashes on exiting if a game was running, and skipping the bios doesn't work. That's in addition to the known issues on Windows...

airmake...

That's good to know. Not really sure how Arch builds wx, need to find out :p One quite inconvenient thing about using Code::Blocks is that making packages for it is a mess, and requiring Code::Blocks to build it not clean at all. I'm the maintainer of pcsx2-svn, but I really don't know if I should just stick with the legacy_gui for a long time, or requiring code::blocks.

The headers are located under: /usr/include/wx-2.8/wx for example. Is that the case in your distro?

arcum42

Looks like it. Code::Blocks is using:

wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags

to get the flags, which provides the location of the headers, but is obviously pretty specific about what version it's looking for.

And yeah, I'm still not sure what to do on the package side, because it provides issues setting up packages for Gentoo, too, which I use. Hopefully, I'll manage to re-rig up a makefile system at some point, strictly for packages that build from source.

Trouble is that I know the previous makefile system wasn't able to handle the way the layout of the project is currently, so there are going to be a bunch of hassles doing that...

airmake...

Ok, it looks like wx is built without debug info in Arch.

#non-debug

wx-config --version=2.8 --static=no --unicode=yes --debug=no --cflags

-I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread

#debug

wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags

Warning: No config found to match: /usr/bin/wx-config --version=2.8 --static=no --unicode=yes --debug=yes --cflags

in /usr/lib/wx/config

If you require this configuration, please install the desired

library build. If this is part of an automated configuration

test and no other errors occur, you may safely ignore it.

You may use wx-config --list to see all configs available in

the default prefix.

I'll try to get things working on my side, then.

airmake...

Hmm ... Well, at least it doesn't whine about wx headers anymore, when I build as release. I get a different error though. Not sure if I should post here, or make a new issue, but hey. It looks trivial at least.

/tmp/pcsx2-read-only/pcsx2/gui/Dialogs/AboutBoxDialog.cpp:51: error: ‘res_Dualshock’ was not declared in this scope

/tmp/pcsx2-read-only/pcsx2/gui/Dialogs/AboutBoxDialog.cpp:51: error: template argument 1 is invalid

arcum42

Yeah, it is. It never got set back up to generate Dualshock.h when the graphic changed, and I still had the old header around for it to find, so I didn't notice. I'll take care of it...

Revision 1938

Fix Dualshock.h on Linux.

airmake...

Sweet :) Now, the wx version builds in codeblocks with Release build :D

arcum42

Glad to hear it. It was one of these things where it built on my side due to a legacy file that it wasn't generating any more that was still in my trunk...

airmake...

Hmm... Having weird problems, that my bios can't be found with the wx build, even though I point it to the correct folder :V Is it a way to brute force it in the .ini file or something?

airmake...

It should be noted that I tried to copy over a wx-PCSX2 into a legacy_gui PCSX2-folder and run it from there.

arcum42

Under [Filenames] in pcsx2.ini, the BIOS line says:

BIOS=/usr/local/src/pcsx2-1/bin/bios/rom0.bin

in mine (noting that I'm running it in /usr/local/src/pcsx2-1/)

Also, I've had issues with it not defaulting to the right folder unless I uncheck and check the Default button below it before. Not sure if that's fixed or not; issues on initial setup are hard to reproduce...

airmake...

Indeed. Can you copy-paste your pcsx2.ini, so I have something to work with? :)

arcum42

Sure, though I'd sure you'll need to modify at least some of this:

MainGuiPosition=19,111

SettingsTabName=Plugins

LanguageId=0

RecentFileCount=6

DeskTheme=default

Listbook_ImageSize=32

Toolbar_ImageSize=24

Toolbar_ShowLabels=enabled

CurrentIso=/usr/local/src/tmp-iso/iris.iso

CdvdSource=Iso

file1=

file2=

file3=

file4=

file5=

file6=

[MemoryCards]

Port0_Slot0_Enable=enabled

Port0_Slot0_Filename=Mcd001.ps2

Port0_Slot1_Enable=disabled

Port0_Slot1_Filename=Mcd003.ps2

Port0_Slot2_Enable=disabled

Port0_Slot2_Filename=Mcd005.ps2

Port0_Slot3_Enable=disabled

Port0_Slot3_Filename=Mcd007.ps2

Port1_Slot0_Enable=enabled

Port1_Slot0_Filename=Mcd002.ps2

Port1_Slot1_Enable=disabled

Port1_Slot1_Filename=Mcd004.ps2

Port1_Slot2_Enable=disabled

Port1_Slot2_Filename=Mcd006.ps2

Port1_Slot3_Enable=disabled

Port1_Slot3_Filename=Mcd008.ps2

[ProgramLog]

Visible=disabled

AutoDock=disabled

DisplayPosition=379,0

DisplaySize=680,560

FontSize=8

[Ps2Console]

Visible=disabled

AutoDock=enabled

DisplayPosition=399,111

DisplaySize=680,560

FontSize=8

[Folders]

UseDefaultPlugins=enabled

UseDefaultSettings=enabled

UseDefaultBios=enabled

UseDefaultSnapshots=enabled

UseDefaultSavestates=enabled

UseDefaultMemoryCards=enabled

UseDefaultLogs=enabled

Plugins=

Bios=

Snapshots=

Savestates=

MemoryCards=

Logs=

RunIso=/usr/local/src/tmp-iso

[Filenames]

GS=/usr/local/src/pcsx2-1/bin/plugins/libZeroGSoglr.so.0.18.168

PAD=/usr/local/src/pcsx2-1/bin/plugins/libOnePAD.so.0.1.0

SPU2=/usr/local/src/pcsx2-1/bin/plugins/libZeroSPU2.so.0.1.0

CDVD=/usr/local/src/pcsx2-1/bin/plugins/libCDVDiso.so.0.9.0

USB=/usr/local/src/pcsx2-1/bin/plugins/libUSBnull.so.0.6.0

FW=/usr/local/src/pcsx2-1/bin/plugins/libFWnull.so.0.5.0

DEV9=/usr/local/src/pcsx2-1/bin/plugins/libDEV9null.so.0.4.0

BIOS=/usr/local/src/pcsx2-1/bin/bios/rom0.bin

[EmuCore]

CdvdVerboseReads=disabled

CdvdDumpBlocks=disabled

EnablePatches=disabled

SkipBiosSplash=disabled

McdEnableEjection=disabled

MultitapPort0_Enabled=disabled

MultitapPort1_Enabled=disabled

[EmuCore/Speedhacks]

EECycleRate=0

VUCycleSteal=0

IopCycleRate_X2=disabled

IntcStat=disabled

BIFC0=disabled

vuFlagHack=disabled

vuMinMax=disabled

[EmuCore/CPU]

sseMXCSR=65472

sseVUMXCSR=65472

vuOverflow=enabled

vuExtraOverflow=disabled

vuSignOverflow=disabled

vuUnderflow=disabled

fpuOverflow=enabled

fpuExtraOverflow=disabled

fpuFullMode=disabled

[EmuCore/CPU/Recompiler]

EnableEE=enabled

EnableIOP=enabled

EnableVU0=enabled

EnableVU1=enabled

UseMicroVU0=enabled

UseMicroVU1=enabled

[EmuCore/Video]

EnableFrameLimiting=disabled

EnableFrameSkipping=disabled

DefaultRegionMode=ntsc

FpsTurbo=240

FpsLimit=60

FpsSkip=55

ConsecutiveFrames=2

ConsecutiveSkip=1

[EmuCore/Gamefixes]

VuAddSubHack=disabled

VuClipFlagHack=disabled

FpuCompareHack=disabled

FpuMulHack=disabled

DMAExeHack=disabled

XgKickHack=disabled

MpegHack=disabled

[EmuCore/Profiler]

Enabled=disabled

RecBlocks_EE=enabled

RecBlocks_IOP=enabled

RecBlocks_VU0=enabled

RecBlocks_VU1=enabled

arcum42

Looking closely, looks like I took SCPH-50001_USA_Con_0170_20030325_v9_[C898DF82].rom0 and SCPH-50001_USA_Con_0170_20030325_v9_[EB7CA0AA].rom1 and made copies of them named rom0.bin & rom1.bin in the bios folder[1]. It's possible it might be detecting the names incorrectly...

[1] And, obviously, totally forgot about it.

arcum42

Yep, that's what it is. Symbolic links to *.rom0 and *.rom1 named rom0.bin and rom1.bin should suffice till it's taken care of.

arcum42

In fact, looks to me like it's just filtering out anything not ending in *.bin.

Jake.Stine

Does anyone have a bios file not ending in *.bin? rom1, rom2, and erom files are not primary rom files, so they should generally be ignored when enumerating. Although I guess there's no real harm in enumerating "everything" like the old PCSX2 did. Maybe someone uses .rom for an extension on the primary bios rom file?

arcum42

Mine don't end in bin, for whatever reason.

I seem to recall that when the bios extracting program generated a bat file, I renamed it to be a 7z file and extracted the files, since I didn't have access to Windows at the time. It's possible the bat file may rename things.

Perhaps I should rerip and see how things look. I just got my ps2 set back up, so I can actually do that if need be...

Revision 1939

Bring in cdvdGigaherz (step 1).

Revision 1940

Undo my little mess. Fix it next commit

Revision 1941

Whoops missed 2 files.

Revision 1942

Properly add the project stuff so it "fits" with the build system used on all

the other plugins.

Revision 1943

Remove custom settings from the vcproj which were already globally defined in

the vsprops.

Fix a silly bug too, and silence a warning.

Revision 1944

Fix error on release build.

Revision 1945

Unbreak Debug too.

Revision 1946

Just a tiny cosmetic change in the plugin name string.

gigaherz

Ok you can comment now, I'm not commiting anythign else. XD

radu12...

Alright thanks. I'm going to delete my other comments so as not to spam this. But will you guys look into it?

gigaherz

Well i'm not the one who codes gsdx, that'd be Gabest, so it's mostly up to him. I'm sure he will check it, at one point or another.

radu12...

Thank you very much. I haven't seen him around for a while though... I'm getting worried.

gigaherz

Nah, he's just not very active. Some time ago he was gone for like a year. A few weeks are nothing. :P

ramapcsx2

In the meantime go back to the revision that worked. I've told you in the forums before, this is NOT a simple fix.

Bringing it up every day lowers the odds of it being worked on, you know? ;)

Thanks for upping this, gigaherz. We now have working CDDA support :)

Revision 1947

SPU2-X: Fixed some more major bugs and typos; most sound *should* be working

again now. Added a hackfix for a crash in the BIOS cased by what *should* be

correct handling of IRQAs.

Jake.Stine

Notes on this revision, for Rama and anyone else interested:

The "current" DMA functionality of testing only the current core's IRQA is in fact what SPU2-X has been doing since the dawn of time, which is why that weird BIOS hackfix wasn't needed. So right now "hacked" mode is basically the status-quo for what we've been doing all along. Translation: The hack shouldn't break anything that wasn't already broken.

I re-added code for the original ReadInput, which can be commented out in case you want to regression-test it. The BIOS CD Player in particular needs tested, if someone can do that for me. I'm still waiting on a new DVD drive for my PC, and I'm too lazy to make an audio iso and mount it with Deamon Tools :p

Revision 1948

Added some DebugBreak generation (INT3 / 0xcc) to the PsxRec, for catching null

pxsRegs.pc assignments from the recompiler (enabled in DEBUG builds only).

These are usually more context-useful breakpoints than the assert() check in

psxRecompile.

Revision 1949

Win32 build system:

* Re-enabled function-level linking in the shared properties sheets (applies to

debug and devel builds, and is ignored in release builds). Can't remember why

it got disabled in the first place, but whatever errors it was causing seem to

be gone now.

* Removed the wxWidgets 2.9/3.0 copy of wxScopedPtr (wx/scopedptr.h), since we

have a new superior implementation of our own.

Revision 1950

Lots of new code maintenance stuffs:

* Completely new assertion macros: pxAssert, pxAssertMsg, and pxFail,

pxAssertDev (both which default to using a message). These replace *all*

wxASSERT, DevAssert, and jASSUME varieties of macros. New macros borrow the

best of all assertion worlds: MSVCRT, wxASSERT, and AtlAssume. :)

* Rewrote the Console namespace as a structure called IConsoleWriter, and

created several varieties of ConsoleWriters for handling different states of log

and console availability (should help reduce overhead of console logging

nicely).

* More improvements to the PersistentThread model, using safely interlocked

"Do*" style callbacks for starting and cleaning up threads.

* Fixed console logs so that they're readable in Win32 notepad again (the log

writer adds CRs to naked LFs).

* Added AppInit.cpp -- contains constructor, destructor, OnInit, and command

line parsing mess.

Revision 1951

SPU2-X: Fix CDDA playback, which got broken a few revs back; and remove

regression test code (ReadInput is pretty well confirmed to be good now,

anything still broken is because of something else).

Revision 1952

Linux: Minor fixups!

Jake.Stine

Also! One of the benefits of the new pxAssert macros is that we no longer need to rely on wxWidgets debug builds for debug/assert functionality. It's not entirely ready yet, since the new pxOnAssert() still needs its own popup window handlers to replace wx's (wich don't exist in release builds of the lib, annoyingly).

So hopeflly we'll be able to nip that linux debug/release annoyance in the bud here soon.

arcum42

Sounds promising.

The two main issues I'm seeing on the Linux side at the moment are that the skip bios option doesn't work, and that exiting is causing assertions if the emulator has been started. (Both of these have been issues for a while.)

A few games crash on startup, but I normally don't launch those games via the bios, so that could be a result of that bug.

I've been fixing my home file server for the last few days, and it's left me not doing much coding, partially because most of my isos are on it. It's almost back up and running, though. Just have to figure out why samba isn't sharing anything on the network after my reinstall...

Deyan...

can I ask one question?Where can I download these versions?I know it is a stupid question but forgive me.

powerzx78

@[email protected] & mercer550 if you want compiled new versions for windows, then visit http://www.emudreams.pl/

ramapcsx2

But do remember they're still not done.

Don't expect to play games on these, there isn't even a framelimiter yet.

Jake.Stine

>> The two main issues I'm seeing on the Linux side at the moment are that the skip bios option doesn't work ...

doesn't work here either so don't feel bad. I dunon why I can't keep it working. :p I'm going to *really try* to get savestates working today tho, and then start tidying up some of the little things again, and then get the framelimiter implemented.

Jake.Stine

@arcum: On crashes, I'm pretty sure I need to force-disable EBP allocations in the EEcore recompiler for linux to be stable. I'm using C++ exceptions now as an optimization for exiting the recompiler, and linux implementation depends on EBP (Windows uses SEH, which works without EBP). The EE core clobbers EBP though, so if ou happen to try to exit the rec when you're in a block that's changed EBP, it will probably fail >_<

Unfortunately zerofrog never allowed for ebp to be disabled, because apparently he hated debuggers. He has a switch that disables allocation to eax+ecx+ebp all at once, but that's major overkill. I'll see what I can do.

Revision 1953

Bind the cdvd's newDiskCB properly when changing CDVD sources; and more

jASSUME->pxAssert change-overs.

ramapcsx2

This worked :)

Revision 1954

Minor fix to r1953.

Revision 1955

Linux: We don't need no stinkin' muldefs! (fyi, turns out the solution was to

use the "inline" keyword on class member prototype definitions, yes that simple

-_-)

Revision 1956

legacy_gui frees itself of the shackles of -zmuldefs as well! (not actually

tested since I could never get legacy gui to build on my linux distro here)

arcum42

Tested it, and it builds...

Jake.Stine

zedron says the legacy gui here still gets some muldefs on GTK code. That's outside my jurisdiction tho. If you disable -zmuldefs from the makefile they should show up, if you feel like fixing them.

Zedron needs them fixed for the Mac build because OSX's ld lacks the -zmuldefs "feature". Either it builds clean with no muldefs, or it fails :(

arcum42

I'll check it. I probably didn't do a full rebuild, since I was on my way out the door...

arcum42

Actually, come to think of it, the fact that -zmuldefs is still the configure.ac file probably has a lot to do with it working, doesn't it?

Assumed that was already done. Oh well...

Revision 1957

Better fix for zmuldefs. Less warnings in MSVC and GCC both. :)

Revision 1958

wiki: Updated for w32pthreads.v3.dll

Revision 1959

Renamed PCSX2_ALIGNED to __aligned and removed the need for excess parenthesis

and oddball qualifiers. Left the old macros in Pcsx2defs.h for now, just in

case. Redid some of the storage organization of microVU and iFPU consts and

temporaries while I was at it, using structs instead of naked vars -- should

improve cpu cache behavior a wee bit.

arcum42

_aligned fits better with some of the other defines we're using, I think...

Revision 1960

Two minor cosmetic fixes from the __aligned switchover.

Revision 1961

Added a gamefix that should fix the messed up camera views in Gundam games like

"Mobile Suit Gundam Seed Destiny: Rengou vs. ZAFT II Plus" and the other ones

that had this problem.

No need to set roundmode to nearest anymore, just use the gamefix.

also i think i also have to add this fix to iFPUD.cpp stuff, i'll do it

tomorrow.

btw, this fix is untested because i don't have the time today to test it w/o

working saved states.

cottonvibes

okay its not working yet.

i'll fix it tomorrow...

Revision 1962

More zmuldef stuff for the legacy gui.

arcum42

The change to LnxSysExec is a bit of a hack, really. What I should have done is just abstracted out the file selection code. Or at least renamed the variable and kept it local.

Didn't feel like putting that much time into gui code that we've already removed, though. :(

arcum42

In any case, this ought to straighten out zmuldef for the legacy gui. Most of it was just stuff being included in Linux.h that really shouldn't have been.

Two of the variables weren't even used. I'd just kept them around in case I felt like redoing the logging dialog, because it would have been a bunch of typing to redo...

Revision 1963

Fix Linux. (While things in [] in inline assembly in gcc may look like variable

names, they are actually labels that I've set to look like the variable names to

ease readability. Unfortunately, labels can't have periods in them...)

arcum42

I figure "Row0", "Row1", "Col0", and "Col1" is readable enough here...

Revision 1964

Linux: Added more correct __asm__ qualifiers and conditions; including

__volatile__ on a lot of asm code (it should really be the default behavior and

non-vlatile the specifier, but whatever >_<), and added register clobber

specifiers. Might help unbreak some of GCC 4.4's optimization problems,

although VIFdma's uber-hack SSE optimization looks like a real problem.

Jake.Stine

Read VifDma diffs for laughs.

Also! I changed RecExecute, so maybe everything's broken, or maybe it works fine. Please test that for me (I still can't quite run that far in linux).

Jake.Stine

Oh, and we could explicitly map the yuv and sse2 stuff to ecx and edx, (c and d), but it should do that for us regardless, so I left it generic.

arcum42

Unfortunately, I'm going for everything's broken. On Atelier Iris 1, the dolby animation shouldn't be bright pink, and most of the games I tried crash early on, and have distorted colors in movies.

I'll mess with it some more, though.

arcum42

Oh, and something I spotted a while back, but forgot to mention; starting Dark cloud 1 currently gives a "Impossible block clearing failure". :)

Not a new issue to this revision, though.

arcum42

Well, the color issues are local to the yuv2rgb.cpp changes. Not sure about the segfaults yet.

max...

Windows version possible brocken?

iR5900-32.cpp(691) : error C2061: error de sintaxis : identificador 'emms'

Jake.Stine

Yea FMV breakages would be the fault of the yuv/rgb code. I see what I scewed up. I'll work on fixing that (small bug).

The segfaults could be any of the changes I guess, so regression test until you find the asm change that causes it and let me know which.

Jake.Stine

... and I'll fix windows builds in a minute,

arcum42

I'm doing so. Just thought I'd verify that it was the yuv/rgb code on the color changes first. Seemed obvious (which is why it was the first thing I checked), but it pays to be certain...

arcum42

I'm regression testing, that is.

Jake.Stine

Hopefully finding the cause of the crashes might shed some more light on what causes other crashes.

.. and I see I forgot something important in iR5900-32.cpp regarding EBP.

Revision 1965

Fix win32 compilation error, and fix Linux FMVs and (hopefully) some segfaults

too, likely caused by not saving EBP.

arcum42

That took care of the colors issue. The segfault I was looking at looks like it's from an earlier revision. Didn't expect it to be because it's a game I test often.

I'm currently in process of determining the revision...

arcum42

Grrr...

I switched what directory I was compiling the trunk in due to some unsaved changes in my main trunk. Turns out I had an old copy of ZZOgl in there that was causing the crash.

I'll do more testing to see if anythings crashing that shouldn't be, but I think that was it...

Jake.Stine

ah, good. For a minute I was fearing the __aligned changeover would be the cause... >_<

arcum42

Think that was it. ZeroSPU2 wants to crash FFX, but I'm not going to worry too much about that right now...

arcum42

Actually, the FFX issue looks like an intermittent one. I'll worry about it later, though, since I need to get some sleep...

arcum42

At a guess, issue 327 , actually. :)

Revision 1966

Minor buildsystem changes (remove some warnings and add function level linking

option to all 3rdparty libs)

Revision 1967

Win32: Improved batch files for clean_msvc and preBuild, using %~dp0 to fetch

the folder/location of the command script.

sunnydra...

troubles compiling code under linuxx86 gcc 4.3.3 with new pxAssert and etc implementations i got error

expected primary-expression before ‘,’ token

compiler not like much define x(p) x2(p, pz);

i am missing something? (svn trunk is fresh)

sunnydra...

so far seems okay in dev build but it's still going on..

Revision 1968

More Vif register stuff.

arcum42

Forgot I'd made the bios change, but it should be harmless.

The IopHw changes are because I started to clean up IopHw.cpp, then decided to make sure I wasn't revising something that was just going to be rewritten later, or was there just for reference.

And, yeah, more of the same register changes I've been doing.

arcum42

(And yes, these are the changes I had sitting in my main trunk I was referring to.)

Revision 1969

More MSVC/Win32 buildsystem fixes: Made is so you can now optionally unload all

3rdparty libs (after building at least once!) and still build the rest of PCSX2

and plugins without linker errors. This is useful for reducing the memory

overhead of working in the MSVC IDE, and reduces the size of the .ncb file and

the bugs that come with it.

Jake.Stine

Oh forgot to mention! I also added more cleanup files to the MSVC buildsystem, so using clean_msvc should be a less frequently-needed occurrence. The build system now cleans things like bsc, pdb, and ilk files when you select "Clean" (which are typically the sources of rebuild failures).

Revision 1970

Still doing register stuff.

arcum42

I decided to add a few helper functions to the register unions. I just thought this makes it a bit easier to read, though I've only done the stat ones as of yet.

Revision 1971

Don't believe we really need an xml parser in pcsx2. I've moved it to 3rd party,

in case we want it at some point. Removed the xml loader code as well.

Jake.Stine

Speaking of that, someday I'd like to turn patch handling into a plugin.

We talked it over on IRC repeatedly and everyone pretty well agreed it should be a plugin, since there's quite a few ways to handle patches and cheats (dialogs, UIs, file formats, etc).

A patch plugin would be a simple interface too, it'd just query the patch plugin at the same few pre-defined points (one in vsync, and I think one other elsewhere?).

gigaherz

The other one would be right after the executable loads, giving it the CRC and all.

arcum42

I remember seeing the preliminary code hit svn for that. I thought it was a good idea, too. That way people can build special interfaces to their hearts delight on it. I could even see cheat plugins for specific games appearing. (I'm almost certain Final Fantasy X would get one.)

And it looks like it tries to apply patches both in cdvdDetectDisk and in cdvdReadKey. With the same copied and pasted code, in fact...

I'd wanted to get rid of the xml code for a while, though. I just kept getting distracted by other things.

arcum42

Note: Sorry, not the same copied and pasted code. It's slightly different.

arcum42

Incidentally, Jake, the Skip bios being broken right now appears to actually be most of the options being broken. I don't think anything set in g_Conf->EmuOptions ever gets to EmuConfig.

Noticed because I chose SuperVU and got microVU...

ramapcsx2

Agreed on both, the xml loader (old idea to patch every ps2 game with roundmodes is old :p ) and the Patch plugin idea.

Jake.Stine

Yeah, I'm working on saved states again, and will fix the settings along with. I got distracted this weekend doing project maintenance work on asserts and other macros and buildsystem crapola that's been bugging me, but I'm back on track now. :)

arcum42

np, just wasn't sure if you if you'd traced it that far. Doesn't matter that much to me, because skip bios doesn't work in Linux even when the settings work. (It starts to boot the bios, then throws a "ExitRecExecute" exception. At a guess, it should be exiting the bios at that point instead of quitting).

And I'll admit to being easily distracted myself...

Jake.Stine

>> (It starts to boot the bios, then throws a "ExitRecExecute" exception. At a guess, it should be exiting the bios at that point instead of quitting).

That's good, in a way. It's not being caught where it should be because of EBP being used by the rec. So if we can successfully turn off EBP allocation, then SkipBios should start working. So it's an easy test of EBP/working exceptions.

arcum42

Which should be useful. Irritating when testing games, but at least we'll know when ebp allocation is off...

arcum42

Oh, I noticed that the issues exiting in Linux after emulation starts are from when it does a reset of the emulator. Once Pcsx2App::SysReset is called, the emulator basically goes into limbo, and will crash on wxYield the next time to try to reset, exit, or start back up emulation.

(If I choose reset, it does the same thing, and never gets past Pcsx2App::SysReset in Menu_EmuReset_Click...)

ramapcsx2

/Spam

They're savestates, not saved states! (Yeah, I know the latter makes more sense :p

/End Spam

Jake.Stine

Syntax Error on Line #2. Expected ) before /End

Revision 1972

legacy_gui: Some small fixes courtesy of Zedr0n..

* fixes using Run->Execute as the first action after starting the emu.

* Slightly cleaner muldefs fixes (macs must really hate muldefs!)

Jake.Stine

.. forgot to tag it as linux only. >_>

Revision 1973

Linux: Experimental fix for exception propagation out of the recompiler; this

version is based on the theory that the cause is GCC optimizing out exception

handling because it sees the inline asm "call DispatcherReg;" as a no-throw().

So I removed the asm and replaced it with a direct C++ invocation. This should

work since the new rec never exits except via catch() clauses anyway, so

pushing/popping clobbered registers isn't needed.

Jake.Stine

@Arcum: Give this a test with the bios skip force-enabled, and see if the exception works properly.

arcum42

It does, in fact, work properly, so that must have been it. (Which tells me that a few games that currently crash on startup aren't doing it because of not starting through the bios, but I'll look at that later.)

Looking good, though we'll have to be careful about mixing assembly and exceptions...

Jake.Stine

Yeah, this case was exceptional (pun!) because it was asm code *inside* a try/catch block. I could have also fixed it by exporting the asm code into a separate function and specifying noinline. So I don't think it'll be a problem anywhere else. So long as GCC doesn't "think" i can optimize out the catch handlers, it should be fine.

On crashes: Post some stackdumps in an issue or something, when you have time. We'll see what we can figure out.

arcum42

I know I had more then one game crashing, but concentrating on the one that I know about first, it looks like iVif decided to become temperamental again, because it's a reoccurrence of the issue I worked around previously on it (only without mask being 0).

Works fine if I set it to always call "UseOldMaskCode", but I hate to have Linux specific code if I don't have to...

arcum42

BTW, happened upon this article, and thought it might be of interest:

http://www.ibm.com/developerworks/linux/library/l-cppexcep.html

arcum42

Out of curiosity, any reason to keep pushing and popping the registers for DispatcherReg on Windows here? Seems like if it isn't necessary any more, we may as well not do it any more on either platform...

Revision 1974

wxWidgets/Win32: Keep wx from including <windows.h> into every app/gui related

file; reduces window.h global namespace pollution and speeds up compilation

times a little bit.

Revision 1975

Savestates work! Not much else does yet (settings, etc), but at least this

monkey's off my back. I can work on tying up more loose ends now. :)

mattme...

And there was much rejoice.

jfre1...

And cake. Grats on finally getting that big issue out of the way.

zantezuken

The cake is a lie!

Nice job with savestates. At last :P

arcum42

Glad to have savestates, but saving in Linux crashes ZZogl and ZeroGS currently. Not sure if it does in Windows or not; I'll have to check.

Having dealt with no savestates for a while, this doesn't have to be an immediate priority, though.

Here's a stack trace, using ZZOgl r184:

Saving savestate to slot 0...

filename: /usr/local/src/pcsx2-1/bin/sstates/4D2CAC9D.000

Saving GS

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread 0xe9bffb90 (LWP 5807)]

0xf0866532 in glBindTexture () from //usr//lib/opengl/nvidia/lib/libGL.so.1

(gdb) bt

#0 0xf0866532 in glBindTexture () from //usr//lib/opengl/nvidia/lib/libGL.so.1

#1 0xf0aca7aa in ZeroGS::CRenderTarget::Resolve (this=0xec7025b0) at targets.cpp:277

#2 0xf0add97c in ZeroGS::Save (pbydata=0xe8c4d87d "") at targets.h:73

#3 0xf0aa2a3c in GSfreeze (mode=0, data=0xe9bff048) at GSmain.cpp:1245

#4 0x080f9658 in PluginManager::DoFreeze (this=0x942fa90, pid=PluginId_GS, mode=1, data=0xe9bff048)

at /usr/local/src/pcsx2-1/pcsx2/PluginManager.cpp:1048

#5 0x080f97ae in PluginManager::Freeze (this=0x942fa90, pid=PluginId_GS, state=@0xe9bff144)

at /usr/local/src/pcsx2-1/pcsx2/PluginManager.cpp:1091

#6 0x08119cac in SaveStateBase::FreezeSection (this=0xe9bff144) at /usr/local/src/pcsx2-1/pcsx2/SaveState.cpp:289

#7 0x08119f3d in SaveStateBase::FreezeAll (this=0xe9bff144) at /usr/local/src/pcsx2-1/pcsx2/SaveState.cpp:346

#8 0x08115d64 in StateThread_Freeze::ExecuteTask (this=0x9614e18) at /usr/local/src/pcsx2-1/pcsx2/RecoverySystem.cpp:102

#9 0x082d496d in Threading::PersistentThread::_try_virtual_invoke (this=0x9614e18,

method=&virtual Threading::PersistentThread::ExecuteTask()) at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:206

#10 0x082d4ea5 in Threading::PersistentThread::_internal_execute (this=0x9614e18)

at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:291

#11 0x082d4ef5 in Threading::PersistentThread::_internal_callback (itsme=0x9614e18)

at /usr/local/src/pcsx2-1/common/src/Utilities/ThreadTools.cpp:305

#12 0xf781efcb in start_thread () from /lib/libpthread.so.0

#13 0xf77a3b5e in clone () from /lib/libc.so.6

Revision 1976

Resolve some Linux/GCC errors.

Revision 1977

Linux: Revert to using the old masking code in iVif at all times, until we can

figure out why the other masking code frequently crashes under Linux.

Jake.Stine

I did some disasm checks of the codegen in 4.40, in both debug and release modes, and it looked perfectly fine. Are you still using 4.3.x? or 4.4? It could be a bug specific to 4.3.x.

In any case we could make this routine an emitter function, and all problems would be solved. :p

arcum42

Last time I rebuilt my chroot, I installed gcc 4.3.3. I actually have to unmask gcc 4.4.1 if I want to use it, because they haven't marked it as stable on gentoo yet. [1]

I can install gcc 4.4 and test with it; it'll just take a while. [2]

Making it an emitter function is probably a good idea, though... :)

[1] Since gentoo[3] is source-based, they usually don't unmask versions of gcc till they have most of the packages that don't build with it fixed...

[2] Again, gentoo installs everything from source. And gcc builds take forever. I usually do them when I'm going to be doing something else for a while...

[3] Gentoo being the Linux distribution I use.

Revision 1978

Linux: some more minor tweaks to project files and compilation errors (release

mode only)

Revision 1979

Linux: oops... committed the asm dumping switch by accident

Revision 1980

Assorted minor VifDma changes.

arcum42

Not a big commit. Think I've made a few of these changes several times, and then lost them when reverting bigger changes, so I thought I'd commit them now.

Interesting to note that several of the section labels in VifDma were wrong, though.

Revision 1981

Chop up VifDma into a few pieces.

arcum42

Basically, all the Vif0 and Vif1 functions now have their own files, and can be looked at and compared side by side.

I also added templates to some functions in VifDma.cpp.

I'd like to have a lot less duplicated code in VifDma, and separating it so you can see what's duplicated seemed like a good way to start.

Jake.Stine

1 line-by-line comment

/trunk/pcsx2/Vif1Dma.cpp  

r1981  

line 1130:

1130: vif1Regs->stat._u32 = (vif1Regs->stat.test(~VIF1_STAT_FDR)) | (value & VIF1_STAT_FDR);

warning C4805: '|' : unsafe mix of type 'bool' and type 'u32' in operation

This is a meaningful warning, and I don't think this code is doing what it's intended to do. I'm not sure where the actual change occurred, yet but figured I'd note it here for now, since you probably remember the code changes better.

arcum42

I recall thinking that that didn't look right yesterday, but was on my way to bed. I'll revert that line. (It's from r1970, btw. )

Revision 1982

Get rid of a few Windows compilation errors.

arcum42

Well, warnings, not errors, but you know what I mean.

Revision 1983

SPU2-X: fix a memory leak that dropped a few Kbytes of memory on every

suspend/resume (it's been there for ages too; SoundTouch object wasn't being

deleted).

Revision 1984

Fixed a memory leak in the MutexLock object.

arcum42

Well, this is interesting. _CrtSetBreakAlloc( spot ); was obviously a Microsoftism, so I ifdefed it out.

The fact that pcsx2 now starts emulation the moment I open the program, and then crashes due to CDVD being null is odd, though...

Jake.Stine

... That's pretty random. I'd suggest doing a full clean/rebuild if you haven't already.

arcum42

Yeah, a full rebuild took care of it.

That was strange, though.

Revision 1985

Revert one of my changes from r1970.

arcum42

That was not a spot where it actually was a test, so shouldn't have been changed; I just got a little carried away... :(

Revision 1986

Linux: Fix compilation.

Revision 1987

wxWidgets/Win32: Added a private heap allocation feature, which directs all

wxString and wxObject allocations through a Windows private Heap (should reduce

fragmentation and multithreaded contention when allocating/freeing blocks)

(and fix some oddball compilation errors in spu2-x in rare circumstances)

bigianb

Looks like you forgot to add HeapAllocator.h

2>c:\src\pcsx2\3rdparty\wxWidgets\include\wx/string.h(178) : fatal error C1083: Cannot open include file: 'wx/msw/HeapAllocator.h': No such file or directory

2>Build log was saved at "file://c:\src\pcsx2\3rdparty\wxWidgets\build\msw\Win32\Debug\wxAdv28\BuildLog.htm"

2>wxAdv28 - 1 error(s), 0 warning(s)

maurizio...

Confirm

same for me , Cannot open include file: 'wx/msw/HeapAllocator.h'

Revision 1988

Minor cleanups -- removed unnecessary "using namespace std;" declares, etc.

Jake.Stine

crap! I was intentionally trying to avoid committing my copy of lilypad. I have no idea what's wrong with it and I wanted to finish up my outstanding changes and figure out how I ended up with some weird totally different version of the project file.

And I committed it anyway >_<

Jake.Stine

Oh I think I see what it did. It just re-arranged the x64 and x32 builds arbitrarily. Makes it look like all kinds of stuff changed, but really nothing changed. MSVC just decided to move the Win32 builds to the top and the x64 builds to the bottom... -_-

So it's safe. Just a pointless change more or less. Stupid msvc :p

mattme...

Yea, noticed one of my earlier commits flipped their order for no good reason, too. Kinda funky.

Revision 1989

wxWidgets/Win32: Helps when I include the necessary files (HeapAllocator.cpp /

HeapAllocator.h)

Revision 1990

wxWidgets: Bugfix to the private heap, caused by me recovering the wrong file to

commit to svn. -_-

Revision 1991

wxWidgets: helps if I fix *both* string and object allocators. I'm a commit

spammer tonight. -_-

Revision 1992

Made hwDmacSrcChain & hwDmacSrcChainWithStacks a bit easier to follow. Misc

other changes, mainly register related, or making use of existing constants.

Revision 1993

Settings work again!

* Switched the SysCoreThread to a static (fully persistent) thread.

* Added some listeners for when the CoreThread status changes

* fixed some slowness in savestates, and the emu will now stall until

savestates complete, if you try to exit too quick (avoids savestate corruption)

ardza...

Finally ^^. Now i can play Mana Khemia. Thanks a lot.

tom.mat...

Ah and I wondered what broke the settings :p

Revision 1994

Fixed: Savestate bug when saving caused erratic freezeups.

Fixed: More savestate slowness, and less savestate memory hogging.

SPU2-X: Fixed crash bug on using savestates while suspended.

Jake.Stine

@rama: and I'm wrong, wizard no hang. I misread the log. Eveyrhing looks fine there.

Revision 1995

Quick save menu fix.

arcum42

The fix for this was pretty obvious, so I only tested this to the extent of saving and loading a couple saveslots in Windows.

pcsx2gu...

Confirmed. Thanks arcum :)

arcum42

No problem...

Revision 1996

Fix GSdx game patches not loading when bios skip hack enabled.

heatbla...

Long time no see. I`ve tested the latest WIgui. Interesting that Steambot Chronicles boots in new WGUI but still crashes with the PCSX2 svn betas. And btw, if you play STMB the demo works just fine with GSDX10 hardware... only the ingame is with these glitches and that slow speed...

Revision 1997

A couple misc changes. Converted a few more lines to the new register format,

fixed spelling in a few comments, and so on...

Revision 1998

Fix minor mistake in my last commit.

ramapcsx2

2 line-by-line comments

/trunk/pcsx2/Sif.cpp  

r1998  

line 139:

139: if (sif0.sifData.data & 0xC0000000) // If NORMAL mode or end of CHAIN, or interrupt then stop DMA

This here really needs fixing. Wanna help? :p

/trunk/pcsx2/Sif.cpp  

r1998  

line 271:

271: if ((sif1dma->chcr.MOD == NORMAL_MODE) || sif1.end) // If NORMAL mode or end of CHAIN then stop DMA

It should look mostly like this I assume.

arcum42

Keep in mind comments are often misleading. The comment on line 138 is mine, though. I've been saving some of the trickier ones for last, and while I know how xxx#dma-> works, I haven't really looked much at sif#.sifdata yet.

The li9ne in question is basically saying 'if either of the last two bits of the tag are set'. The last bit is the Irq tag, so a Tag::IRQ(sif0.sifData.data) would be in order for that. (which would be the interrupt mentioned)

Not sure offhand what bit 30 of that tag is, though.

And I suspect that the code may be wrong there, but am not totally sure. My guess at what it should be is:

if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))

But that's not what the actual code does right now. Wonder if it breaks anything if I substitute that?

arcum42

li9ne -> line

Yay for uneditable comments.

ramapcsx2

I'm all for testing this out.

Give me some more "versions" of what it *should* be, and I'll test them here :p

ramapcsx2

"if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))"

I'm running this version currently. So far so good (no changes in compat yet).

arcum42

Well,

if ((sif0.sifData.data >> 30) || Tag::IRQ(sif0.sifData.data))

is about what it's doing now.

But I'm more inclined to go with my first version, after trying a few games without any issues. Trouble is, I'm not sure what games make heavy use of Sif0...

ramapcsx2

if ((sif0dma->chcr.MOD == NORMAL_MODE) || sif0.end || Tag::IRQ(sif0.sifData.data))

{

if (sif0.sifData.data & 0xC0000000){}

else Console.WriteLn("waa");

^ no "waa" in any games yet though :p

ramapcsx2

"Trouble is, I'm not sure what games make heavy use of Sif0..."

They all do, it's running constantly for like everything :p

arcum42

Makes things easy then. :)

Though I should say "how many games are relying on us checking bit 30 of the tag in sif0dma". It could be most games just set the irq tag to stop dma in sif0...

ramapcsx2

Yeah, from some testing it seems you're right and games just set the IRQ flag.

Ah yeah, and I've found the revision that adds the high level emulation part.

Could be a good reference :)

https://code.google.com/p/pcsx2/source/detail?r=338

arcum42

So far, it does seem like you could practically just use:

if (Tag::IRQ(sif0.sifData.data))

Suspect it would break something, somewhere, though.

arcum42

Tested a good dozen games or so with no issues, and no signs of anything other then the interrupt being needed.

I'm off to bed...

ramapcsx2

Ok, this testing session brought something up that I find a bit odd.

The docs talk lots about the stall control feature of the DMAC, but when logging for that, the flag is never set..

(I was checking for any "dmacRegs->ctrl.STS" occurance.)

ramapcsx2

Ok, I'll continue here :p

arcum42

Don't have any time to really work on it right now, but just did some quick checks, and I see what you mean. STD is also involved with flow control; wonder if that's being set?

arcum42

Hmmm... just noticed this line:

if (tag[0] & 0x40000000) sif0.end = 1;

Which is "if bit 30 of tag is set, set sif0.end."

I'm assuming that tag[0] ends up in sif0.sifdata.data, so this would make:

if (sif0.end || Tag::IRQ(sif0.sifData.data))

be about the same as the current version. And the fact that if doesn't test for normal mode corresponds to the comment two lines above this code. ("Note... add normal version here")

(And I'm actually getting ready for work. I just give myself enough time to do things like reviewing source code when getting ready. ^_^ )

arcum42

One further thing. Had a chance to doublecheck, and bits 28-30 of a dma tag are the id of the tag. (Knew that at one point, just forgot about it last night, and was having trouble getting into my reference material.)

So testing for bit 30 is saying "if the tag is either refe, call, ret, or end", only sif only uses refe and end. It's basically a rather ugly way of testing for the transfer to end, since both of those tags do end the transfer.

By rights, it should probably have a case statement like the one in Sif1Dma...

ramapcsx2

Well, I did a slew of tests surrounding this code.

Couldn't get any games to behave better than usual, which is a worse result than what I get with voodoo cycles for interrupts :p

So yeah, I guess the code is working (Just looks like it wouldn't. really. :p )

arcum42

Yeah, the code's working either way. It'd probably be easier to read if we go ahead and substitute either my first or last variation, though.

Eventually, I think that whole function probably needs rewriting...

Revision 1999

SPU2-X: Minor bugfix to suspend/shutdown code which caused SPU2-X to hang in

very rare occasions.