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

From PCSX2 Wiki
Revision as of 16:04, 8 August 2015 by Gabest11 (talk | contribs) (Created page with "'''Revision 1''' : <nowiki>Moved from CVS</nowiki> '''Revision 7''' : <nowiki>0.9.1 Release!</nowiki> : <nowiki>Includes new ee/vu/iop recopmilers.</nowiki> : <nowiki></now...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Revision 1

Moved from CVS

Revision 7

0.9.1 Release!
Includes new ee/vu/iop recopmilers.

Revision 8

Fixed a small bug that executed sse2 code on nonsse2 machines.

Revision 9

Bad regression bugs. Fixes taito legends, rez, grandia II.

Revision 12

made a copy

Revision 13

More fixes for SSE only CPUs

Revision 14

More work towards non SSE and non SSE2 support.

Revision 15

nonsse builds broke with last change.

Revision 17

vc2k5 now compiles thanks to [email protected]

Revision 18

small SuperVU rec crash
mmi op for athlon xp CPUs

Revision 20

fixes minor crash in supervu

Revision 22

mtgs not doesn't crash on gs local->host transfers for gsdx. (RetainSoftware)

Revision 27

...to be continued

Revision 41

Moved some declarations from patch.c to patch.h so they can be shared with my
XML patch loader.
Also merged cheat finder WIP into the project.

Revision 42

Updated the changelog (not used to do that yet).

Revision 44

Updated devblog.txt as nvm info was a bit wrong and added serial number info.

Revision 45

Added plugins dir and dev9linuz

Revision 60

Finally fixed the finder...

Revision 63

Alignment fix

Revision 67

Performance Counter registers

Revision 70

EE double branch doesn't crash now.
PHMADH fixed (maxpayne)

Revision 73

Clean up old files

Revision 74

Initial support for for Linux builds.

Revision 78

More linux compat changes

Revision 79

fixed typo

Revision 80

More linux work - recompilers and gui is left.

Revision 83

updated for new files

Revision 84

Blockdumps now the same name as used ISO

Revision 86


Revision 95

Updated patches to support fastmemory and roundmode options.

Revision 96

ee fpu prob (summoner1 legs)

Revision 99

Changed a bit zero's additions to the pnach reader so the can be called from the
xml loader. Added fastmem and roundmode parsing to the xml loader.

Revision 101

unpack/vurec fixes

Revision 104

cop2 bug (truncate rounding)

Revision 105

roundmode default values

Revision 108

bad spu2 call

Revision 110

made a copy

Revision 112

roundmode patch option

Revision 115

Whiplash sse fix

Revision 118

whiplash sse fixes, vif1 stall fix

Revision 119

crc functionality for the gsplugin, vuskipping bug, gui

Revision 120

crc functionality for the gs plugin, vuskipping bug, gui

Revision 121

auto ffx hack for mtgs

Revision 123

auto ffx hack for mtgs

Revision 124

Patches via BIOS

Revision 125

Patches via BIOS

Revision 126

vurec bugs:
mgs2 teleportation, crazy taxi, dropship, sensible soccer (although still a
little buggy)

Revision 127

TLB Cache

Revision 128

TLB Cache

Revision 129

MCD Speedup

Revision 131

More linux compat

Revision 133

Almst all recompiled x86 code is in x86 folder/Linux compat

Revision 135

minor fixes to vc2003 proj file

Revision 136

more linux stuff

Revision 137

Fixed the VIF stall on end problem

Revision 138

Fixed the VIF stall on end problem

Revision 139

midnight club/malice crash fixes

Revision 140

Few Vif Changes, Added MFIFO Vif Stalls (Dark Summit)

Revision 141

Update from main branch

Revision 142

new vif stall fixes from ref

Revision 143

compilation errors

Revision 144

enable vurec in release builds

Revision 146

ffxhack for mtgs problems / vurec regression (vampire night)

Revision 149

frame limiting/ffx crcs/disabling screen saver

Revision 150

ffx crcs/screen saver disabling/frame limiting

Revision 151

Patch Browser crash fix

Revision 152

Patch Browser crash fix

Revision 153

added more ffx crcs and frame limiting stuff

Revision 155

Syphon Filter Filling Write fixes

Revision 157

pcsx2 debugging changes (by ibrown)

Revision 158

delete all of the old pcsx2 codebase

Revision 159

pcsx2 0.9.3 and a lot of other additions

Revision 164

turn recompilers on for default

Revision 165

Fixed compilation problem

Revision 167

zerogs crashing bugs

Revision 168

zerogsogl x86-64 bug

Revision 169

small build changes

Revision 170

vif bug

Revision 173

linux peops spu2 defaults to alsa (by popular demand)

Revision 174

temp linux zerogs crashing

Revision 175

zerogs ogl bug fixes. ffx won't crash anymore and textures will be better.
thanks to BirdFuzz for pointing the errors out.

Revision 176

added the 4096 pad for the mtgs buffer as suggested by BirdFuzz instead of 3
byte transfers (which are slow)

Revision 177

reverted back to 3 byte copy

Revision 179

fixed windows build

Revision 181

readded debugger fixes from ibrown

Revision 182

fixed a small rec bug - ffx ingame should be fine now

Revision 183

fixed a number of gtk crashes in the debugger display and re-enabled the logging
options window

Revision 186

0.9.4 release

Revision 187

0.9.4 release

Revision 188

bilinear filtering bug

Revision 189

linux fixes (thanks to birdfuzz)

Revision 190

StartPerfCounter had trailing reference on release builds

Revision 193

added sse3 enable option

Revision 194

removed padwin from builds

Revision 195

TLB Slowness bug, caused by VU memory check/clearing
Faster now, not sure on the physical impact (probably nothing!)

Revision 196

tlb real fix for the speed issue (thanks to refraction)

Revision 198

minor changes

Revision 199

zerogsogl: glew initialized too early (thanks to BirdFuzz)

Revision 201

reverting back

Revision 203

added better cpu detection support for linux

Revision 204

zerogs fixes

Revision 205

zerogs dx 0.97.1 and a few linux changes from ibrown

Revision 206

forgot to enable sse2

Revision 207

FFX Blue screen fix. as a bonus it gets Gitarooman back to the best state it
was in when the patch worked, without killing katamari! result.

Revision 208

bios renaming prob in config

Revision 209

forgot some fx files for opengl

Revision 210

supervu fixes for katamari (superman returns still broken)

Revision 211

eerec bug (socom)

Revision 212

vurec NaN handling changed (we love katamari fixed)...... might break a lot of

Revision 213

FPU value clamping

Revision 214

Made a new framelimiter code. It seems way more stable than the old one, and it
doesn't seem slower. There's also a change in thep roject file to make the .pdb
files go together with the exes in bin/.

Revision 215

Added an option to customize the framelimiter limit (as requested by bositman).

Revision 216

new frame limiter was sleeping too much

Revision 217

zerogs linux GUI ehancements (from Barius)

Revision 218

cleaned up some iFPU changes

Revision 219

Properly fixed the framelimiter slowdowns. Now the speed drops are almost null,
as they should be.

Revision 220

Changed the frameskip code to a cleaner (but more limited) one. It hasn't been
too much tested and needs improvements I will do later based on feedback.

Revision 221

changed some things which made the release version actually run a lot slower
than the dev build, silly really!

Revision 222

Updated version number for revisions following the release of 0.9.4

Revision 223

Various timing changes to reducing passing about of values.
Counter fixes for the KH eye issue, Shadow Hearts hang, possibly Grandia 3 hang,
maybe others too. (and proper FFX loop fix, instead of my original hack :P)

Revision 224

cleaned up files from previous release, readded spu2 interrupt handling, and
added counter changes to ipswhw.c, also added a vunan handling patch option
(enabled by default)

Revision 225

forget some reverts

Revision 226

reverted a revert

Revision 227

turn off vunan handling for default

Revision 228

Rectify bug i made

Revision 229

Fixed USB Timing, shouldnt miss keys now

Revision 230

slight change to how the EE counters reset the counter on target, seems to help
videos a bit (Guitar Hero video no longer freezes)

Revision 231

whoops forgot somet

Revision 232

uff, ill remember everything one day. Forgot the USB timing trigger

Revision 233

More fixes, rethought my KH fix, was barking up the wrong tree, it was cdvd
timing. Fixed some other overflow issues and checked some things on my PS2.

Revision 234

fixed some crashing with the Network Access Disc

Revision 235

fixed mistake in interrupt changes

Revision 236

more misc counter fixes for various video issues etc.

Revision 237

reverted back to fpu regcaching, added a nan handling patch to FPU (combined
with vunanhandling)

Revision 238

Changed FPU clamping so katamari still works but so does tekken 5, gitarooman
etc. Also removed the disabling counters on 0 target as tekken 5 seemed to not
like it.

Revision 239

Fixed ffx, was me being a plum, 0x10 is the IOP target interrupt flag, 0x100 is
for the EE Counters!

Revision 240

couple of mods to the timing changes (not 100% sure on the effect, what ive
observed its for the better), implemented a more logical method of cdvd timing
which wont make x24 cd reading 6 times faster than a dvd at x4 :p

Revision 241

Extended the DMA logging a bit on IOP, re-enabled the EE dma logging

Revision 242

zeropad 0.2 - linux joystick support

Revision 243


Revision 244

failed pad ff

Revision 245

zeropad minor bugs

Revision 246

small but with zeropad

Revision 247

forgot something

Revision 248

zeropad x86-64 compilation bug

Revision 249

bug with zspu2 that would cause it to freeze on close

Revision 250

Updated psx counter logging in register dump so it can read the 64bit values and
has some description

Revision 251

Removed most of the warnings when compiling. Going through the warnings I
noticed two buts with counter code, and a but in the "Lock pages" privilege
setting code.

Revision 252

Fix for We love Katamari bad textures

Revision 253

unbroke the linux build and reverted other stuff that shouldn't have been
touched in rev251

Revision 254

joysticks should be opend as readonly

Revision 255

zeropad uses SDL now

Revision 258

fixed broken saved states for old versions, zeropad was broken under windows,
updated some files...

Revision 259

bad SDL include?

Revision 260

Unscrewed again what zero screwed up, evidently he cant read english comments.
Spanish next time? maybe some italian? how about a touch if hebrew.

Revision 261

initial fps2bios, this includes some mods from Ian Brown. the bios does even
boot the pcsx2 at the moment

Revision 262

forgot to delete something...

Revision 263

bad makefile

Revision 264

new loadcore

Revision 265

Added an optional function to the spu2 plugin interface so I can read the IOP
cycles var from spu2.
I use it to improve the sync between the emu and the spu2 by calculating the
elapsed time also on register accesses.
The function is optional so older plugins still work fine, and only called once
every "open" so it doesn't make anything slower.

Revision 266

fps2bios: better loading of modules

Revision 267

fps2bios: fixed several bugs in loadcore module

Revision 268

Added a check to the "superVU" recompiler to stop Dirge of Cerberus from
crashing: a function was trying to use an uninitialized pointer.
This check could be avoided by properly initializing the values but I don't know
where would that be.

Revision 269

better fix for FF7: DoC, the start PC was outside VU memory range, now wrapping
it around the memory size.

Revision 270

fps2bios: restructured the ee kernel... doesn't compile yet\n

Revision 271

fps2bios: forgot some files

Revision 272

fps2bios: more work on the EE kernel

Revision 273

fps2bios: forgot a file

Revision 274

fixed some weird ffx bug, reverted VUSkip back to the original working version

Revision 275

Couple of counter gate fixes to stop normal updates of them. Fixed a vif stall
issue, jiggled some mfifo stuff about to improve how it works slightly and
reduce the amount of silly condition checks needed

Revision 276

General MFIFO tidy up, removed pointless code (that should never be
reached/used) fixed a couple of bugs while i was in there. One caused a garbled
block in the top left of psychonauts videos.

Revision 277

Reverted SPR change for MFIFO timing, Tekken 4 hated it :(

Revision 278

Little tidbits (unimportant) and a fix for vif mark stalls on tags (neopets)

Revision 279

idiotic mistake by myself causing tenchu to loop

Revision 280

Small fix for GT4 crashes (only works with zerogs)
Small change to reduce timer checks (prolly does nothing)
put the reg freezing where its actually needed, instead of guessing.
(centralizes it a bit)

Revision 281

whoops forgot to revert something during my testing.
btw last commit had some pad calls removeed too as they were obsolete, 1 being
left in as it was calls for escape, gs shortcuts etc

Revision 282

yes, i am mentally dwarfed

Revision 283

dont do drugs kids. oh and i forgot some for vu0, corrected stuff i did in
normal calls when it shoulda been rec code.

Revision 284

okay thats me done now

Revision 285

Created VS2008 project files from all the 32bit project files included in the
default pcsx2 solution.
Also included a small optimization change to avoid meaningless calls to
WaitForSingleObject. As far as I can see it's completely thread-safe (one end
only writes and the other end only reads), but I'm not completely sure if it
will give any reasonable speed improvement. Anyway it's there.

Revision 286

unbroke some stuff and add a forced check for regs

Revision 287

Moved a couple of things around, fixed a couple of bugs i made, removed some
unneeded/duplicate checks

Revision 288

other additions (had to do an svn update, was outdated :( )

Revision 289

it is NOT obsolete

Revision 290

slight reorder on zero's request

Revision 291

revised some of my changes a bit (after some profiling) performance seems to
vary game for game, the killer is cos we are using memcpy_fast, freezing them
MMX registers so often murders it on some games.

Revision 292

fixed linux compilation problems

Revision 293

I know this wasn't really a "bug" as it wasn't executing anything at all, but
now that I saw it, I don't see why should I leave it as it was...

Revision 294

fixed a couple of crusty rec bugs thanks to Rama1

Revision 295

giga missed one xD fixed a potential crash or two myself

Revision 296

fixed a couple of freeze issues i had still

Revision 297

fix for GH USA, was crashing. Moved sif freezing to where its needed on SIF1,
its not required when called for the IOP (which SIF1 does most)

Revision 298

removed the forced "default" inline use, now using any suitable, provides a tiny
boost in speed.

Revision 299

DMC1 fix, didnt work before on some games, now it does, wierd!

Revision 300

Mojo Ribbon fix

Revision 301

Silly bug which broke tokyo road race

Revision 302

fix for the other versions of DMC1 :p

Revision 303

fixed a small silly bug

Revision 304

changed the pad thing back in winmain. anal people (aka emwearz) decided hed
have a problem when using lilypad

Revision 305

couple of changes to make doubly sure counters start right etc and alert me
(sorry if it floods on some games), accurate cycle counting to next interrupt

Revision 306

A few speedup hacks now selectable via Config->Speed Up Hacks (original eh :P)
Thanks to Rama1 for those.

Revision 307

missed part of the hack, rama's fault ^_^

Revision 308

some test counter changes with some debug notes

Revision 309

Added the fantastic new patch browser and memorycard browser as written by
ihateregisterin. Good job man. Oh and disabled one of my debug messages, seems
it really slows the bios xD

Revision 310

jiggled some stuff about and took out some dupe code in vif unpacks, saves
approx 25,000 cycles per frame in 3d. also along the lines ffxii videos got
smoother too so, good day for reffy! fixed a couple of little bugs too.

Revision 311

Fixed a small bug i made when data was left over. didnt increment dest

Revision 312

Fixed a couple of other bugs and an old bug where the destination wasnt being
incremented properly on split transfers.

Revision 313

small fix (dark summit)

Revision 315

Couple more unpack fixes. Sensible Soccer looks perfect when interpreting V3-8,
but SSE is broken. Looks less spikey than it did now anyway!

Revision 316

Fix for Shox + Whiplash regressions

Revision 317

Fixes sector reading problems on when using cd reads (growlanser games + simple
series games)

Revision 318

small detail missed, not sure how important it is, but id guess it helps towards
the sync/jumping of sound

Revision 319

changed version number to accomodate the change, which is reported to help some
skipping voices/sounds

Revision 320

Improved SPU2 timing sync a bit without hindering speed (like before) makes the
FFXII videos stutter less again, DMC (U and J) not loading seems related, but
that seems ok in this rev

Revision 321

was a bit too generous with the cycles, WA5 didnt like it.

Revision 322

Worked out my timing issue. needs new zerospu2 with dma timing changes (next

Revision 323

Some means of DMA timing in there now, some games were triggering too fast now
async gives cycles more often.

Revision 324

im committing this fix, needs to be done, but wild arms 5 is strange, different
pc's show different results

Revision 325

Rewrote my Hsync/Vsync code, improves sync on streamed videos and realtime
FMV's, also reduces graphical anomolies (flickering on Wild Arms 5).
Tweaked my SPU2 async changes, Also added an option to the speed hacks for
tighter timing, which stops the jumping/freezing in FFXII videos.

Revision 326

fix for memcard saving since new interface, never remembered the new selections.

Revision 327

i cleaned a comment out like a spaz, and it broke vsync completely xD

Revision 328

sorry bosit :( ill remove them counter printouts :(

Revision 329

some more counter changes, mojib ribbon seems to like them (at least here)
should help those picky games which constantly reset the hsync counter (dmc/wild
arms 5)

Revision 330

Fixed a PREVH, had the wrong shuffle codes. (king kong corrupt text)
Disabled QFSRV, most videos are 10-30% faster interpreted! itll do till it gets
fixed properly.

Revision 331

Improved DMA timing, should help with wild arms 5, DMC, Mojib Ribbon etc, the
picky ones, you know :p

Revision 332

removed a statement which did nothing but made the sound more choppy at high
speeds, thanks to rama and his hacking for finding that :p

Revision 333

Fixed a bug causing games that use Counter Gates to lock up/not load.
(Beatmania, possibly DDR games too)
Adjusted some more spu2 related stuff, removed some old code which shouldnt have
been there!
experimental changes to GS interrupt stuff, shouldnt break anything.
got rid of some pointless code on vif1 unpacks.
came across a wierd situation with TTE on DMA's, trying soemthing, seems stable
on my games:p

Revision 334

stopped it logging sound constantly when you have logging on in debug. Was
driving me bonkers! :P

Revision 335

just a small bug, probably not used very often.

Revision 336

stopped public release builds from forcing the recompilers regardless of

Revision 337

"fixed" the vs2008 project file based on rama's suggestions (I don't knwo if
they trul fix the problems but whatever...).

Revision 338

changed how a few IOP counter things work, reverted one of my VIF changes and
fixed another possible Unpack situation i hadnt accounted for.
Oh and the best news, SIF timing now exists, you know what that means? yes,
Okami no longer needs a patch

Revision 339

Fixed SIF bugs introduced in Persona, also reverted the VIF change that caused
problems with the graphics.
Fixed savestate loading in MTGS thanks to Rama1.
Tweaked the MCD manager so it doesnt infinate loop in places, also no longer
auto populates the list if the memcard is corrupt, which caused it to crash.

Revision 340

DMC didnt like the persona changes, so did a rethink ;p

Revision 341

Quick! Look behind you! a 3 headed monkey!

Revision 342

small error in unpacks, not sure how major it was.

Revision 343

reverted something i missed when reverting some path3 mask changes, so the
people using speed hacks leave me alone to chase REAL bugs.

Revision 344

cleaned up some of the defines in common.h for v/hsync. uncommented some code
which shouldnt have been commented for vsyncs, was causing supersonic speeds on
boot and probably throwing all that hard work out :p

Revision 345

small adjustment to h/vsync things. fpu clamping fix for NFS Carbon which was
crashing, managed to do it without breaking katamari, bet smth broke tho lol

Revision 346

Path 3 transfers now only use interleave mode if Path 3 Masking is used. This
stops Tekken Tag from randomly crashing (hopefully)

Revision 347

slight change to the interrupt status on cdvd

Revision 348

Ignore this commit. It was just a test.

Revision 349

IPU fixes. Corrected bitstream data positioning and removed redundant code.

Revision 350

fix for zerospu2 savestates

Revision 351

FFX video fix, reminents of stuff which shouldnt be there ;p

Revision 352

added some code for easy profiling of changes on the EE. can be enabled by
uncommenting the #define EEPROFILING in r5900.h

Revision 353

removed MMX freezing on IPU as its no longer used

Revision 354

SIF now uses normal memcpy's as it seems to take up less cpu time.

Revision 355

Very small misc changes,mainly in plugin about boxes and 2 pcsx2 console

Revision 356

fixed slight overlap on "Greetings to" text

Revision 357

Fixed the broken fixes,sorry :P

Revision 358

Cleanup in docs: Removed old and unused docs while adding the new ones
Reduced compiling errors: Used #pragma warning(disable:4996) to ignore the
stricmp deprecated warning
A couple of small fixes in Memcard viewer
(thx gigaherz and refraction)

Revision 359

Deleted old txts

Revision 360

Applied a patch from Pontifice with an improvement on the patch engine which
adds supprot for using codebreaker "raw" codes directly in the pnach.
[23:43] <Pontifice> its backward compatible, to use new codes you must use
something like patch=1,EE,400A0000,extended,00DE0002
[23:44] <Pontifice> where 400A0000 00DE002 would be the original RAW codebreaker

Revision 361

He forgot to change a few var types before diff'ing.

Revision 362

Improved vu skipping and frame skipping. frame skip changes by myself to make it
less jerky (more useable), vuskip changes by rama to cut down black screen
problems. Frame skip still needs some tweaking, will work on it later.

Revision 363

More codebreaker code support from pontifice. He said the few code types
remaining don't make sense in pcsx2.

Revision 364

Re-enabled "Denormals are Zero" for the recs. Seems to cause huge speed boosts.
for example Persona 3 went from 50fps on my rig to 103fps. reported the suikoden
games are now quicker. Also enthusia doesnt have invisible wall problems. Could
help with many misc FPU problems.

Revision 365

disabled denormals are zero on the VU's for now (thats the one that speeds it up
:( ) will probably add it as a hack option, tho it shouldnt be, the ps2 takes
denormals as zero :/

Revision 366

Reverted something which caused sound glitches, still not 100% sure its how it
should be, will look in to it.

Revision 367

GUI changes by bositman

Revision 368

Fixed some problems with MAC/Status Flag settings on VU. Fix list
Sega Tennis - SPS
Dark Cloud 2 - SPS
Crazy Taxi - SPS
Metal Gear Solid 3 - Falling Through Floor/Stuck In Trees
Tekken Tag - Stretchy Crowd
Possibly more, testing as much as we can :p

Revision 369

Just a few changes to make RSQRT more accurate (Tales of Legendia), avoided some
bugz in DIV/SQRT/RSQRT, n made others :p

Revision 370

fixed some of the bugs i made, some changes by gabest in here too :)

Revision 371

Fixed dark cloud 2 missing text, some vurec changes by Gabest. Reverted one
change from using the normal memcpy all the time as it uses SSE, we dont account
for this.

Revision 372

Fix for GT4 darkness

Revision 373

Normal RSQRT fixed by gabest, the mans on fire :p

Revision 374

Fix for God of War 1 & 2, its not perfect, some FPU errors still, but a massive
improvement. Fixed the overbright bug in some games (hopefully), removed the
annoying messages that flood the console. Note: green screen on GoW is a GSDX
problem, use software mode or ZeroGS

Revision 375

couple of WIP FPU changes.

Revision 376

Fix for Donald Duck crash, some changes by gabest adding more SSE4 functionality

Revision 377

Fixed remaining Woody Woodpecker crashes. Oh and the MGS3 crash ;)

Revision 378

Massive update of the GPL license headers. I don't know if I missed something,
but I hope not.

Revision 379

Sorry I had DAZ enabled in my local copy and it slipped in.

Revision 380

updated some more licenses.

Revision 381

Added some source-level configurability to the paths... hope didn't break
anything ;)

Revision 382

allow also changing "inis" path.

Revision 383

tiny bug

Revision 384

fixed a typo which could have potentially slowed down the emu. Thanks goes to
cottonvibes for that one!

Revision 385

Different version of pcsx2 with recompiler only. Supported compilers include VS
2008 and up. WIP

Revision 390

commenting out unneeded rpsxBASIC

Revision 392

got rid of abs error

Revision 393

changed qword to xmmword to fix gcc errors on newer distros

Revision 394

compilation problem

Revision 396

more asm fixes

Revision 398

Using standard SVN folder structure

Revision 400

Moving old pcsx2 src to tags

Revision 401

Moving pcsx2v2 to branches

Revision 402

updated GSSoft code to compile to help developing fpsbios under a virtualbox vm.
Does not work properly yet, but it compiles under xubuntu 8.10. Only useful for

Revision 403

change to allow compilation on latest linux. Only tested on xubuntu 8.10, 32 bit
so far.

Revision 405

added gsdx, xpad, cdvdolio

Revision 413

that didnt go right :P

Revision 426

Should be the last of the trunk, gotta finish the branches/tags, but thats the
main bulk transferred.

Revision 427

drk||Razi's bm test, apparently an old version, storing here for archiving sake

Revision 431

Removed "Pg" from filenames and project names. Removed "Vtlb" from build target
names and pcsx2.exe (so the new pcsx2.exe is the same as the old pcsx2pg-

Revision 432

Work on getting everything compiling properly in Linux.

Revision 433

Updated logo to remove the "Playground" stamp :) Welcome aboard guys!

Revision 434

Fixed release mode target for pcsx2_2008.sln (it was defaulting to debug after I
renamed the project targets)

Revision 435

Remove anything saying Playground from the Linux version. Minor change to the
Linux cpu code.

Revision 436

Pointed pthreads Intermediate folder to a location other than Pcsx2's. This
resolves some linker warnings and other build issues.

Revision 437

ZeroSPU2: Fix the mixer issue properly, and get rid of the temporary code I'd
added back in.

Revision 438

Tweaked the Game Fixes GUI slightly so it was less ugly, buttons were hanging
off the edge etc.

Revision 439

- renamed pcsx2pg.ini to pcsx2.ini
- made pcsx2 to default to MTGS mode "on" instead of "off"
- renamed "Mega VU" recs to "Micro VU" recs since the team thought "Mega"
sounded lame ;p

Revision 440

minor update - i forgot to rename a few things

Revision 441

Reformat CDVDiso's code, and get it to use a real ini file instead of writing
inside one of the plugins binaries. Prep work for hunting down some bugs and
modernizing it that I've been procrastinating about doing.

Revision 442

CDVDiso: Add break statements.

Revision 443

Linux: Reorganized the files to a somewhat familiar file structure. Adjusted
some Linux code to be closer to the Windows version.

Revision 444

Fixes some various compilation problems (people without TortoiseSvn installed
won't get errors anymore)

Revision 446

Linux: Some cleanup on the Linux headers as followup to r443.

Revision 447

Modified the build system so that both the original and new "revisioned" copies
of EXE/DLL files are copied into the target build folder. Example: When
compiling Release, pcsx2.exe will always reflect the most recent successful
Fixed COP0's recompiled branch instructions (BC0F, BC0T, etc) -- the conditional
was not implemented correctly (thanks to Refraction for spotting that one).
Used a better method of clearing the errorlevel during the Pre/Post Build steps.
Should be a little less error-prone (pun?)

Revision 448

Linux: Save slots are now disabled in the menu unless a) a game is running, and
b) it was saved with the same game as you are running. So you should now be able
to tell at a glance which slots you've used. Experimental...

Revision 449

CDVDiso: Add the ability to create block dumps to the Linux port.

Revision 450

Hmmm... I remember adding this to svn. Oh well, it's in now.

Revision 451

Yay! Fixed a memory corruption bug in the SuperVU that caused several "VU-
intense" games to crash randomly: Tekken 5, Persona 4, and God of War to name a
Changed the Hw FiFo to use what should be a more correct register addressing
scheme. The entire contents of each page of the FIFO is mirrored into the
lowest register(s). For example, any address between 0x10006010 and 0x10006ff0
should always be treated as address 0x10006000.
Code cleanups and minor optimizations to hw.cpp, FiFo.cpp, and gs.cpp.
Added some additional utility functions to the Path namespace, for splitting
paths into files/folders parts.

Revision 452

- fixed a warning from last revision
- made "framelimit" mode default, instead of "normal" mode (was discussed by
- some more microVU rec work...

Revision 453

Fixed a foopah in r451 that caused most games to run at PAL framerates and
timings. Oops, heh.
Squashed another race condition in the MTGS; this one when hitting escape to
close the GS window (very rare).

Revision 454

Fixes for Fatal Frame VIF errors and FF7 DoC grey screens. Experimental VIF
timings included

Revision 455

Small bug in the new VIF timing i forgot to fix :P

Revision 456

Added NTFS compression to the memcards folder and any memory cards used from
pcsx2. Most memory cards compress exceptionally well (from 16M to 3M
Also in this commit: Some minor code cleanups to sio.cpp, and added some missing
setup code to the Iop Counters savestate loader; psxhblankgate and psxvblankgate
weren't being re-initialized.

Revision 457

Helps if I add all the files.. >_<

Revision 458

Removed various references to "Playground" in plugins and dialogs.

Revision 459

Added preliminary hotswapping and "Memorycard Not Present" support to the SIO.
Among other things, this fixes memcard problems when using savestates, where-by
some games would fail to recognize that the memory card had changed. So those
of you with savestates for games that refuse to save to a newly-formatted
memcard, this *should* allow you to save now. :)
Added several new files to organize some large files: HwRead.cpp, HwWrite.cpp,
MemoryCard.cpp, MemoryCard.h.

Revision 460

Changed the Magna Carta gamefix to something more plausible.
Thanks to tmkk for spotting this :)

Revision 461

A new VU MIN / MAX code by Nneeve allows more games to use DaZ on the VUs.
We'll test if any game still needs DaZ off, and if not so, make that default to
DaZ is a more correct behavior for the VU's, and only bugs prevented it from
working as expected.
Thanks to Nneeve for his hard work :)

Revision 462

Removed my VIF tests, put some other means of protection in place that seems to
work. Should fix Issue 22 which was introduced in r454. Also fixed a vif mfifo
bug which has been there god knows how long..

Revision 463

Re-Added eol-style:native properties to the repository. The settings got lost
when we merged from Playground to Official.
Added interface.cpp (plugin/pcsx2 interface) and savestate.cpp to SPU2ghz, to
help clean up SPU2.cpp.

Revision 464

Removed VSync INTC timing hack, could possibly sort others too

Revision 465

SPU2ghz: Bugfixed the update of the ENDX flag; fixes Summer Heat Beach
Volleyball. Added afxresmw.h to the SPU2ghz project, so that VS Express folks
can (hopefully) compile it now, relatively hassle free.
Reverted the Pg icon back to the Official Pcsx2 "2" icon.

Revision 466

some microVU work

Revision 467

Bugfixed the Elfloader; resolves a bootup crash in Psychonauts.
Renamed MemoryAlloc to SafeArray, and added linux files to the Win32 solutions
(they're disabled, so they don't compile or anything -- I just needed them in
the solution so that I can more easily update Linux code when I make API changes
to the GUI)

Revision 468

Let's see: Fix Linux build so it compiles, both under normal and devbuilds. Add
the ZeroGS patch for SSE2, and preliminary work on the configuration issue. Get
build.sh postix compliant. And let's not feed C++ strings to WriteLn.

Revision 469

GSdx software renderer speed-up, using xbyak to JIT compile a few things, more
to follow.

Revision 470

SPU2ghz: Significant overhaul of the volume system! Volumes for most games
should be much more accurate now, and distortion greatly reduced. This is still
a work-in-progress, and I intend to follow up with another commit soon that
should improve performance in a few areas, improve overall audio quality and
(hopefully!) fix up the Special Effects system as well.
Pcsx2: This time the Pg icon really has been replaced/reverted to the original
(dunno why my last attempt didn't commit, oh well). Also improved the syntax of
the SourceLogs; fixing if/else statement scoping problems.

Revision 471

SPU2ghz: Reverted an experimental ASDR slider that broke way more than
expected.. >_<

Revision 472

LilyPad 0.9.9, more or less

Revision 473

SPU2ghz: Corrected another ADSR bug that muted audio in Shadow of the Colossus;
implemented some minor speedups.

Revision 474

Various minor cleanup. Get rid of those annoying extra newlines in Linux.

Revision 475

LilyPad: Hack to put save state number in window title, can set sensitivity of
multiple bindings at once, fixed issues with displaying disconnected devices,
some random code cleanup.

Revision 476

Minor changes to GSdx and fixed the SSE2 compiling error.

Revision 477

Fixed Fatal Frame once and for all due to a DMA issue which it shouldnt have
been doing ;p Also fixed the COP0 condition for the Recompiler and Interpreter,
this was stopping Mojib Ribbon and Shadow of Colossus (after the Fatal Frame
fix) from running. Int some how worked but it was wrong lol :P
Also fixed some Copy n Pasta typos

Revision 478

minor microVU rec changes
note to pcsx2 users: for those that still don't know, these are new VU
recompilers i'm working on. They're not working yet, and won't be for at least a
few months. So don't expect noticeable changes when i update microVU stuff,
since currently they're not being used (when they're in a semi-working/usable
state, i'll be sure to put a note in the revision message ;p)

Revision 479

ZeroGS: Change the OpenGL conf screen to have radio buttons for No interlacing,
Interlace 0, and Interlace 1, and save all 3 values properly. ( Issue 26 )

Revision 480

Small hack (possibly) so the Katamari games boot from "Run CD/DVD" Fixed SRS so
it doesn't hang on loading ingame 3D (please report any broken games), also
moved one of the hwRead case statements for SPR logging.

Revision 481

Disabled a default EE Rec option, which shouldnt have been on in the first
place, fixes Enthusia freeze up (maybe others that froze in 3d)

Revision 482

More cleanup on Patch.cpp.

Revision 483

No wonder snapshots didn't work, the directory is not there. Renamed "snap" to
"snaps" for GSmakeSnapshot.

Revision 484

GSdx: more JIT code and a little clean-up

Revision 485

Linux/Plugins: Use spu2ghz's noise rng in ZeroSPU2, clean various plugins before
compiling them, put in better default values for the Linux port when
configuring, and go into pcsx2 after configuring for the first time, rather then
quitting. Oh, and disable the debugger for the moment in Linux.

Revision 486

Linux: A bit of work on memcard support in Linux. Disabled for the moment
because it seemed like the emulator wasn't seeing memcards being swapped till
after restarting pcsx2, and I was worried about memcard corruption. I also made
it put in default values for memcards if you didn't have them in preferences

Revision 487

Initial Revision!

Revision 488

Edited wiki page through web user interface.

Revision 489

Implemented a hackfix for FFX (I hate this game lol) also fixed a bug in VIF i
think i introduced during some tests.

Revision 490

Slight modification to the MFIFO's to prevent potential situations which could
cause bad data to be copied.

Revision 491

Linux: Moved the new memcard work to separate files, and enabled it, as it seems
to be about as safe as switching memcards in the Windows port. Cleaned up
Linux.h a bit, and started a bit of work on the debugger.

Revision 492

ZeroGS: fix up the dev build so it works, fix a typo in configure.ac that could
cause compilation issues, and bring in a fix of zedr0n's for newer Cg versions
when in dev mode.

Revision 493

Fixed an issue which caused savestates (or escaping) to freeze up the emu if
MFIFO was in use

Revision 494

Whoops, overdid that a bit (thanks for pointing it out Bositman :P)

Revision 495

ZeroGS: Commit Zeydlitz's bug fix from Issue 11 , which seems to resolve most
problems with double images when antialiasing is on in the OpenGL version of

Revision 496

xpad: compatible with pcsx
GSdx: minor optimizations, +crcs

Revision 497

SPU2-X: Introducing the new SPU2-X! After some talk with Gigaherz, It was
decided to branch and rename Playground's mod of SPU2ghz to SPU2-X. This commit
isn't just a copy. It includes a series of significant revisions. The most
notable features are:
* Working Reverb. Yes, you heard right. Fully and completely implemented
reverb effects!
* Automatic 5.1 speaker expansion.
* Some more bugfixes to volumes.
* All new configuration panels.
* Improved/Bugfixed XAudio2 drivers.

Revision 498

coded the microVU opcode tables, this took me all-day to get right lol xD

Revision 499

SPU2-X: Cixed a tyop-ish error in the code that caused reverb static and
Fixed savestates so that they don't return an error anymore.
Fixed some bugs in the config box. Some checkboxes weren't being saved and

Revision 500

Pcsx2 now correctly sends CRC info to the GS plugin when using Run->Execute to
boot games through the BIOS. And, Omg! The X button in the about box was
broken! Thank goodness I fixed it before someone got hurt! ;)

Revision 501

SPU2-X: Couple more quick fixes to the config dialog box.

Revision 502

Updated the Copyright to reflect the passing of another year. :)
Updated the pcsx2_suite_2008.sln; changed SPU2ghz to SPU2-X.

Revision 503

Added GSdx to the pcsx2_suite_2008.sln. It defaults to SSE2, you'll have to
manually configure the build targets to use SSSE3 or SSE4 (hopefully we'll find
a better solution to that in the near future).
Upgraded GSdx's use of svnrev to match other plugins in the pcsx2 repository; so
that it no longer requires TortoiseSVN, and will also compile correctly from
folders with spaces (ala '/program files/username/my documents/projects').
Removed the /3rdparty and /common folders since they aren't used anymore, and it
was potentially confusing or misleading to leave them in since they were out-of-
date (they were once referenced by svn:externals, and we opted out of using
those here due to slowness).
SPU2-X: Fixed a minor overflow in the reverb that would cause infrequent
crackles in a select few games.

Revision 504

GSdx: Added a GSdx_vs2008.sln file in /plugins (convenience item), and fixed the
prebuild command to drop svnrev.h into the right location (oops).

Revision 505

Removing linux-specific svn property. Will replace it with a hard copy in the
next commit.

Revision 506

ZeroGS/OpenGL: Moved zlib to 3rdparty folder.

Revision 507

xpad: fixed dependency on obsolete /common folder. :)

Revision 508

xpad: gah, forgot to add in the build scripts. >_<

Revision 509

SPU2-X: Added a lowpass filter to the reverb output, which should produce more
correct audio (still experimental). Plus many code cleanups.

Revision 510

SPU2-X: Forgot a file (again).

Revision 511

SPU2-X: Fixed a screwup from the previous commit. A bit of code cleanup got
lost in translation. ;)

Revision 512

SPU2-X: Switched over to what appears to be a much better ADSR table (we'll be
testing it to see what impact it has across all games).

Revision 513

SPU2-X: Better ADSR fix this time, by fixing some bad math on my part during the
ADSR Decay stage.

Revision 514

Fixed a bug that caused MTGS to throw "pure virtual function called" errors on
rare occasions, and cause crashes in Linux. ( Issue 31 )
Improved the Win32 build scripts to solve some end case scenarios on some
systems/configs, where they would fail due to missing path separators.

Revision 515

Fixed a pair of bugs with flipped controls and sensitivity > 1. "Ignore
keyboard" removed from device list. Removed some unnecessary mouse capture code
for mouse raw input. Renamed some options to be more user friendly.

Revision 516

Left axis bug with last commit fixed.

Revision 517

Missed an important bit of last night's build script update. >_<

Revision 518

SPU2-X: Savestates work now. :)

Revision 519

- Disabled all broken memory card manager options
- Set DaZ to on for the VUs as default

Revision 520

VC 2008 release build no longer depends on ntdll.lib. VC 2005 still uses it to
shrink dll size, as it comes with VC 2005 Pro. "GS Thread updates" disabled and
grayed out for PSX emulators.

Revision 521

Disabled a superVU optimization that slowed down VU intense games lots.
Big speedup for Persona4 and Tekken5 :)

Revision 522

Lots of work from tmkk. This update adds recompiling for several MMI opcodes,
fixes bugs and adds SSSE3 detection.
Thanks again, tmkk! :)

Revision 523

A few minor changes to the Linux port, and a minor ZeroGS bugfix.

Revision 524

Re-enabled the superVU optimization (It had problems with FFX on non SSE4 cpus,
likely a bug in AssignVFRegs).
To make up for the speed loss in Tekken5 and Persona4 the vu cache size is now
This means another 10% more speed for Tekken, and a whooping 30% for Persona :)

Revision 525

SPU-X: Major code cleanups across the board, and optimizations to the reverb
effects generator (possibly buggy yet)

Revision 526

A few fixes for MMI stuff by tmkk, and disabled a logging printf in release

Revision 527

SPU2-X: Some bugfixes to reverb that were introduced in my last commit. Still
some minor problems in this build. I'll fix them soon.

Revision 528

Small change - removed 2 console logs from release builds

Revision 529

SPU2-X: more fixes to reverb. Digital Devil Saga sounds a lot nicer now.
Updated savestate revision so that loading states from before my latest
cleanup/optimization won't crash.

Revision 530

Counters fix from tmkk -- a rarely used gate mode of the EE counters was being
handled incorrectly.
Added FreezeMMXRegs to SPU2async in IopDma, which is callable directly from the
SPU2-X: Fixed another reverb bug, this one put too much reverb on voices and

Revision 531

fpu interpreter bugfix thanks to nneeve.

Revision 532

New Speed Hack! And a good one! This is an idea I had a while back, as
implemented by Pseudonym, and is intended as an eventual replacement for all EE
speed hacks (x2, x3, etc). Expect huge speedups in most games way beyond even
X3, and it shouldn't break FMVs or cause graphical artifacts either like the old
hacks do.
Memorycard Fixups:
* Replaced the old disfunctional memcard manager with a neat and practical one,
with options!
* Improved memcard hotswapping support.
* Added memcard CRC checks to savestates, so that memory cards are only ejected
when needed (should fix Guitar Hero problems from Issue 32 )

Revision 533

Added Nneeve's fix for recMADDU (it was using the IMUL instruction which would
have produced potentially incorrect results in rare cases).
Cleaned up some of the signed/unsigned ambiguity surrounding MULT/MULTU

Revision 534

Moved an MTGS log to help troubleshoot some kind of rare system hard-crash
problem in MTGS, and removed an errant playground reference. :)

Revision 535

GSdx: upgraded the ps1 renderer to use runtime generated code, too.

Revision 536

Tmkk managed to fix a huge hack in the superVU delay slot handling.
This new code properly handles these situations now, removing the need
for the magna carta gamefix, and also fixing problems in dragon quest 8(jp).
Thanks again, tmkk :)

Revision 537

Fixed a small bug in FCOR under the VUrecs, also put a hack in there for ICO to
cure the SPS, this can be selected in the gamefixes dialog.

Revision 538

Added several important variables to the VIFdma savestate, relating to it's SSE
unpacker; which should make the gifdone savestate hack obsolete (it broke
savestates for most FMVs and some games). Seeing how important the unpacker
tables are, it's a miracle VIFdma ever recovered from a savestate without them
Fixed a bug in the memorycard hotswapper. It wasn't reloading the cards
correctly after changes.
Improved the new INTC hack slightly, and changed its description since it's not
quite as universally awesome as Pseudonym and I had hoped when we worked on it
last night. -_-
Added __fastcall and __forceinline to some of the VIF's unpack functions, where
appropriate (very small speedup).
Removed some code I added to the MULT/DIV instructions, since it wasn't needed
afterall, and fixed some typos in vtlb's API.

Revision 539

Seems my last commit change didnt quite do what i expected and broke FFXII.
Reverted it.

Revision 540

Linux/ZeroGS: Bring the memcard and gamefix dialogs up to date. Get rid of some
compilation warnings on ZeroGS, and some misspellings that were bugging me.

Revision 541

Added some more relevant persistent state vars from the GIF to the savestates.
There's still a known bug in the IPU's savestate however, so saving/loading
while FMVs are playing could result in bad states (not sure when the bug
started, and it could be very old, only noticed it today)

Revision 542

New svn branch: Release Candidate for 0.9.6. (designated for bugfix/stability
patches in preparation of a proper release to supersede the ageless 0.9.4 --
major code renovations will continue to be applied to /trunk)

Revision 543

minor change

Revision 544

Plugins: Devbuild and Debug should be separate, and let's use ZEROGS_DEVBUILD
and not RELEASE_TO_PUBLIC in ZeroGS.

Revision 545

Updated version information displayed in the window title for rc_0.9.6.

Revision 546

Fixed two bugs in the savestates. Older savestate versions will work now, as
they should.
Added a queued frame counter to the MTGS to help keep keyboard input in sync
with video output, which is needed now thanks to the INTC speedhack making the
menus of some games run really really fast. ;)
Spiffed up the about box a wee bit.

Revision 547

tweaked FPU compare opcode clamping.
this fixes a bug with Digimon rumble arena 2.
thanks to Nneeve for figuring out the problem.

Revision 548

minor FMAND VU opcode change thanks to nneeve

Revision 549

Merged some stable bugfixes from r543->548 into rc_0.9.6.

Revision 550

GSdx: completed the ps1 renderer conversion for xbyak, GSRasterizer::Draw*
functions should be next.

Revision 551

GSdx: forgot to disable some console output

Revision 552

SPU2-X: Squashed a bug that caused lots of crackle-pops on certain audio tracks
(most obvious during the KH2 intro); LoopStartA apparently should *not* be set
to NextA when KeyOn is issued.

Revision 553

Tri-Ace gamefix works again :p

Revision 554

Rc branch also needed the Tri-Ace gamefix fix :p

Revision 555

SPU2-X: Another bug stomped which caused sounds on Voice 15 to be silent
(introduced around r511). Affected synth music in most games that have synth
music (Xenosagas, Final Fantasies, etc).

Revision 556

SPU2-X: These aren't the buildfiles you're looking for. Move along now.

Revision 557

SPU2-X: Added ConvertUTF.cpp (handy!), Changed instances of _T("") to the much
less ugly L"", and removed references to _wfopen.

Revision 558

Tagged the SPU2-X 1.0 Release.

Revision 559

CDVDisoEFP: I'm not sure what happened in the mists of time to this folder that
caused all the source code in it to have the lines all become double-spaced and
unreadable... Got rid of all the extra blank lines, and reformated.

Revision 560

Minor cleanups to the order in which plugin init/open/close functions are called
(PADs are always closed before the GS now, for example, since they usually rely
on the GS's window handle).

Revision 561

Linux: A little more consistancy about using the System.h wrappers, restore the
bin symlink, and a few other minor changes to plugins.

Revision 562

Added some diagnostic and recovery checks to the MTGS queued frame counter, as
per problems expressed in Issue 49 .

Revision 563

FPU fixes:
tweaked the fpu compare clamping so now gt4 works again.
made the digimon rumble arena 2 fix into a gamefix.
tekken 5 doesn't need a gamefix anymore.
VU fixes:
fixed 2 opcodes thanks to nneeve.
optimized FCOR a bit.
changed the way ICO gamefix works so its less hacky (just always sets VI to 1
instead of setting VI to the opposite of the 'correct' result)
General fix:
there was some odd bug with the autogenerated TEXTINCLUDE stuff.
if you edited a resource, it would generate
#include "afxresmw.h
instead of
#include "afxresmw.h"
(a quotation mark was missing so you'd get compile errors)
so i fixed that ;p

Revision 564

Modified EE opcode table to make add/sub require sign-extended operands. This
fixes a crash in Unlimited SaGa.
WinGUI: Fixed a minor issue when changing language.

Revision 565

LilyPad: Version number updated in rc copy. Refresh device list bug on device
insertion/removal fixed. Attempt to resolve potential XInput/DirectInput
infighting by deleting DirectInput interfaces to disabled/bindingless
DirectInput devices.

Revision 566

minor vu changes

Revision 567

Not much to see here, just some patch cleanup and editing...

Revision 568

Linux: Get the locations of ini files for plugins mostly working again (I know
about the USB & FW stubs). ( Issue 55 ). This is still somewhat hackish; I'll
probably be cleaning up bits later, and this does put LOCAL_PLUGIN_INIS out of
commission for the moment. It will come back eventually. This ought to also take
care of issue 54 . You may need to delete pcsx2.cfg for everything to work

Revision 569

Linux: Show the version number for release builds.

Revision 570

GSdx: vtune JIT code profiling support (somebody should implement this in pcsx2
too, see iJIT_NotifyEvent(iJVM_EVENT_TYPE_METHOD_LOAD_FINISHED, ...), plzkthx
:P) and other minor fixes/optimizations.

Revision 571

Clean up r568 a bit.

Revision 572

- nneeve fixed some bugs when VU extra/extra+sign clamp modes were enabled.
- i added paths.h to the vs2008 project file.

Revision 573

some more vu clamping fixes by nneeve (fixes problems with the non-sse4 code)

Revision 574

SPU2-X: Fix for bleepy sounds in FFX / FFXII. Apparently effects processing is
much more sensitive to tight SPU2/IOP sync than any other part of the SPU2.
(good to know!)

Revision 575

Fixed some potential dangerous situations in VU rec

Revision 576

Code cleanup of some VU clamp functions for SSE4, and reverted my previous
useless commit :p

Revision 577

Assorted code cleanups to WinMain's message handling, and streamlined the
language selection 'gui restart' procedure.

Revision 578

Fixed a minor issue in MADDiq/MADDAiq VU opcode.
(when _Fs_ == 0)

Revision 579

Changed a behavior of recUpdateFlags a bit; now it also clamps results when flag
updating is skipped.

Revision 580

Implemented a fix for Art of Fighting, MFIFO was clearing our counted size when
it shouldn't have been.

Revision 581

Restructured the build system from the ground up. 3rdparty libs have been moved
back into a /3rdparty folder, and are compiled as libraries. Most relevant
plugins are part of the pcsx2_suite_2008.sln. Revision tagging of filenames is
still there, but is now disabled by default. Pathnames with spaces shouldn't
break the buildscripts anymore. Removed tons and tons of files in an effort to
simplify the repository and build system management. So if a solution file
you're used to using is missing, it's missing for a good reason (means the
project can be built either from the Suite solution, or by double-clicking the
project file from explorer, from which MSVC creates a new solution for you).
I'll put up a wiki soon which covers new compilation features and stuff, like
how to re-enable revision tagging, and how you can direct compiled exe/dlls to
be copied to any destination of your choice (yay!) -- plus many other compiling
tips (if I can remember them all! >_<)

Revision 582

Added a compile guide to the wiki.

Revision 583

Fixed some small errors in the new solution file settings, and added gnu_gettext
to bin, since it's a dll dependency of Pcsx2.

Revision 584

Edited wiki page through web user interface.

Revision 585

Fixed image links in the new CompileGuide wiki page.

Revision 586

Forgot a set of quotes. Build system should be able to cope with spaces in
project folders now.

Revision 587

Wiki: Added note about logging out to have environment var settings take effect.

Revision 589

Oops, hit OK instead of cancel on my last commit. Here's the second part I
Removed Commandline dialog from Release builds (it's meant for giving debug-
style commands to homebrew diagnostic ELFs used for testing Pcsx2/Ps2
compatibility). Removed the compatibility list, which was just a local copy of
the online resource. Replaced it with a link to Pcsx2 website. :)

Revision 590

Linux: Get the main program compiling again. I'll work on the plugins later.

Revision 591

Now calmping code added in r579 is enabled only in "extra" setting or above,
because it slows down some games
WinGUI: Disabled arguments menu in release build, for sure :p
Buildsystem: Made pcsx2 dependent on zlib, and changed post-build script a bit

Revision 592

Revert a cdvd timing change from playground. Fixes some games that depend on
longer seek times.
Also removed one more console log from release builds.

Revision 593

Added some better support for 8 bit VIFdma writes, cleaned up some logging
stuff, and added version resources to SPU2-X and ZeroSPU2.

Revision 595

New Feature: Press TAB to toggle the framelimiter on/off (as a substitute for
hitting F4 several times). Usable as a "turbo" feature, similar to other emus.
Many minor code cleanups to logging and constants.

Revision 596

will be gone without gamefix now :)
WinGUI: Added SSSE3 detection message into a CPU config dialog.

Revision 597

Linux: Get most of the plugins to build. ZeroSPU2 is being stubborn...

Revision 598

Ico gamefix not needed anymore.
(It's still there for Linux, I better don't touch that :p )

Revision 599

More work on patches removals and cleanups

Revision 600

Fixed bugs in LDL/LDR instructions; fixing various TLB Miss errors in assorted
games (namely ones that worked in the old VM builds). The instructions were not
sign-extending values into the upper 32 bits of the target register. (LDR in
particular has odd rules for sign extension)
Some minor cleanups / correctness fixes to the IPU's register Read/Write
Am pondering whether this could be responsible for the "Auron: Look!" bug in FFX, testing now.
Hmm nope, didn't fix it, however, there is a new message now:
"vtlbDefaultPhyWrite32: 0x213CA90"
Using European BIOS (not sure of version, but the hardware is the latest version of PS2), r613 of PCSX2, running from an ISO of the game.

Revision 601

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

Revision 602

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

Revision 603

Damnit. LWR() is a pita.

Revision 604

Modified the GIF and SPR in my wierd backward dma way :P should resolve problems
with the Avatar games, 24 videos and hopefully anything else which has broken
due to recent changes.

Revision 605

Small fix for a regression i caused in r604 with Ridge Racer V, also fixed a bug
in MAXbc on the VUrecs and added an optimization for MINIbc
somewhere between r595 and r605 the FMVs are broken, showing a bunch of green squares
That was caused by this revision. It was fixed by a reversion in 607/608.

Revision 606

Merged all recent bugfixes and stable changes into RC branch. (RC branch still
uses the old buildsystem)
Btw, my apologies. It's my fault for killing all comments in our repository. I was fiddling with some features in Subversion for changing commit logs and stuff, and apparently they cause Googlecode to erase all code comments. -_-
Omg, you gotta tell me how you did that :D
You can change commit log easily in Windows with TortoiseSVN.
I wonder how we can continue programming without any comment :)

Revision 607

Merged Ref's latest bugfix/opt into RC, after he and cotton finished debating
it's validity. (for score keepers: Ref won this one! ;)
hahah thanks ;p just dont wipe the comments again, or ill have no ammo!

Revision 608

... see above.

Revision 609

RC: Reverted SPR "fix" from r506 for now, since it turned many game FMVs into
green screens, followed by hard locks. >_<
i think is r605!
wtf... the videos looked fine here, plus now the game will hard lock and crash, which i think is worse than the video hard locking after a bit :p
but what games had green blocks and hard locking? none showed here (Ridge racer videos have always had green blocks afaik, not just this change)
fixed now... lol

Revision 610

RC: Some important changes didn't get merged right, thanks to TSVN glitches. -_-
(it's been a long night)

Revision 611

SPU2-X: Another sync regression fix. My earlier experiments didn't fly, so I
reverted the TimeUpdate call in spu2_read also (negative impact on some dma-
related things, but fixes lots of other weird stuff).
Changed several instances of afxres.rc in plugins to be afxresmw.rc (for VS
Thanks for putting the inline assembly in in both Microsoft & GCC form; one less spot to change when working on the port... :)
It's just copied straight out of pcsx2, yea. ;)
Oh, it was, wasn't it?
I've passed by it a number of times; not sure why I didn't recognise it.
Still fighting with SoundTouch and ZeroSPU2; passing ../../ in the location for SoundTouch seems like it's screwing with when SoundTouch tries to find the configure.ac file, which is back in the ZeroSPU2 directory...
hi Jack,
thanks for finally putting the mixer.cpp fix , for cubic.
However I don't know if you noticed that in issue 65 ,
i.e https://code.google.com/p/pcsx2/issues/detail?id=65
I've put additional comments.
Especially I persist to say that doing s32 mu = vc.SPc
is more accurate than s32 mu = vc.SP + 4096 when exiting loop.
Also I'm wondering if it's not worth to clip negative vals from
cubic interpolation. Anyway if this bother you, I won't insist more, promised !

Revision 612

Fix for my earlier mistake causing green blocks on videos, remind me its never
good to alter memory that you arent suppose to alter ^_^

Revision 613

RC: Merged unbroken SPR fix, and set the version number back. ;)
First of all, I'd like to say that some of the latest changes (can't
really say which revision exactly) affect Issue 46 to a certain degree,
something in the latest builds helps cure some of the issues Animaniacs:
The Great Edgar Hunt had with graphics, black and colored polygons no
longer flicker like mad and the textures don't flicker colors either.
Black and while polys do appear and flicker as you play, which looks like something SPSish as far as I can tell (or something of that kind at least), but a good deal of issues are gone by now.
And second, I just wanted to express my amazement at what you guys are
able to do. Being a coder myself, I have to admit that such level of
coding as PCSX2 demonstrates and such level of understanding both
hardware and software is way behind what I can possibly imagine.
PCSX2 is simply an incredible and unique piece of software - absolutely
astonishing. Keep up the wonderful work, guys! :)

Revision 614

Tagged SPU2-X v1.1 release.
quick changes to let ICC compile (note: also turn on /QxSSSE3 instead of /archSSE2 for a 9% speed increase on SSSE3 based PCs)
2 line-by-line comments
line 60:
60: #ifndef RESTRICT
nuke the #ifdef case for ICC, it doesn't use RESTRICT
line 10:
10: #if (_MSC_VER < 1400) && defined(XBYAK32)
ICC should also take this path, since intrin.h is an MSVC thing and will break compile for ICC.
suggested to change to:
#if ((_MSC_VER < 1400) && defined(XBYAK32)) || defined(__INTEL_COMPILER)
How the hell those last 2 comments got there I have no idea, sorry : |
If You have error after posting, so don't refresh or don't go back. Just close google code and run it again, Your post will be here. This is google code bug i think.
My error is that it posted in the complete wrong place (meant to be in issues .. some how it ended here?)
strange, but we had a slight screwup with the code comments earlier.
Could be related :p

Revision 615

ZeroGS: Resolve issue 71 .

Revision 616

Linux: Get ZeroSPU2 compiling. May be modified later, because I'm not sure I'm
happy about manually copying libSoundTouch.a in build.sh.

Revision 617

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

Revision 618

Fixed a bug in the savestate system that caused memcards to eject when they
shouldn't have (had uint instead of u64 >_<).
Developers: Changed the way PCSX2_ALIGNED16 macros work, so that they're more
friendly to MSVC and Visual Assist X intellisense (more more red squigglies on
vars like cpuRegs!)

Revision 619

SPU2-X: Trying a new (experimental) DMA option which may fix problems in DMC1,
but might break more than it fixes? (we'll find out!)
Also - Added some options to DSound driver. Enabling Hardware mode on dsound
might improve dsound compat on some soundcard drivers, for those who can't use
XA2 or have problems with XA2 stability.
Going to try thanks.
Did you based this on the line code I added on issue 18 ?
Just tried it and the devil may cry problem is still there.
Oh I think I think where the error is, You add my line of code at the wrong place. (mostly my fault the code I copied is there 2 time)
The code should be put at Line 321
Sorry for comment spam. I mean line 302
Well.. i just tryed your new code with the line I added to the earlier code, And My line doesn't seem to fix devil may cry anymore. with this new dma stuff.
Hmm, yeah I should set it up so both of those share some of that code, actually. I think I can, anyway. Or maybe it'd be more trouble than it's worth.
As it turns out I only modified the DMA Reads (which aren't used very often by most games). Dunno if it would actually affect DMC or not. Could be your problem is random. I mean it sure seems random. The DMC Issue has been a series of "it works!" and "it's broke!" for like months from various uses, and I really don't see how any of this stuff could affect it in any significant way.
Well I With my modification (file in issue 18 ) I have tryed it ferry often to not let this be luck. ANd it was really working great.
I havent seen anything bad related to other games.
SO you may consider reverting the dma.cpp and put my linee of code and wait for feedback from others.

Revision 620

Plugins: Add a check for libjpeg-dev to ZeroGS( Issue 60 ), and a few minor
Delete configure file -- it's automatically generated from .ac
Sure, sometime in the next batch of commits.
Didn't even notice it was in svn. looking at the history, looks like it's been there for a long time, too...
And ine thing -- why we have commented cg checks?
Not sure; looks like it's been commented since at least pcsx2 0.9.4....

Revision 621

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

Revision 622

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

Revision 623

RC: SIO's memcard ejection fix from trunk.

Revision 624

Remove forceinlining on a few functions that won't inline, a few minor tweaks,
and add a warning in the build file for Linux x64 people trying to compile.

Revision 625

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

Revision 626

Linuz CDVD Iso: Fix a major Linux bug that was preventing certain titles from
loading in this plugin. Dark Cloud 2, Atelier Iris 3, and Xenosaga I for
example. No more switching back and forth between Linuz and EFP. :)
Finally tracked the bloody thing down. Surprised it wasn't causing issues in Windows as well, if it was checking if an unsigned variable is -1. :)
Oh, did find one game that still needs EFP. This is a big improvement, though...
Kudos for the fix accum. That plugin prevented me from running my svn compiles until I found out about it in an older post of yours.
Thanks. This bug has been a long standing pet peeve of mine; in fact, it was one of my bigger reservations about dropping 64 bit support, becase it only existed in 32 bit Linux...

Revision 627

Minor Optimization: Added Const support to Vtlb's Load and Store
It's actually a significant amount of code, but the speed gain seems insignificant to me. In cases where const prop is available, the vtlb instruction overhead is reduced by 2-3 (10-12 less bytes of code generated). So it should certainly be faster, but might only really be noticable on AMDs, P4s, and older Cores.
I don't know why, but after this change the videos of Persona 3 FES that was sounding crackling until now (even if they got 60 FPS and lots of CPU power free), now sound a lot better (still not perfect though :D)
Anyway yes, i've noticed a little improvement in speed. :D
Huh? I see all Persona 3 FES videos correctly, unless i use a 2x (or more) at EE sync hack.
With default or 1.5 they're running great, at least for me.
Yes tiku is right. Some game's FMVs tend to crackle if you're using cycles higher than 1.5. Anyway I approve this change, any optimization is welcome, thanks Jake.
even if you are under fullspeed you will have only 60-70 CPU usage.
Thats due to MTGS.
Few percent on suikoden5 here. Anything helps I guess ;)

Revision 628

IOP Fixes/Optimizations:
* Fixed the IOP's recExecute so that it correctly preserves X86 registers (EDI
and EBX were not preserved!)
* Optimized the recExecute procedure, seems like a nice speedup in FMVs and
some games that are IOP intensive.
* Renamed psxMemRead to iopMemRead, added new Virt/Phys functions, and fixed
several instances of DMAs using translated addresses (DMAs are always physical
maps). Our IOP doesn't really emulate the tlb so it won't fix anything, but
it's more correct in cas stuff is better supported in the future.
* Removed unneeded FreezeMMXRegs, since the IOPrec doesn't use any mmx/xmm regs
What are some IOP intensive games?
You forgot the "%" signs in front of the registers in pcsx2/x86/aR3000A.S
line 179 and 180. Breaks the build on the gcc platforms. they should read:
pop %ecx
pop %edx
Also in pcsx2/Linux/DebugDlg.cpp there are four occurrencies of PSXM still
left (line 249, 253, 321, 326):
mem = (u32*)PSXM(addrf);
could you change them to read:
mem = (u32*)iopMemRead32(addrf);
Those changes are all is needed to be back on track on the other
platforms, so please apply them since you have svn access.. thanks a lot ;)
I'd send a patch in the GNU patch format but I don't know whether they're usable on ms products.
They are useable in Windows with Tortoise SVN, which the whole team (or majority) uses.
Or, of course, I'm the Linux person on the team, so I'd be able to use this.
This update is a pretty typical issue, though. Any time a *.S file is updated, it's pretty likely that the %'s get left out unless I'm the one doing it... :)
Oh, and I'll change the lines in DebubDlg.cpp, but it's essentially dead code at the moment; it broke, and was already in bad shape when it broke, and I haven't spent the time to fix it yet.
>> This update is a pretty typical issue, though. Any time a *.S file is updated, it's pretty likely that the %'s get left out unless I'm the one doing it... :)
... because %'s are EVIL. X(
Certainly explains why I'm the one always committing them. :)

Revision 629

Linux: Quick fix for the last revision.
thanks arcum... I guess u got enough sleep time :P
Yep. And it was the same type of issue I see over and over again...

Revision 630

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

Revision 631

Fix a segfault issue in ConvertTo16 on ZeroGS, and make a few changes in spu2-x
for later use.
And yes, I'll change that copyright notice later.
yay, yeah I'll help work on some of that stuff in spu2-x soon. I needed to take an spu2 break tho. :)
It still doesn't even compile as a null plugin, but figured I'd throw in what I had so far. I still am going to need to remove __forceinline on a few functions that gcc says aren't inlinable, and change a few u32's in Spu2.h to ints.
The Linux folder is still basically a jumbled mess. Adding the dialog won't be an issue; I was just waiting till it works as a null plugins till I did it.
One of the bits that would probably be the most helpful on it would be if you took the contents of the Alsa.cpp file, and changed them to be set up as a module in spu2-x...
I can understand needing to take a break, though. I cycle through different project a lot due to that...

Revision 632

MMI: Fixed a minor issue in PSUBUB/PSUBUH, and implemented recompiled opcodes
ungigned 32-bit comparison? :)
lol, typo :p
cool, more opcodes :D
are there any intensive opcodes left wich aren't yet recompiled?
Still there are a few in MMI, but genereally MMI opcodes are not intensive.
i mean in general an not MMI only.
All VU instructions, and almost all EE instructions are already recompiled. So this kind of opcode level optimization will not improve performance drastically, until AVX appears.
What is AVX?
Will this emu still be developed in 2011? :P
Probably. There are still PS1 emulators being worked on up to this day.

Revision 633

Bring in the ICC patch that makes pcsx2 build on that compiler.
Thanks to fea for this one ;)
Now we need only to fix some little details on the various plugins (GSDX crash on ESC and linking error on SPU2-X and Lilypad), to make everything working.
I'll work on it as soon as i can. :)
What 'linking error'?
SPU2-X and Lilypad makes link error on the .def file saying that there are some unresolved external. (on SPU2-X is s2r_replay, i've made a tentative patch on the issue, go and take a look, but i'm still not entirely sure it's the right way to fix this.)
I've completed the fix for SPU2-X. It is ready on the issue tracker, now i'll work on lilypad even though i think its basically the same problem. :)
Maked the patch for Lilypad too, i've posted it in the issue80 on the tracker. (with this the basic plugins compile perfectly with ICC)
Now i'm wrestling with the last plugin that doesn't want to compile. :D
Great work!
it let me re download the ICC compiler and re install it....
@fea: Oh yea, forgot about that one. I ended up just cutting the replay out of the ICC build.
When the dev team will review these 2 patches for SPU2-X and LilyPad and commit them we'll have a complete build set for ICC. :D
I'm now working fixing the minor plugin to build (the various NULL and such)
I test FF12, fatal fram1. It seems the ICC build and VC build have not any difference of the performance, though the ICC build size is almostly 2 times of the VC build. Maybe the critical part is GSDX.
When profiling the binary, it seems that most of the processing time is spent in the CPUs (EE / VU), so obviously this will mean that those prove the highest performance gain.
In saying that, you also have to realize that this is going to be optimized for INTEL processors, not AMD. If you compiled it yourself, remember to also compile the main PCSX2 Binary with SSSE3 optimizations, too.
my cpu is E5200,enabled all possiable optimization, include SSSE3 output. But my video card is N6600 and is the bottleneck. I ever oc my cpu to 3.0Ghz (defualt is 2.5G), and in FF12 the fps no change, so I feel the GSDX is the critical plugin.
Well, as GS emulation is largely to do with graphics, you couldn't hhave honestly expected an increase just by having (compiler-generated) code optimization anyway ; )
Although FF12 isn't really very graphics intensive is it? I've always seen it at max FPS and my system isn't really high end.
It depend HIGHLY on the game, on persona 3 i gained 1-7 FPS depending on the scene...(i have a Core Duo T7250 2 Ghz), on some other no gain. ;)

Revision 634

Yay more header file cleanup chores! Removed most of the Windows.h dependencies
from non-Win32 specific files, and fixed the annoying ARRAYSIZE warnings. Let's
say it together: "We all should love C's archaic include system, because it
makes Jake and Arcum work really hard for no good reason."
C++ and x86 asm are the two languages i program with, and i gotta agree with you, i cannot believe we'r in the 21st century and changes haven't been proposed to replace the include system with something more optimizied, in fact some compilers do the include job for you if they are smart enough. Check Codeblocks.
In /trunk/pcsx2/x86/ix86-32/iR5900-32.cpp from line 148:
ssprintf( filename, "dumps\\R5900dump%.8X.txt", startpc );
That's not a valid path for the non-windows platforms, I guess you should keep if the #ifdef _WIN32_ and use the "\" "/" path separators accordingly.
Actually I have nice functions to fix that, which are #ifdef free. I just got lazy because it's ugly dumps with no labels and I couldn't care less if they never work anyway >_<
So you change ARRAYSIZE to ArraySize? ZeroGS OGL should be fixing too.
Hmmm... Fixed the ARRAYSIZE warnings as in broke the plugin API? So we can start going through and making all the API changes that have been on our wishlists for a while now?
Oh, and don't worry, anyone who uses Linux. I'll have this working in Linux again shortly...

Revision 635

Clean up Jakes commit in r634, and get rid of some dead code in the assembly
And, yes, I realise I left it building in debug mode. I'll worry about that later.
Yeah I forgot to mention that I axed the PerfCounter code. Using rdtsc and/or QueryPerformanceCounter is almost never a good idea for profiling code. It's just too unreliable.
The SamplProf.cpp for Win32 is better (does the same basic thing as like VTune and such, but on a much simpler level). Dunno if a linux equivalent could be made.
Probably. There's some profiling code in the opengl version of ZeroGL for Linux, though I'm not sure if it works.
Since I was in there, figured I'd axe the old x64 bit assembly, too.
Looking at the assembly, I really wish that __delspec(naked) functions wouldn't mix C and assembly, or at least would keep all the C limited to function calls, because that would make maintaining seperate assembly files a lot easier... (I was just looking at the PITA that aR3000A.S is. I'm still not convinced that it's implemented correctly...)
Well the ARRAYSIZE thing was just a problem I've had for a long time now. I actually added it to PS2Etypes myself, as I recall, trying to fix the Windows.h conflicts before. But no matter what I did I'd either get warnings or errors. So finally I decided to rename it completely. >_<
>> Looking at the assembly, I really wish that __delspec(naked) functions wouldn't mix C and assembly, or at least would keep all the C limited to function calls.
Yeah, not really possible, without really hurting performance. :( I tried some various things but I'd loose 5-10% speed usually. DispatcherReg is absolutely critical to performance of the emulator. I'd recode it as all asm but, as you pointed out, the one in R3000a.S is a mess, and the MSVC one would basically look the same, and then I'd have no idea if I did it right or not. ;)
But right now I'm getting errors on std::min/max -- the ones I removed and you re-added. I dunno why those are getting errors.
I readded them because without the std:: part, they were coming up as undefined.
How about if you add using namespace std; to those files, and remove the std:: again? That'd work on the Linux side...
And it's a pity. I was hoping it'd be practical to, say, move:
s_pDispatchBlock = PSX_GETBLOCK( psxRegs.pc );
if( s_pDispatchBlock->startpc != psxRegs.pc )
into a separate function...
R635 doesn't compile with vs2008
"std::" error
Yes, that's what me and Jake were just talking about. Removing them in r634 broke gcc, and adding them back in broke Visual C++.
I had a left-over windows.h I didn't remove. It was mucking with the min/max defines. >_< I'm fixing it now, along with finishing up some things I didn't do before.
>> And it's a pity. I was hoping it'd be practical to, say, move [...] into a separate function.
Yea, it'd simplify the asm a lot, but the overhead of invoking a function and returning from the function would be that 5-10% performance hit I mentioned before.
On the other hand, if drk||Razi writes/finishes his new block manager, it'd mean that the whole PC_GETBLOCK macro mess would go bye-bye and be replaced with a much simpler design.
That'll be nice.
And I hate it when an extra include mucks things up.
Still looking at .S files. Interesting to see a file dedicated to a Linux version of memcpy_mmx, and then realize that it's only used once in the program, and that use is only done on Windows for some reason...

Revision 636

Re-re-fixed the Windows.h mess. PsxCommon.h still had a win32 include, and
cdvd.cpp and misc.cpp had some win/linux code which I relocated. Also, cleaned
up the vtlb's SysExceptionHandler stuff -- moved the platform-specific portions
to WinSysExec and LnxSysExec, and moved the shared code portion to a new
function in Memory.cpp.
(Yes, Linux is probably broken again.)
Oops, forgot the other part I was working on when the std::min/max thing came up: I made some of the functions in the Path namespace API to be a bit more user friendly. :) They're not as "efficient" now, but eh, it's all gui stuff. Friendly code is more important I figure.
If you added a file without adding it's name into the list in Makefile.am, yeah, it is.
Not an issue, though. I'll merge the minor cleanup I was doing with fixing this. (I'm adding a header with most of the extern "C"'s for the assmebly files in it, so they aren't scattered all over the place...)
Never mind, you did add it. :)
I added it :)
... but I'm sure I broke something else anyway :p
can you add a ICC optimization configuration on the wiki page
after the windows and linux both work ok :p
thanks your and arcum42's hard work
Eh, we'll see. I have to get my code changes working properly before I update and fix anything that needs fixing.
Guess I'll fix up memcmp_mmx afterwards. Looks like it needs extern "C"s for FreezeMMXRegs...
Oh, I can do that. I just put it on hold for a few minutes while I checked to see what broke in this commit. Right now Linux isn't using memcmp_mmx at all, but the reason it isn't is obsolete. That's why I was looking at it...
Incidentally, the only thing preventing this commit from compiling on Linux was the capitalization of "cdvd.h". :)

Revision 637

microVU rec stuff

Revision 638

Fix Linux. Move most of the externs for functions in .S files in Linux to one
header, and reenable using memcmp_mmx in Linux.
Think I accidentally reverted a minor change to SuperVUInitLiveness.
Easily fixed, though, and it's not something that'll really cause problems.
Looks like I need to make a few minor adjustments. Another commit will be on it's way shortly...
Actually, looks like something else broke Linux, though it compiles. Time to play with it a bit...
I may have very well screwed something up in my commit.
In what way is it broken? Ie, does it crash, and where/how?
Running any cd gives:
# Initialize Start.
# Initialize GS ...
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# Initialize Done.
EE DECI2 Manager version 0.06 Feb 6 2003 08:38:48
CPUID=2e20, BoardID=0, ROMGEN=2003-0325, 32M
loadcore RegisterLibraryEntries (1944c): sifcmd
intrman RegisterIntrHandler (19478): intr INT_dmaSIF1, handler 183c0
Protected memory cleanup. Offset 0x10c0
Protected memory cleanup. Offset 0x10c0
Protected memory cleanup. Offset 0x10c0
Protected memory cleanup. Offset 0x10c0
Protected memory cleanup. Offset 0x10c0
Protected memory cleanup. Offset 0x10c0
Ok, yeah I broke the Exception Handler. It's probably not masking the pagesize correctly.
Yp, that's what I did, but not to the pagesize. I actually got pageoffset and pagesize kind of confused. I'll commit the fix momentarily.
Oh, yeah, I think I see it:
SysMemProtect( ptr, 1, Protect_ReadOnly );
The debug build's broken, too, but that's easy to fix. a .cstr() was left out of iR3000A.cpp on line 197...
Nah, SysMemProtect on the Linux side automatically transforms the 1 into a 4096 now, so that the code for Win32 and Linux can be the same in Memory.cpp. What I forgot to do was align the pageoffset also.
Ah. Hadn't looked at it that closely yet.
In any case, I'm building it now, so we'll see.
This break the ICC build of PCSX2, i'm working on a patch and i'll post it here as soon as I can. :)
Posted on the last comment of the issue69 . Review it and post it on the svn.

Revision 639

Enabled PCH for w32pthreads library. It compiles a *lot* faster now. ;) [whole
thing rebuilds in under a second on my machine, heh]

Revision 640

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

Revision 641

Ah fudge. -_-
That did it. Back to normal...

Revision 642

90% of an implementation of memcpy_fast_ for Linux. And fix debug mode.
The copy of memcpy_fast_ in this commit is broken, but is most of the way there, so I wanted to commit it before anything happened.
I've already fixed the conversion mistake I made, but when I commit it, I'm going to temporarily make it optional, till I know how reliable it is.
StarOcean gives different errors with it on, which I find interesting...
And now I can't reproduce that. Weird. Oh well, it'll probably be a short test period.

Revision 643

Finish the Linux implementation of memcpy_fast_. I've disabled it by default
until I'm sure it's working right, but it can easily be enabled in build.sh.
Should be a speed boost in Linux (which Windows already had), but I haven't
tested it enough to be able to tell yet.
And, in fact, even thought it started up properly a minute ago, now it's not working again.
Oh well, I know the fix was right. I probably overlooked something minor.

Revision 644

Win32: One more foopah left over from r634 needed fixing, this one caused games
running at very high FPS to "freeze" for 2 second intervals at a time.
Heh. Brought the multiplier in from Linux, I take it?
Oh well, it happens...

Revision 645

Get the Linux side of things ready for when cotton's done with microVU. I'm sure
I'll have to make significant changes at that point, but it's good to have the
framework in place...
I was probably overparanoid with the #ifdef's, but I didn't want to mess up anything cottonvibes was working on.
Think I'll wait on anything else on this till microVU's actually done, though.
i'm doing major emitter changes now, so i wanted to backup my microVU work.
so its best to not port it to linux at this time since the current code is broken and WILL change.
No problem; I just mainly wanted the structure to be there, and to actually have the assembly file ready, even if the contents were going to majorly change.
And I'd already decided to comment out my changes to configure.ac next commit; I just haven't gotten to my next commit yet...

Revision 646

A few minor changes.
Intel build fixed. :)
Yep. Don't expect me to remember what breaks ICC, though. It's hard enough trying to keep track of what breaks gcc and Visual C++ at the same time. :(
Don't worry, i'll remember and make patch for you whenever it happen. :D

Revision 647

major pcsx2 emitter change.
the emitter is now 'templified' so that you can run multiple instances such as:
eMOVRtoR<0>(EAX, ESP);
this uses emitter instance #0
to use another instance you can simply change the number in the brackets like:
eMOVRtoR<1>(EAX, ESP);
will use instance #1.
all old-functions are mapped to instance #0 by macros.
#define MOVRtoR eMOVRtoR<0>
why do this to the emitter?
so we can have thread safety, and eventually thread the recompilers using
different emitter instances.
note: this took me forever to get working (around 12 hours of non-stop coding).
however for some reason debug build is being extra-picky and still giving
compile errors.
hopefully Jake or someone else can fix this, because i tried a few stuff, and
just got more compile errors ><
I think you forgot the ix86_macros.h file...
yeah i did, sorry :P
And you brocken Linux build too
All right, here are the issues I'm running into so for:
First, none of the functions in ix86.inl are in headers. And they need to be in headers, because some of them are calling functions that are implemented later in the file.
And a few of them are calling functions that aren't implemented at all. I'm assuming eeNOP is a typo for eNOP, but I'm not seeing eLEA32RStoRI anywhere.
Incidentally, there were the ones I ended up adding to ix86.h, becides uncommenting the ones that were already there:
emitterT void eMOV32RtoR( x86IntRegType to, x86IntRegType from );
emitterT u32* eJMP32( uptr to );
emitterT u8* eJMP8( u8 to );
emitterT void eCALL32( u32 to );
emitterT void eLEA32RtoR(x86IntRegType to, x86IntRegType from, u32 offset);
emitterT void eLEA32RStoR(x86IntRegType to, x86IntRegType from, u32 scale);
emitterT void eNOP( void );
emitterT void eAND32I8toR( x86IntRegType to, u8 from );
emitterT void eAND32ItoM( uptr to, u32 from );
emitterT void eLEA32RRtoR(x86IntRegType to, x86IntRegType from0, x86IntRegType from1);
emitterT void eAND32I8toM( uptr to, u8 from );
emitterT void eLEA32RStoR(x86IntRegType to, x86IntRegType from, u32 scale);
You know, I just realised: eLEA32RStoRI should actually just be I. Must be an accidental paste. Never mind...

Revision 648

these files aren't needed anymore

Revision 649

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

Revision 650

minor VU fix thanks to nneeve

Revision 651

MMI: Added recompiled version of PPAC5/PEXT5, and optimized PADDUW a bit.
Another instructions is great always like such sort of commits

Revision 652

Added the second part of emitter macro functionality, by making the emitter
instance configurable. We can't actually use it yet tho, since everything
shares iCore, and thus everything needs to share the same emitter instance (for
Fixed new emitter so it compiles in Debug builds, cleaned up the header files a
Linux build is still brocken. How could ModRM<I>(something) be compilable?
Believe me, it is. Linux commit coming out shortly.

Revision 653

Fix a few typos, as well as Linux.
The .inl files shouldn't be compiled as source files. They're actually include files only. So you should be able to remove them completely from the source list and add them as include dependencies instead. :)
This worked, and I didn't see much info on using gcc with include files.
I like having all the files listed there anyways, and it doesn't really hurt; you'll notice I've got headers in the makefile, too...

Revision 654

Committing the beginnings of a new PS2 Exception Handler! This is very much a
work in progress, but it shouldn't really break (or fix) anything in its current
EE Interpreters: Fixed some signed/unsigned mistakes in some instructions,
namely DIVU, DIVU1, unsigned Traps, and a couple unsigned right shifts. (all of
these were already emulated correctly in the recs)
Also: Removed the ThreadPriority stuff from Pcsx2, since it was a throwback to
the days of Win95's unstable multitasker. If you really really feel like you
need to change the thread priority of Pcsx2, use the Windows Task Manager or a
third party util.
What improvements will this new exception handler bring with it?
I honestly haven't got a clue, but it's fun to code! :D
Uggh more ini changes. Just what I need.(Keep up the goodwork :))
Hopefully it should help use easier diagnose emulation problems and give more specific infos to pass to devs for looking at

Revision 655

Fix up the last revision for Linux.
Oops I forgot the GCC magic throw() fix. >_<
That's all right; I'm starting to get used to the general nature of things that Visual C++ likes, but cause gcc to throw() fits.
Oh, and the reason why I deleted #include <sys/mman.h> is because it's already in LnxSysExec.h.
And I'm off to work. Hopefully things won't be too broken when I get back...
Yeah that's fine. I figured it was already included but couldn't really test to be sure, so I made the note so you'd know to delete it or whatever. :)

Revision 656

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

Revision 657

SPU2-X: Fix for DMC1, closing Issue 17 once and for all; also added ICC patch
from Issue 75 .
By Issue 17 I mean Issue 18 . >_< I'd fix that, but last time I modified a commit log, it wiped all of our user comments.
This comment is off-topic to this revision but not really relevant any where else either.
I was doing some digging around on assembly optimizations (bored, trying to learn). I happened to come across this site (http://www.agner.org) by Agner Fog, Ph.D; he's written some papers, proposed theories etc..
Anyway, I came across a part of the site where he keeps an 'optimized' asm library of various functions such as quote:
"This is a library of optimized subroutines coded in assembly language. The library contains faster versions of common C/C++ functions such as memcpy, memmove, memset, strcpy, strcat, strlen, etc.."
I know you have an optimized version of some of these already in pcsx2; had support for sse2/sse3 optimized versions and in another zip file gave insight on future optimization in regards to sse5/avx.
Anyway the relevant files are @
http://www.agner.org/optimize/ < Optimization Page
http://www.agner.org/optimize/asmlib.zip < Lib & Source
http://www.agner.org/optimize/asmexamples.zip < Comments about Future Optimizations
Sorry if this stuff is of no use. I wouldn't doubt you had seen it before.
Yep this work. Great job.
I have a question for jake.
Do you know if this is common in programming that you compile stuff and it work a way then you compile it again and the result may be different?
Thats see to what happen to me with my "suposely fix"
first time I compile it make a working DLL for dmc. THe second day, I compiled the same code and it didnt work :/
@Wagnard: Admittedly, your "fix" was a pretty dangerously random thing, and I have no idea how it actually ever worked. :)
@trigunflame: Thanks for the info! Great stuff. I've been wishing for a good optimization info source.
Glad to know it could be of use to you. From what little I've read from the papers, this guy really knows his stuff.
Hopefully it will help you and the others gain some insight and tips.
@jake hehe I know. Its was kinda random. I took some code from the working old revision in playground and patch them in.
I guess I just got ultra lucky.

Revision 658

Set up the x86 emitter so that it always uses MOVAPS over MOVDQA. This
generates slightly faster code since movaps is 1 byte shorter than movdqa (both
instructions are functionally identical). The optimization is optional via
AlwaysUseMovaps defined in ix86_sse.inl
Enabled optimization stuff for zlib and bzip2 projects (Release/Devel build
I hear, that MOVDQA have one advantage over MOVAPS on AMD processors (when moving fro reg to reg).
p.S. There is also one difference in Real Mode :-).
Screws Shinobi's FMV :) Sorry
Persona 4 FMV too.
if i'm not mistaken this also breaks fxii when entering the ingame menu
i'm not really sure if it was this revision specifically, but since it's breaking other games i thought it should be related (it's somewhere between r634 and r662 :P )
FFXII problem is caussed by r651. I'll fine an issue and assign it to tmkk.

Revision 659

Fixed a problem that VU clip flag wasn't propagated correctly between recompiled
blocks in some cases. SPS in Rule of Rose will be fixed by this.
And one more SPS game down. Great job! :)
I don't know why but this rec screwed Shinobi FMVs
Is that confirmed to be caused by this revision? Ie, did you check r658 also to see if it had the same problem?
Sorry I made a confusion. It's rev. 658 that screwed Shinobi's Fmv. Thanks for fixing Rule of Rose anyway.
Many thanks for you tmkkmac!
I suspect this revision for breaking God of war.
There is a lot of SPS
Change my "suspect" to confirm. rev 658 work and not this one
Look's like yuo've broke old VU CLIP Gamefix for God of War *we need it once again*

Revision 660

Fixed a bug in r658 caused by some sloppy macros.
Win32: Moved various debugger-related dialogs into a new debugger.rc file, to
help reduce clutter between both the std resources and the debugger resources.
debugger.rc(3) : fatal error RC1015: cannot open include file 'resource1.h'
Woops, I totally botched the commit for the new .rc file. ;)

Revision 661

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

Revision 662

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

Revision 663

Fixed the problem in recompiled version of PPAC5/PEXT5. I forgot about the case
with Rt == Rd.

Revision 664

SPU2-X (Linux): Did some preliminary work on the Alsa driver.
Cool. That'll help a lot...

Revision 665

Nneeve coded a new FPU clamp mode "Full" that can help some games which wouldn't
work with the other modes.
This fixes the Digimon menu for example (Gamefix will stay a while longer
though, until we confirm ingame is fine as well).
He also updated the advanced dialog a bit.
Remember that this mode can break games if VU clamp is below "Extra + preserve
<nneeve> it fixes FFX's reversed controlls on some screens (like the airship)
<nneeve> it fixes klonoa 2's green balloon positioning
<nneeve> it fixes ape escape 3's backgrounds (not to be confused with tmkk fixing the major SPS issues with the game a few revisions back)
it's likely to fix other things as well.
As said, a few games may have issues when "full" is enabled in EE but "extra+sign" isn't enabled in VU. Ar tonelico is one such game.
The games listed above seem fine even with EE at "full" and VU at "normal".

Revision 666

You might need this one as well :p
I'll include my comment about the "Full" option here as well:
<nneeve> it fixes FFX's reversed controlls on some screens (like the airship)
<nneeve> it fixes klonoa 2's green balloon positioning
<nneeve> it fixes ape escape 3's backgrounds (not to be confused with tmkk fixing the major SPS issues with the game a few revisions back)
it's likely to fix other things as well.
As said, a few games may have issues when "full" is enabled in EE but "extra+sign" isn't enabled in VU. Ar tonelico is one such game.
The games listed above seem fine even with EE at "full" and VU at "normal".
Another one "revision of the beast"... :-) Congrats...
PS: Sorry, even if I've read RevisionReviewEtiquette :-)
And adding the new sourcefile into atohell configuration file, so it could be compilable under Linux. I don't know -- windows does not require exact listing of all sources?
Sorry, I don't touch linux stuff. I'd break it instantly.
Linux compilers, makefiles, configuration files and command switches all look like some alien language to me :D
This change (the EE "Full" Mode in particular) appears to fully resolve Issue 46 with Animaniacs, a quick run through the first couple maps has showed that no flickering polygons or other trace of SPS is present in that game, I'll try to check and see if it's fully playable now.
Magic number revision :p
Comment by ramapcsx2, Today (61 minutes ago)
Sorry, I don't touch linux stuff. I'd break it instantly.
Linux compilers, makefiles, configuration files and command switches all look like some alien language to me :D
that from the guy who learned programming for pcsx2 on the hardest way I can imagine^^
Actually, adding a file in Linux is pretty easy. Most of the folders in pcsx2 have a Makefile.am file in them, and near the bottom, you'll see all the headers and cpp files in the folder listed, separated by spaces, with \ symbols at the end of the lines to tell it that there's more filenames on the next line.
All that has to be done is adding the file name in the list. But I can do it, of course...
Thanks for the explanation, arcum.
Still, I'd like to take you up on your offer, especially sine I can't test anything I do in regards to Linux.
(No, I'd rather not fight with some distribution in a vm or stuff like that ^^)
Hey, Jake writes whole Linux files without testing them. :)
Actually, though, any time I update, I always look for files added to the svn, and add them to the appropriate makefile, so it's no big deal.
Adding things to the advanced dialog box is trickier for me really. Mainly because I have to connect what you do in the gui to what the Windows code says, which isn't always obvious...
It fix lot of things in ICO
1)intro doesn't freeze now.
2)FFX was not the only game with "reversed controls bug"
3)Small graphic bug with dissapeared geometry also fixed.
Thanks. :)
Yes, I've already noticed it myself...
Guys, this build is awesome, best of all!!! Maybe it's because of it's number?.. :-)
Does all that mean that we must have top-of-the-line PCs to be able to play most games WITH good fps and WITHOUT glitches when we enable "Full" EE clamping and "Extra+sign" VU clamping?.. When I enable theese most games run 2 times slower at least...
The "more" clamping you do, the more pcsx2 behaves like the ps2 would for special cases.
So yeah, if it wasn't so expensive to use, we'd just put it all on maximum and remove the options :p
Well FULL on my pcp didnt seem to affect compared to none. :)
Good work!! Too bad it didn't fixed Shinobi SPS.. Damn game. =p It simply refuses to get fixed :)
Basically, EE's "Full" doesn't slow down things much (a few FPS might be gone for a few games). But it's not fully compatible with VU clamping options aside from "Extra + sign". And that's slow (very slow if you don't have SSE4.1)

Revision 667

Added Nneeve's fix for some issues in VU pipeline. SPS in Arc The Lad will be
Added a temporary gamefix option for God of War, which has been broken since
r659. Anyway I'll fix this problem in a proper way.
And as usual, linux part is not touched.
UI changes are done mostly in Glade-2 (or 3), and I'm not even sure that runs on Windows, so not a problem...
Arc the Lad Fixed! Now I would have another testgame.
Arc the lad fixed? AWESOME.

Revision 668

Fix Linux, and update to match gui changes.
For those curious about how the Linux end works, all the changes made to pcsx2.glade were made by a program called Glade. It then generates interface.c & h, callbacks.c & h, and support.c & h.
The other changes were done manually...
It is theoretically possible to dispense with the c files I mentioned, and generate the gui from that glade file, incidentally. The times I've tried to switch over to doing that have resulted in nasty segfaults, though... :(
It's due to having to be *really* careful about threading issues.
You made a "full" radio independent of all others -- it stay always turn on.
Oops; didn't notice that. I'll take care of it.
Weird; the copy of glade 3 I have isn't letting me change radio groups; it just stays blanked out. Guess I'll use glade 2, instead...

Revision 669

Pontifice from our forums fixed some cheating related code he wrote for pcsx2
This supposedly makes using codebreaker / ar max cheats more reliable :p
Thanks for that, Pontifice ;)
through codebreaker.elf? or patchfiles? patchfiles always need help... :) thanks
Given what code was modified, it would be patchfiles.

Revision 670

minor emitter fix and dialog text tweaking.
hah, I wonder how my search/replace missed it?
nah they were added after your search/replace.
nneeve added new emitter instructions for his fpu fix, and forgot to change them ;p

Revision 671

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

Revision 672

backup, just ignore this

Revision 673

necessary change to properly compile microVU's templates (c++ is picky with
templates :p)
How much longer do you suppose until this is actually integrated?

Revision 674

i assume these headers aren't needed anymore but were accidentally left in VS
project file :p

Revision 675

Major GUI API Cleanups. Most likely buggy as all hell.
* Moved most of the shared code between the two GUIs into platform independent
source modules (System.cpp, Saveslots.cpp, and RecoverySystem.cpp)
* Created two new namespaces which house functions that need to be implemented
by OS/platforms: HostGui and HostSys. HostGui is useful -- HostSys I'm not sure
I'll keep around in the long run.
* Moved keyEvent struct from PS2Edefs.h to PS2Etypes.h
* Many improvements to the logic flow of the GUI (should be a little less
Yep. Given that once I got it compiling, no keys worked while running the emulator, and I got lots of messy warnings when saving, buggy as all hell.
Fixed the first, and I'm working on the latter.
Like the abstraction, though.
Well, tracked down what's happening when the segfault happens, anyways.
It tries to save a slot, States_Save gets called, which then calls SaveToFile. g_RecoveryState is NULL and g_gsRecoveryState is NULL. g_EmulationInProgress is true. So it calls States_Save, which calls SaveToFile again, ad infinum...
This also tells me that a variable isn't being set properly somewhere in the Linux files...

Revision 676

Damn buggy TortoiseSVN >_<

Revision 677

Savestate version upgrade and stability fix -- added some vars that the SPRdma
might like to preserve between states, and removed some old hacky VM-related
stuff while I was at it.
Fixed up the Saveslot detection somewhat (File:Load > menu now greys out
unavailable saveslots).
Applied ICC fixup patch from Issue 84 . :)
I keep getting errors like these with ICC on gsdx for some reason, trying to figure out what's causing it.
Any idea? Here's a link to the output thusfar.
Ah, fixed it; was the same issue as jdastridge; had to to enable restrict support.

Revision 678

Gah! I forgot a line in my prev commit, so the SPRdma savestate fix wasn't
actually being used. Btw, this *may* fix unstable savestate problems
experienced in many games, including FFX and SMT3:Nocturne (but it;s so random
it's hard to know for sure).

Revision 679

Linux: Get everything compiling again. There is still a nasty crahing bug or two
from r675, in particular when using the menus for load and save states rather
then keyboard commands. I'll work on fixing that tomorrow, but wanted it to at
least compile and run.
Gah, the pad plugin API is such a crapfest. I tried to do the one thing to fix the double-key problem that happens whenever you have 2 mismatching pad plugins, but it doesn't work either because some PADs don't return null. Maybe I can fix it yet...
Also, sorry for forgetting to go back and remove ExecuteCpu(). I ended up refactoring code like 5 times, and by the 4th or 5th time my win/linux changes were completely out of synch -_-
It could partially be ZeroPad, too. Keep in mind that it's the only pad plugin for Linux. I have an issue or two with it otherwise, but I think it's the SDL api it uses for joystick input...
No problem on the ExecuteCpu()s. The one that's really worrying me right now is the fact that OnStates_Save (which is called when a savestate is chosen from a menu) crashes pcsx2. It works fine from the keyboard.
I mainly committed now rather then waiting because people start filing bugs if I leave the Linux version totally broken for more then a few hours...

Revision 680

SPU2-X: Resorted the mixer so that it's a little faster, and will be easier to
apply some SSE2 opts in the future.
What I did here is set it up so that the mixer is organized into a set of smaller loops, instead of one huge unrolled loop. This makes the code much more cache friendly. Additionally, I've sorted all the data so that it can have SIMD optimizations applied to it in the future (although I may have overlooked some alignment requirements in V_Core... >_<)
I hope all that optimizations will not break DMC1 again... ;-) Good luck anyway...

Revision 681

SPU2-X: Fixes alignment condition for SSE2-dependent members of V_Core. I
wanted to sneak this in quick since to do it later would have meant another
savestate version.

Revision 682

pork chop sandwiches!
GI Joe - Pork Chop Sandwiches ?
It's great that you're still working on MicroVU :)
Good luck
fnh800: indeed ;p
ntcong.it: thanks :D

Revision 683

IPU Bug/Feature fix: Pseudonym has coded a new yuv2rgb decoder which is up to
IPU spec (which differs slightly from MPEG spec). Improves color hue/saturation
on many vids, and is a bit faster too.
Dynarec: Removed RET2().
Good Job!
Right now Linux accepted only PCSX2_ALIGNED16(u16 C_bias[8]) format, no
PCSX2_ALIGNED16(u16 C_bias)[8]. I could be a bug here, or in ALIGNED realisation.
Oh, you're right about the aligned macro, my mistake.
As usual, I see the comment mentioning the problem after working it out... :)

Revision 684

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

Revision 685

microVU stuff
god of war no longer works properly
When this new mirovu stuff get in action what should we expect?
Is it supposed to help the speed?
The gamefix is back for god of war. Check if you have it enabled.
sorry I had not seen who had been reinstated the GameFix

Revision 686

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

Revision 687

Pseudonym Crazy-Opts Projects Inc presents: Improved block managers for EE/IOP
recompilers! Basic asm optimizations combined with a technique of replacing
NULL/invalid pointer checks with a direct link to a JIT dispatcher. A collab
effort on irc produced this gem, which improves speed on all accounts, and even
makes the linux .S files uber-simple and clean. (no more wondering if they're
broke or not!)
You forgot to change Linux #ifdef part for psxDispatcherReg!
And you made
.global JITCompile
.global iopJITCompile
in R3000A.S
Afther this two fixes, Linux build is compilable again
I'll patch that up. Having this code actually be the same for Linux and Windows is great, though...
Seems like there are quite a lot of "IOP Recompiler data reset"'s now, though...
Yea the recClears aren't optimal, but then they're not critical to performance either.
As long as it doesn't add a performance hit... I was just startled to see it printed a dozen times within minutes of starting up a game...
There was some communication mixup, the patch was just a snapshot of my working dir and wasn't commit ready. It's buggy because it's buggy.
This breaks ICO

Revision 688

Linux: Quick fixes to the new .S files, and did a mild cleanup of the recLUT
these 2 revisions broke grandia 2.

Revision 689

Experimental commit!
Hacked in a way to make GSdx change the renderer on the fly.
When you press F11 it will switch to DX9 sowftware rendering.
Press it again to get back to the setting you were using before.
-For this change I had to modify a few lines in GSdx. If that's not acceptable
we can do more drastic measures and modify the gsdx.ini :p
-F11 is currently also used for doing gsstates in debug modes, it will likely be
-When in dx10 hardware + fullscreen mode, pressing this key will crash GSdx.
And why this should broke linux build too?
extern bool renderswitch -- it does not defined. I prefer that such variables be defined in os-independent files, and externed in os-specific.
just tested this new feature with Persona4 and FFX, seems stable and there are no problems switching between two states, also there could be a note in the main window somewhere that we're in the software mode currently, or in hardware mode, anyway this thing helps pass some low fps moments with hardware mode etc, good work :)
Ok, complaint noticed. It will get changed anyway.
This commit is to show what i wanted to do and it's not final in any way.
I prefer that linux isn't supported at all, but i don't write to comments about it.Be happy with what you get, and if you have any complains about how the project works either write your own ps2 emulator, or use the last release.Svn is for developers, ppl with no life, and internal testers that can understund what wip means.
Nice Hack. ATV Offroad Fury 4 playable very simple now, thanks.
RAMA! You did it! :P
Yeah, as I said: gabest doesn't accept any feature requests :P

Revision 690

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

Revision 691

Patch up the last few commits for Linux.
@arcum: Did you notice the cool new "noprefix" thing I found?
No more evil %'s! Yay :D:D
Yeah, I saw that. Might go through and apply that to the rest of the Linux assembly, just to make keeping it in sync easier...
On the other hand, it decreases my position as purveyor of evil in the pcsx2 code... :)
Thanks a bunch, arcum. I'll make sure to care for these defines when the thing gets changed ;)
No problem. I thought about just adding the code to Linux, but unless the directX and openGL versions of ZeroGS get unified into one plugin, I didn't see a need...
Plus, this is specific to Gsdx. ZeroGS plays most FMVs well enough in either mode. GSdx doesn't replay some vids correctly (sometimes not at all) in hardware mode.

Revision 692

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

Revision 693

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

Revision 694

pcsx2: -highpriority switch, other processes generate too much noise and I
cannot trust my performance counters without it :P
GSdx: nothing new just committing a few cleanups and my findings on AA1 before
doing it, tested a few things with ps2dev on a real machine, got really strange
results when not using the standard 0 1 0 1 blending mode, but it doesn't seem
harder to implement than a line drawing (which it is), and only adds a few extra
pixels here and there, should be fast at least.

Revision 695

Added googlecode's sparsehash / densehash classes, which may or may not be
useful in the future.
Removed various instances of legacy VM code that is no longer needed for
reference purposes.
Missing HashTools.cpp

Revision 696

Added missing files from prev commit.
Break the ICC build, i've posted the patch in the issue69 .

Revision 697

Linux: Some work on the plugin code.

Revision 698

Made the GSdx render switch thing a bit cleaner, moved it where it belongs
and changed the hotkey to F9. (Sure hope no plugin uses that yet :p )
changed the code a bit :D
if (mt == 2){ //pcsx2 sent a switch renderer request
//renderer = 1; //DX9 sw
renderer = AfxGetApp()->GetProfileInt(_T("Settings"), _T("switchto"), 0);
mt = 1;
and it works.
set switchto=7 in the gsdx.ini and press F9 in Valkyrie Profile 2 when you're in Solde, you'll see this game is so damn much GS dependent.
It seems Ridge Racer V (PAL I think) doesn't like this hard/soft render
change mode on the fly at all. The game is hanging in the intro FMV.

Revision 699

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

Revision 700

Fixes for the new block manager optimizations by Pseudonym.
There's a bit more speed even :)

Revision 701

Nneeve patch for "Full" FPU, improves some clamping and adds missing values to
the savestate info.
Savestates: Pcsx2 now errors when it encounters a savestate made by a newer
version of pcsx2.
Added a new SafeList type to the SafeArray collection (not well tested yet).
I hope "version" -- is savestate version, not revision number?
You use IfDevBuild, that defined in System.h in SaveState.h, but I don't see any signs of #include "System.h" in it.

Revision 702

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

Revision 703

More block manager fixes/optimizations by Pseudonym.
This should be the last one (but you never know :p ).
Wow that's a lot less multiplications.
Well the *2 muls don't really matter mcuh, except that they save the CPU from having to use as many temp registers. But it does mean that Pcsx2 uses almost 50% less ram now!
And new function iopJITCompileInBlock -- should be added in NakedAsm.h and aR3000A.S.
Sorry, two functions: JITCompileInBlock too :-). In aR5900.S and NakedAsm.h
And after that the PCSX2 is crushed right after the start in Linux, because I overlook this *2 part form .S files. But yes, At the end I was able to compile it under Linux
Excellent, these recent commits stop the Jak games crashing, they now show an "Impossible block clearing failure" instead, which i prefer to be honest lol
Zeydlitz: could you attach a quick diff?
Fixed the NakedAsm.h part myself just fine, but I am not able to fix the asm
Zeydlitz: forgot to say, don't bother if it currently crashes on Linux.
I am not sure I understand whether it does or not from your post.
It does run (one of the) Jak games in release mode, it seems
Don't worry about it, I'll be committing a fix shortly. I just finished comparing aR3000A.S to iR3000A.cpp and aR5900-32.S to iR5900-32.cpp, and fixing anything I saw that was changed.
I've been able to start up a few games; I'm just going to do a bit of cleanup before committing, though.

Revision 704

Fix for games which start VIF1 off while the DMA is paused (Crash of the Titans
being one of them)
Jak3 now also loadable
You will probably find that was fixed in one of the recent Recompiler dispatcher fix/optimizations
glad to see you working for pcsx2 :P
the revision seems fix the unstability issue for fatal frame when framelimit disbaled

Revision 705

Fixed bug in VIF causing Tenchu "weapons" and some backgrounds not to be
displayed which was introduced in r454
Tekken5 crash on R705.
Yup, I confirm the Tekken 5 CTDs before showing the "Loading memory card" in r705, as well as r709. I think r705 might be one of the first versions to have this problem, because r700 didn't crash for sure. Reporting this as an issue as well.
It seems the VIFDMA's modification must be very careful.
can you please check earlier versions. The changes made here should NOT cause CTD's
please recheck on r713
tekken5 works on 713 again

Revision 706

Linux: Fix up the .S files to match recent changes. Make changes to SafeArray to
avoid compiler warnings on every file.
thanks arcum,
sadly I am getting this at any game just after the bios intro:
terminate called after throwing an instance of 'R5900Exception::TLBMiss'
Odd. Everything seems to be working properly for me, and I tried messing with a buch of settings to see if it was a setting somewhere.
Though it might be worth deleting pcsx2.cfg, just in case something crept in...
I tried that but I get the same behavior.
The games I could test are "Saint Seiya" (both sanctuary & hades (EU PAL))
and "Hokuto No Ken" (Jap/NTSC).
Hokuto no Ken has sound but no video(black screen), I think it's a zerogs
The Saint Seiya games crash with this:
# Initialize FPU ...
# Initialize Scratch Pad ...
# Restart Without Memory Clear Done.
EE: Unrecognized op dc
EE: Unrecognized FPU/COP1 op 45100000
branch 10250043 in delay slot!
branch 10250043 in delay slot!
terminate called after throwing an instance of 'R5900Exception::TLBMiss'
They were working fine some revisions ago.
I have Multithreaded GS on.
If anyone can test those games on windows, it would be great.

Revision 707

time for some fun edits :D

Revision 708

implemented alot of microVU shit...
Hey! There might be kids reading this changelog someday!
Kids generally excrete, too, contrary to populate belief. I'd be more concerned about the effect of a non-capitalized "I" on their fragile psyches.
I like this changelog :p
That's not all to worry about; this commit also contains nudity. Look carefully in the diffs in one of the files, and you can see the exposed end of a naked function.
This is clearly not a kidsafe commit. :)
this commit is Rated 'R'.
May contain adult themes, adult activity, hard language, intense or persistent violence, sexually-oriented nudity, drug abuse or other elements not suitable for children.
I've been watching the svn for a while but never created an account until now. I'm 14, which is probably the closest to a kid you will get.
Has cottonvibes scarred you for life? If so, do you have any objections to being scarred for life?
Don't forget the question if you're scarred was it more the "I" part or the part about excretes XD

Revision 709

LilyPad: Safely exit fullscreen on escape hack now sends the escape back to
PCSX2 as well after un-maximizing the GS window.
Minor changes to the general config screen's hack section.

Revision 710

implemented more microVU 'crap' :D
ICC build was broken again
1>..\..\HashMap.h(622): error: argument list for class template "HashTools::Dictionary" is missing
1> UnicodeDictionary( const Dictionary& src ) {}
cotton: let me guess, Rated X this time!
@junrgao just apply the patch from https://code.google.com/p/pcsx2/issues/detail?id=69 this will fix the icc build. the error originates from rev696.
yep, i already submitted a patch, but is waiting for someone to apply it. :D

Revision 711

A fix for some VU clamp functions, by Nneeve.

Revision 712

Fixed a bug in the new patch code introduced in r669, and applied a patch for
ICC from Issue 69 . Thanks, feal87 :)

Revision 713

Fixed a silly error (on my part) which stopped the Gran Turismo games loading,
looks like it was the same reason Tekken 5 broke too.
This should fix ATV Offroad as well and any other games which experienced crashes/infinate loops on r705
hope this revision will not break other games :P
It shouldnt do, was a massive mistake in 705 which i overlooked, so any games broken in the process should be resolved ;p
Yes, Offroad is fixed. Thanks.
Tekken 5 works nicely now, thanks! :)
Yay! Gran Turismo!

Revision 714

SPU2-X: Fixed some problems with saving/loading states, when loading from old
savestate versions.
Pcsx2: Small speedup for the IOP's recClearMem (used a forceinline to cure
MSVC's laxidazical inlining)

Revision 715

added some missing CRC's for the ffx hack when MTGS is enabled
What games does the FFX hack break when it's on, anyway?
Why not make it a gamefix instead so that people would want to get rid of it?
I believe this is exclusive to FFX, that's why.
Well from what I read in the documentation, the FFX hack seems correct. I once asked around what the FFX hack breaks but nobody knew. I didn't ask refraction, though. So I guess I am now.
Pretty much, this section of code predates the gamefix dialog. This fix is turned on for FFX, FFX-2, and Harvest Moon.
There's also a gamefix specific to Erementar Gerad, and the path3hack for Sprint Cars and Flintstones Bedrock Racing hardcoded in there. Crazy Taxi and Spacefisherman used to be in there, too, but the hacks they turned on have been removed by now.
This function is one of my pet peeves, actually. And you are right, they probably ought to be in the game fix menu. Bet we'd get a lot of complaints if we moved it, though...
NLOOP hack breaks the bios :p
im guessing there is potential to break other things until its worked out why that breaks the bios
That's odd.. It doesn't seem to break the bios at all over here... I tried both executing the bios through the null plugin and run->execute and I see no difference.
This is with g_FFXHack replaced with 1, MTGS mode and GSDX's nloop hack on.
try without MTGS mode and the black tick in GSDX
I tried and the BIOS works fine with the nloop hack enabled, both through MTGS or without MTGS.
I think this problem was fixed a while back. Cotton and I fixed some bugs related to the processing of the XGKICK and GIFtags, and I had a hunch back then that it probably solved NLOOP issues. Unless someone can find any breakages, I'm thinking we might be able to retire this one.
If we retire it, I'd suggest we add two patch files to replace the 2 crcs with the path3hack, and that we just drop the VUFIX_XGKICKDELAY2 hack entirely. Then we could get rid of the function.
The path3hack is already in the patch system, iirc, and the kick delay hack only effects erementar gerad, a game that has scrambled graphics on several scenes, and only runs on ZeroGS.
I'd assume that since it's in the VU code, that function is slated to be rewritten at some point, anyways...

Revision 716

Don't try this.It will bite you.And it'll be your fault.
--removed most of the code from iR5900-32.cpp
--Added blockmanager.cpp/h that i worked on before
keep in mind, this is a wip attempt to update/rewrite the rec (eerec), and it
won't even compile.This is the last warning i'm going to do for non devers,
you'll have to check the URL of the changes on your own to decide if any commits
are for this branch or not.If you can't live with that then stop reading the svn
Ok, it wont work. I think people get it :p
Keep going :)
get what? *compiles*
Oh-oh. So you rewrite assembler part in r5900? I better wait, until you finish, because for Linux this stuff should be merged.
I don't code for linux, someone else will have to port it over.If it ever works that is.
Which would probably be me or Jake.
I know you will do a great job here raz :)
new block manager?
maybe it will fix lots of games when it is complete :P
i tried it and it bit me :(

Revision 717

A frog in a well won't know the ocean.
this changelog is philosophical
heh, it was in some anime i watched:
"Translators Note: this saying expresses the idea that one can never fully comprehend anything beyond his experience."
its a pretty cool saying :D
anyways, since all my updates for the next few weeks are going to be for the new (non working) VU recs i'm working on, it'll get boring if i keep saying "microVU rec stuff" in the log messages :p
Can certainly understand that. I get pretty bored with typing "Fixed Linux" over and over again myself...
"You're cuter when you're fat." - Uzumaki Naruto to his wallet frog
http://www.afroginawell.com/ lol
Pork Chop Sandwiches is more interesting :P
The caged whale knows nothing of the mighty deeps. If it makes you any happier. :)
(Terry Pratchett)
I hope this thing will become... overwhelming.
Did you say mighty or nightly? :)

Revision 718

Linux: Straighten up or remove a few Windows/Linux differences in the code
(experamental), remove some dead code, fix a mistake in the Linux version of
memcpy_amd_ (still broken, though), and change optimization levels due to gcc
optimization induced errors.
The -msse2 flag, incidentally, was so I could include xmmintrin.h & emmintrin.h, allowing me to comment out that assembly in iVif.cpp, and just use the same code Windows does.
And I'm not sure why __builtin_bswap32 wasn't used in the first place in Mpeg.h...
Or you could use this:
mov ebx, eax
shr eax,16
shl ebx,16
or eax, ebx
mov ebx, eax
and eax, 0xFF00FF
shl eax, 8
shr ebx, 8
and ebx, 0xFF00FF
or eax, ebx
Or you can use pshuflb xmm0, xmm1
>> And I'm not sure why __builtin_bswap32 wasn't used in the first place in Mpeg.h...
I think because mpeg.h was written in 1997 or something ;)

Revision 719

Many small bugfixes and optimizations:
* Fixed Memcard init so that Memcard1 isn't default in both slots (oops!)
* Fixed Memcard path logic so that cards outside your pcsx2 folder can be
* Fixed CDVD-to-BIOS time sync (I simply forgot a function call!)
* Optimized yuvrgb_sse2, by using Mod/RM form instructions.
* Win32: Same optimization applied to FreezeXMMRegs and FreezeMMXRegs (linux
already had this optimization)
Hmmm... in ix86_tools.cpp, should I apply the same asm changes as on Windows? I already have to fix the extra ); anyways...
Nope, GCC already has the optimiztion:
>> "r"(g_globalXMMData)
That assigns the offset of g_globalXMMData to a register of GCC's choosing. Thus, all the %0's are mapped to a register when GCC does its optimization pass.
.. at least I'm pretty sure that's how the inline asm syntax works. I'm probably wrong or something. :S
Think you're right; I believe the "r" does stand for register. I'm just used to tuning out that section of code... :)
Hmmm... The changes to yuv2rgb.cpp are giving me issues. Unlike the .S files, it isn't feeling like processing the defines (though I'm sure it would if I used the same gimmick ix86_tools does).
I'm sure I can fix it, but I have to leave for work. So the Linux port'll be broken till I get home, possibly longer... :(
The #defines might work better as an enum{} -- I dunno. Worth a shot. I'll commit it in a bit and I'm sure Zey well let me know if it's broke or not ;)
You should install Linux, where're you from, so I can send you my Ubuntu DVD as a gift ;).

Revision 720

Linux: inline asm fixes.
I am very sorry, but you could not use static variables in GCC asm :-(,
Or enums, it looks like. Unfortunately, Since it's a workday, I don't recally have much time to fix this right now.
I was able to get it to compile by removing the static and const keywords, and then turning the enums to u32s. This resulted in most of the FMV's I tested sending pcsx2 into infinite "Protected Memory" loops, which is already something it seemed to be doing a certain other times, like starting up FF XII.
Protected memory cleanup. Offset 0xe169440
Actually, not FFXII, but I know I've been seeing it recently. I'd better get to bed, though...

Revision 721

GSdx: Implemented edge anti-aliasing (aa1) for software mode, bios or ffx are
good test subjects (not many other games use it). It's still a bit slow but
could be improved a lot by not doing 4 pixels with sse for each single edge
pixel, that's just a lot of unnecessary texture lookups. The bios config screen
cubes are still bogus, gs_user on aa1 isn't too helpful...
I am getting a few fps speed increase in software mode with the AA1 selected though.
Does the hardware renderer support AA? if I disabled the AA function in the driver setting.
and the software renderer will be the future main method?
Change the d3d internal res in the hardware renderer for effects similar to AA
Change internal res similar to Supersampling AA...Am I right ?.
afaik, supersampling a bit slower than multisampling ( I read it in nForce website ), so is there any performance increase in gsdx if we use multisampling
This helps the BIOS edges on cubes nicely. FFX seems to use it only on geometry.
Hope this is a simple flag, and every game can be forced to use it :p
A question:
Only FFX and Bios screen gets advantage from this feature ?
yes it does, but only by your videocard driver, not by GSdx.
I can't compile this rev
Yea, compiling everything below SSE4 is broken atm.
AA1 is not like the AA of directx, more like an extra anti-aliased line drawn at the edges. It enlarges objects so can't really be applied on everything, just selectively with care by the original programmer of the game.
It is less important for the hardware renderer, but at native resolution it will be possible to implement it with dx11, that passes the coverage value to the pixel shader.
wtf, no text wrapping, google roxx.

Revision 722

LilyPad: GSDX10 + fullscreen + escape workaround that's lamer than the last
one, but seems to work much better and should cause no issues with GSDX+DX9,
other than a slight delay.

Revision 723

microVU's upper instruction implementations (second pass) finished (except for
clip instruction)
No more "crap" or "shi" microVU things :P
Does that mean it's already implemented and working on Pcsx2?
it means we all have to test it ;)
I don't think so.
MicroVU is not yet used by PCSX2 because it isn't complete.
I think that MicroVU can be used ... after 1 or 2 months
only half part of it, the lower part is wip...

Revision 724

started on the lower instructions

Revision 725

more lower instructions implemented

Revision 726

at least cotton does something O_o
...from somewhere by someone...
it seems that the lower part was completed

Revision 727

Fixed a bug in memcpy_fast that caused memory corruption on blocks not aligned
to 32-bits in length (this might fix the linux memcpy fast problem too).
And with that, SF:EX3's crash on load is finally fixed. GJ.
good job
You've made a small mistake in comment on line 384 in fast_routines.S -- you put a semicolon (;) instead two slashes (//). But except this, everything fine.
That's why it wasn't working in Linux. Seems to work nicely now, and I just enabled fast_memcpy by default in Linux for testing.

Revision 728

nneeve improves the software-emulated FPU accuracy ("Full" mode in Advanced
Appended notes:
* ADD in iFPUd should be bit accurate (unless it isn't. needs TESTING)
* MUL in iFPUd with Software Emulate MUL is as much as I could get near bit
accurate (not quite enough, probably. needs TESTING)
Correction : This commit adds a "Software Emulate MUL" option in Advanced dialog. This emulates MUL a bit more correctly but is quite slow. It's probably only useful for a hang in Tales of Destiny, but who knows.
It has nothing to do with "Full" mode. ("Software Emulate MUL" works both with and without "Full".)

Revision 729

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

Revision 730

GSdx: sse2/ssse3 build fixed
sse.h fixed but still get tons of errors on GSVector.h
lines 1480, 1493, 1540, 1571, 2130, 2443, 2458
could you please tell me how can I download or try this project
[email protected]:
Which config and what errors? I have tested all and they compile for me.
Gabest: Any chance of looking into the cause of the race start crash in Gran Turismo 4? Been happening ever since many many gsdx revision updates a year ago roughly.
Note that the crash only occurs in the gsdx9 version.
They are warnings not errors, signed/unsighned mismatches are fine
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1488) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1493) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1493) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1540) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: идентификатор не найден
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(1571) : error C3861: _mm_castps_si128: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2130) : error C3861: _mm_castsi128_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2443) : error C3861: _mm_castpd_ps: identifier doesn't found
1>c:\users\zerox\desktop\pcsx2\plugins\gsdx\GSVector.h(2458) : error C3861: _mm_castps_pd: identifier doesn't found
Ali this combination of errors repeats for me several times
Check your C:\Program Files\Microsoft Visual Studio\VC\include\emmintrin.h file. It looks like wrong\old version of this file. I have no any errors...
BTW, what MSVS version you are using?

Revision 731

wxgui -> New Branch! This is to be an eventual replacement gui of the future for
Pcsx2, based on wxGui. Initial content coming soon.
By wxGui I meant wxWidgets. >_<
lol, i was thinking about why you were using a Tcl/Tk library. :D
I feel the whole pcsx2 will be rewritten :P
Which would be a good thing. I`d love to see the gui take a change to be more of a transparent display (ala zsnes`s gui) as that would be alot more game friendly, rather than having to start games from scratch or having to run a command to continue.
Dunno if we'll get that far. There are problems inherent to the GS Plugin model that make it potentially difficult for us to embed the display window into Pcsx2's gui. Ultimately it could be doable, but it'd just be a lot of work and would require plugin API changes and planning and such.
But what the wxWidgets gui will do for us here is simplify the whole win32/linux cross-platform mess. And it should also allow us to thread the GUI (Something I would have done already except it'd break linux or get ugly with lots of platform dependent code and stuff).
One of the benefits of doing it this way, too, is that wxWidgets uses gtk+ as a backend on Linux, and standard windows widgets on Windows. So the plugin configuration boxes will still be consistant without being rewritten, though I'm sure they'll be rewritten eventually.
And it ultimately means I can stop fiddling with the Linux gui so much, because the Linux gui will be the same code as the Windows gui, which *everyone* works on...
Why you guys do not consider Qt4 as the GUI front-end?~
Choose Qt4, WxWidget or Gtk+ are depend on developer's choice, it's probally the same.
afaik, pcsx2 for linux is now using gtk, gtk is x-platform rite ?, why not use gtk+ for both linux and windows version

Revision 732

Pcsx2-wxGui: Initial commit of "non-functional" gui (WIP). It compiles but
doesn't do anything yet (none of the menus have been bound to actions, except
for the GameHacks dialog). Initial wxWidgets project additions and prepwork are
courtesy of Feat87.
The copy of wxWidgest on the repository is for Win32 only. It's presumed at this time that Linux will use/link to some system-global distro pre-installed/compiled or something. I think that's how some other projects do it, and it keeps the wxWidgets install at around 17 megs instead of 50 megs needed for all the unix distro stuff.
Yeah, that's what I was planning on. That's what we do with most of the other Linux libraries, and Linux is good at handling that sort of issue.
Any version requirements as far as wxWidgets is concerned, though?
the actual version included is the 2.8.9.

Revision 733

Folder Structure change: Renamed the 'Win32' folder to 'Windows' for several
plugins. It's technically more correct and alleviates some confusion with the
Win32 target/build folders generated by MSVC.
Now how about consistancy on having the plugin source in src, Src, or directly in its directory? That one's bugged me...

Revision 734

Pcsx2-newgui: I missed *just one* file in my last commit to the newgui branch.
This'll fix it so it compiles. >_<

Revision 735

Fix the yuv2rgb.cpp issues, per Zeydlitz's patch in issue 100 . fast_memcpy works
in Linux now as of r727, so I'll leave it enabled for a while, and if it seems
stable, I'll remove the switch for it, and have it permanently enabled.
I'm still not sure why GCC needs the volatile switch. :|
And I am *so* going to have to do that naming trick in some of the other areas of the code that have %0's and %1's all over the place...
Beats me, but if it's what gcc wants to run, I'll go with it...
BTW, stumbled upon this perl script:
Volatile is useful if you want use complicated structures in assembly. It's not 100% needed (you could remove it, and it does not crush), but someday compiler could guess about optimization of you data and rearrange it's fields. I think for MSVC it's good too -- not to try optimize such data.
p.S. I think if you wrote assembly, you know better how to arrange data, than compiler?

Revision 736

R3000air; New branch housing my rewrite of the IOP's interpreters and
recompilers (also very much a WIP). Initial commit of branched materials will
be up in a few mins.
It's a big project......
I'm almost feeling left out that I don't have my own WIP branch in with nothing works yet. Guess I'll just have to share the wxgui one.. :)
Please do! Working on GUI stuff is *exhausting*, and the workload is pretty big, since we have many dialogs in need of restructuring. >_<
I probably will, though not likely till Thurs...
Initially, of course, I'll probably just be getting Linux to compile it. And I consider having "Run CD", "Execute", "Reset", and "Exit" to be the highest preiority commands to link up... :)
Are you trying to grow a PCSX2-tree with hundreds of branches?... :)

Revision 737

R3000air: A new IOP, from the ground up! Currently it is Interpreted only, and
buggy (doesn't boot, but does run some thousands of instructions before
erroring). I did a partial branch, which means checking this out and running it
is tricky -- you need /trunk/common and /trunk/3rdparty, and you need to make a
new solution file. This is also part of my experiment to see how life fairs
when using a partial branch as such.
I of course provide no technical support for people daring to use my broken code. But I figured I'd give an explanation of how it's set up anyway, in case people out there enjoy torturing themselves on this sort of thing.
i have a small question: doesn't the IOP use pretty much the same processor as the one in the PS1? can't the team use code from pcsxe or something? plz correct me if i'm wrong :)
And have fun rewriting the recompilers :P
We are right now. I believe that's what Jake's rewriting... :)
It's not about speed. It's about not sucking in terms of compatibility, stability, and debugging. And ya, the IOP was originally pased on pcsx (the original), but it's not exactly high on the compat scale or the "not a total hackfest" scale either. ;)
well the way i see it, the IOP recompilers can be slow as hell and not prevent pcsx2 from reaching high speeds :P i mean the iop uses a 25MHz CPU iirc, and as long as it's running on a different thread, it won't hinder performance, because even if the code is very slow, any modern-day cpu will be able to emulate it afaik. So yeah it's not about speed :P
thx for clearing up the compat thing. i used to think pcsx had a very high compat rate (yet i never played ps1 games on the pc).
Anyways, have fun ;)
>> and as long as it's running on a different thread, it won't hinder performance.
True. Unfortunately current IOP code in Pcsx2 isn't thread safe. That's one of the things I aim to resolve. :)
PCSX2 is in a great period now  !!!!
maybe one day it will boot also psx1 games :)
whats about the recompilers in epsxe or pSX?
couldn't the devs share it for pcsx2?
they work more than perfect, especially in pSX.
i mean r3000 as the iop for PS2 Emulation, not for PS1
This is why the code is being rewritten, the iop interpreter/rec originally WAS the one from PCSX (the Ps1 emulator by the original team) but the ps2 IOP isnt quite the same, although it is close, it didnt work as well as it could have. So the best thing we can do from ps1 emulation is use it as a baseline reference, as the lack of documentation on the IOP is extreme.
Indeed, documentation lackage on the IOP is annoying.
Anyways, I'm fixing bugs and making it easier to fix more bugs and reverse engineer unknowns. And if pSX wanted to have their code open sourced, they'd have open sourced it. Sheesh people.
That's why I love you guys. Keeping such a project as Ps2 emulation as open source.
Those guys who work on emulators in "closed projects" should shut themselves in hell and rot, kyahaha. Best of luck in the new IOP :D
Hey Jake here is a very juicy document about R3000 instructions os PS1. Hope it can help: http://psx.rules.org/system.txt
I think you already know this, but in case if not: http://members.at.infoseek.co.jp/DrHell/ps1/

Revision 738

Improved PCR/TIMR support -- fixed a case where games would try and read from
the PCR multiple times in the same recompiled block, reuslting in bogus values,
and fixed some sign extension errors on the interpreted version of MFC0.
For the PCR0/1 updates I just call the new C functions from the recs, since the C funcs don't need any flushing, and the PCRs rally aren't checked that often afaik. If it actually seems like a performance issue on some games, we can update the inlined versions later.
I doubt it'll be a performance issue tho, and only having to update the C versions makes life a lot easier. :)
This fixes Orphen.

Revision 739

Fixed a problem in the new VU clip flag code that a history of the flag is
cleared wrongly in a certain situation. Unfortunately the problem in GoW is
still there :(
MMI: Optimizations for some opcodes.
wasn't the GOW problem just the bug in the PLZCW rec?
i'm confused...
This here is a different bug that popped up after a fix for the VU clip flag beeing "forgotten" sometimes.
This commit breaks BIOS loading!
The GOW problem is not the clip flag being forgotten, but it issues double CLIP's (one straight after the other) and it has to use the most recent result to get the next calculation correct, which is why i put that bit of code in to update the flag, but due to other recent changes this no longer functions (unless you tick the option)

Revision 740

Added some preliminary exception handler code to the PCR's. No point in
finishing it right now since the rest of the EE's exception handler is still in
flux, but at least it's ready for a quick upgrade now. :)
Causes the GS window to freeze on init with speed hacks on. Not fixed in later revisions until 744 at the time of writing this

Revision 741

Fixed my stupid mistakes in the previous commit.

Revision 742

cleaned up some code (knocked off 100+ lines in Alloc.inl), and implemented
'ESUM' opcode.
<drk||Razi>cotton2: write more helpful logs kthx ;p
<cotton2>doesn't matter, no-one cares what i write since it doesn't effect
anything for now
<Krakatos>cotton, stop posting those useless commit comments XD
<feal87>no no, please continue. they're fun, i look forward to read them
<feal87>from time to time
<cotton2>lol :D
<Dwarg>Please spend more time making them more amusing.
<drk||Razi>cotton2: it does matter
<cotton2>dwarg: yeah i know!
<Dwarg>drk||Raz: Why? They're useless for reversion testing
<cotton2>i have to think of good stuff to write :O
<drk||Razi>when the next vu coders (if any, ever ;p) want to look at your code
.. and the history is full of crap
<drk||Razi>that won't be much useful
<cotton2>there won't be a next vu coder!
<Dwarg>Comments in the actual code would be more useful, wouldn't they?
<cotton2>my code is perfect!
<cotton2>>.> <.<
<cotton2>but seriously
<cotton2>i don't think it can get better
<cotton2>unless like
<Dwarg>Rather than going back and comparing SVN comments to changes made way
back when
<cotton2>you want to support AVX
<cotton2>or w/e intel's new SSE thing is called
<feal87>and anyway AVX is like 3 years away
<feal87>in that timeline pcsx2 i think will be stabilized
<drk||Razi>cotton2: just log kthx
<drk||Razi>implemented y,x,z
<cotton2>thats what the diffs are for!
<feal87>and anyway really its useless for this stage
<drk||Razi>yea i know
<feal87>until microVU is active and used by PCSX2
<cotton2>i'm just implementing different opcodes though, its not like i'm
chaning features
<drk||Razi>you can tell anything from the code -- no comments or changelog
needed.Right ? ;p
<feal87>then every change should be documented for regression testing
<cotton2>drk: yup!
<cotton2>its not like i'm changing stuff
<cotton2>i'm just implementing things that havn't been coded
<cotton2>so theres nothing to regress to
+1 :D
+1 because it doesn't feature me saying any of my usual stupid IRC crap!
Now, thats helpful :p
+1 for lowest entropy (relative to the amount of words XD)in a pcsx2 commit ever XD
This thing will make my day... Really... :D
Lol, nice commit log :)
especially changelog :P
should +2
I Lold, helpful indeed :P
I totally agree that more useful comments would be alot more welcome, as joking comments only is useless, and leads to the inability of knowing what happened on a commit unless you go and check the code, which is all just wasted time.
Alot of us do read what you write in the commit logs so it is of use to us the users of the emulator to know exactly what changes were made in the background. If all the appears in a commit is something like "humpty fell off the wall again" then thats completely useless to everyone.
Also: "<cotton2>there won't be a next vu coder!"
Famous last words :p. Please write more useful comments.
It's his own rewrite project so nobody else has really to check whether the code is right or not or even when the code was implemented so i think
so long as he knows where he implemented what the commit log should not matter...

Revision 743

Small changes to makefile to enable code to compile out of the box. Fix to
romdir.c to avoid uninitialised data being written to output.

Revision 744

nneeve fixed min/max FPU opcodes to be more precise when running in "Full" clamp
he also cleaned up some other stuff in iFPUd.cpp
somewhat with the last commits, the emulator doesn't start emulating, tried even with GSdx and ZeroGS and the same thing happens.
Here a screen showing that.
make a thread in our forums for help the emu is working fine for me.
I think it started happening with r742 or r738 and up..because before it was working fine
that was EE sync hack's problem..
I figured out! The EE sync hacks seems to got broken,only with default cycles is working
lol we posted in the same moment ;P
Yeah I can confirm this. Pcsx2 break in BIOS loding from rev 739

Revision 745

Fixed the bug in r740 that broke speedhacks; and improved the PERF support a bit
more using bitfields and more correct mode tests.
Thanks! Ahh much better with speed hacks =P

Revision 746

More work on the PERF counters. Counters now selectively count or don't count
depending on mode (which should keep some games happier which might try and use
them, if still not being totally accurate or correct).
1 line-by-line comment
line 191:
191: Console::Notice( "COP0 - PCR0 Unsupported Update Event Mode = 0x%x\n\t(Nneeve says this should probably never happen!)", params cpuRegs.PERF.n.pccr.b.Event0 );
I don't think I ever said that, but whatever :P

Revision 747

Added option to control PCSX2 volume only with volume keys, instead of global
windows volume. Release shift, control, and alt on deactivate. Fix for
changing skip mode on alt-F4 (Accidentally removed the old fix for it in 0.9.5)
Forgot to mention changes affect LilyPad only. Also, volume control is Vista only.
nice feature!
i hope spu2-x will get a volume booster too.
The sound is sometimes too quiet.
For most apps, default volume level is 100% and can't be increased. As a result, I keep my system volume a little on the high side so I can turn down app volume to suit me. Problem is most everything has to be turned down a little, but at least I can adjust everything to a level I like.

Revision 748

Minor PERF fixups -- moved the diagnostic msg to a less spamming-like area (on
PCCR assignment, rather than on PCR update).

Revision 749

optimized some stuff, and implemented all EFU opcodes.
note: most of the microVU EFU opcodes are implemented with completely different
algorithms than zerorecs. this might prove to be more accurate, but i mainly did
it to avoid using x87 FPU instructions (since i'm using mmx regs for storage).

Revision 750

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

Revision 751

some tweaks based on some optimization tips jake found.
the idea is that with SSE, doing operations that don't modify all the vectors
can give false-dependencies, and in some situations prevent CPU's out-of-order
execution (slows things down).
so the solution is to only use stuff like "movss" when you need to preserve the
upper 3 vectors, if not, its always better(faster) to use movaps.
asm optimizations are always good
(on a side note ... funny how the many positive comments abruptly ended around the first normal change log^^)

Revision 752

Fixed a bug that caused pcsx2 to crash when loading/saving savestates using the
"other..." menu option.
Added new command line options for running pcsx2 without a gui. Using "pcsx2
[filename]" where filename is the name of a cd image, will run the game. use
"pcsx2 -nogui" to boot whatever you have configured in your CDVD. Use
-bootmode=1 to enable the quick boot method (same as RunCD) .. default boots
through the BIOS. [untested feature! please report if it's broken]
TNX! But, ESC Hack not working, fix it, please.

Revision 753

R3000air branch updates -- added Instruction disassembler and diagnostic info.
(Merged all relevant trunk revisions.)

Revision 754

microVU recs: fixed a bug in LQ, and implemented LQI and LQD.
question: Any particular reason you nuked the const modifiers on the various SIMD tables?

Revision 755

R3000air branch: Interpreter working nicely now booting games. IT's (inredibly
slow* but it's booting. :)

Revision 756

Linux: Bring in sync with recent changes. (as usual)
Too bad that usegui/nogui thing is only half done. :/
Also for some reason I thought testrun stuff wasn't on Linux. I guess you ended up adding it recently-ish?
No, think it's been there for a while. Could be mistaken, but I'm sure I remember going over it in passing, and wondering if it even worked a number of times...
I think it might have a long long time ago (0.9.4) -- but even then it's usefulness was limited. The most interesting options -- the PAD keyrepeater for example -- aren't implemented. And without that there's not much point to automated running of games via batch.
Quite true. It probably was about time to rip it out.
I'd thought about revising the command line args for a while. I'd just never gotten around to it...

Revision 757

Linux: Fix Final Fantasy XII. (memcmp_mmx appeared to be freezing MMX and not
thawing it, and it didn't freeze it in Windows.) Comment out some unused code.
Remove some code I commented earlier. And consolidate some of the calls to
Looks like I deleted a semicolon in IopDma.cpp without noticing it. I'll take care of that next commit...

Revision 758

Should warn when can't write to config files. Getting sick of repeated posts by
the unwashed masses about this (Though also find it bizarre that Vista chooses
to not allow an app to write to its own subdirectories). Also, included VC 2005
project now builds successfully as long as you have an svnrev.h.
Again, LilyPad only. Really need to remember to add that to my logs. Should be able to edit it, dangit.
You can edit it! But ... it wipes all the comments on googlecode, so it kinda sucks either way.
Damned if you do, damned if you don't. -_-
I really like Vista's approach. They tried to clearly separate configuration from program data - like Linux and Unix based system. That forces all programs to have user specific configurations. All system wide settings should need administrative rights.
All data in one place just seems insecure to me... I mean, does GTA III really need access to, say, your tax returns? Storing everything in one place also completely negates the need for an uninstaller, other than to clean up shortcuts, which I think is a good thing, as a lot of installers leave random junk sitting around.
Also, there are legitimate reasons to have two versions of an app installed, or two copies of the same app, and want different settings for each. Former not working could be blamed on the software developer, but latter I'd blame on Microsoft.
It might not actually be a bad idea to move the ini files out of the pcsx2 directory.
For the wxwindows port, wxStandardPaths::GetUserDataDir returns
'C:\Documents and Settings\username\Application Data\appname'
on Windows, which Vista would like, and
'Unix: ~/.appname'
which some of the Linux people would like. And it's already possible to override that location on the command line, iirc...
The difficult part would be telling the plugins where to get the ini files from. Which is one reason why I've been wanting to have pcsx2 pass the plugins the ini file directory path...
I'd be happy with passing the plugins the ini directory.
'C:\Documents and Settings\username\Application Data\appname'
i hate applications that store their ini files in a completely different directory than the executable file.
cuz then i have to track it down, and its just annoying.
every app should have their ini file in the same directory as the executable file (or in a child folder) IMO...
it makes things alot easier if you ever have to modify or delete it.
and yeah, pcsx2 should pass the ini directory to plugins.
Probably the best way to go is to let the user choose inside the program.
My only difficulty with that is where to store the location of the ini files...

Revision 759

Linux: memcpy_fast seems stable enough on Linux, so I'm removing the switch, and
turning it on by default.

Revision 760

implemented some more opcodes...

Revision 761

Minor fixes to the IOP Interpeter and const prop regarding the SLTIU
Removed the rest of the references to the UseGui global boolean since it wasn't
used anymore.

Revision 762

Some header work, get rid of some dead code, and rename PsxCommon.h.
fatal frame is broken when take photo, 720 is ok.

Revision 763

R3000air branch: Interpreter is pretty much finished now (tho not extensively
tested at this point). Performance is roughly 15-25% better than the old IOP
interpreter. Additional feaures include:
* Support for branch instructions in the branch delay slot (known cases exist
on the PS1, may not be an issue on PS2 tho)
* Correct support for delay slot exception handling.
* #define free, and lots easier to trace usingt he debugger.
(merged trunk revisions into branch)
I'll mention now (and probably later too) that this new IOP will not be backwards compatible with old savestates. I took this opportunity to redo the iopRegs structure to have relevant info, and to remove some of the non-relevant stuff.
good job :P
Is it already implemented in the place of the old IOP ??
This is great can't wait it to be applyed in emu :P

Revision 764

pcsx2-wxgui: maintenence merging of trunk revisions into the brance (always a
good idea to update branches after header file renames)

Revision 765

cleanup: moved 'software emulate mul' to gamefixes section since it seems to
only be needed by 1 game.

Revision 766

Preliminary work on a new version of the plugin api. Not hooked up, and very
subject to change. Mainly committed both for backup, and for other devs to mess
Oo multi tap support O_o pretty please with sugar on top
alright after this unnecessary action can I please go to bed now?^^
(just my way of saying cool could be nice)
It has potential, but right now, it's mainly the old API, broken out into more files, using EXPORT_C_ instead of CALLBACK.
I did make all the init functions pass the ini directory to the plugins, merge a few spu2 functions together, and change a few variable types. Other then that, though, I wanted a base in svn that we can build on.
I'd encourage any of the devs to play with these files, especially the ones maintaining plugins...
If PCSX2's still going to use PAD plugins instead of only SIO, you should rename PADinit, so pad plugins can maintain PSX emulator compatibility.
Also, might not be the best spot to ask...But how exactly are SIO plugins supposed to work? Looking at SIO.h, looks like you get a u8 value indicating device type, to which you respond with a value indicating device exists or it doesn't, and port and slot are indicated by a register value. How is this supposed to be handled by an SIO plugin? Plugin has a different function for each port/device type it supports with its own SIOchangeSlotCB function? So if supporting multi-taps and pads on ports 1 and 2, you'd need to 4 different functions? Or do I have something wrong?
One other thing: PADfreeze and SIOfreeze might be useful. Pad mode and force feedback setting need to be recovered when loading a state, otherwise some games will give you a "please plug in a pad" screen for a few seconds, which can be annoying.
@matt: go ahead and modify/comment the code itself as you see fit with regard you PADs and sio. I think you know the subject better than most the rest of us.
That was pretty much the intention. I made the main changes that I could think of and then committed it so that everyone else could make changes. And I figured that the people actually working on plugins would be the best people to make changes to those particular apis.
And I'm in about the same boat as you are with sio. Wouldn't be suprised if the person who introduced it isn't currently on the team...
As far as compatability, I suppose we could rig something up. I just pretty much figured we'd lost compatability when I yanked all those useless void *pDsp's from the open statements.
I could potentally create a new call just for passing the ini location, though.
Actually, those void pDsp's weren't useless - they were used to pass the gs's Window handle to the pad plugin, which basically all Windows input APIs need. A pad can just look for the topmost window for the current process, and pray to God (To Microsoft?) it's the GS, but that's not too robust unless you trust Windows to always put a window on top when it should, which I don't. With MTGS, you can figure out which thread the Windows belong to, and compare that against which thread the pad is being initialized in, but that doesn't work in single threaded mode.
Other plugins can also use a Window to receive Windows events (Audio device state change, audio file finished playing, etc), though in practice, they haven't been doing this. Best just to keep them around, I'd think.
If it is actually being used, I suppose we should..
I'd looked at a bunch of plugins, and hadn't seen them used, but my focus had been on Linux plugins, naturally, and I hadn't really seen it being used.
I'll put it back, rename the variable to something more appropriate, and document it's use in the code, then. Besides PADFreeze, any other functions that you'd find useful, or information you'd find useful to be passed to the plugins?
Nothing I can think of, though might want some standardized way of passing volume control keyboard input from the pad plugin to the SPU plugins. No idea how Linux handles it, but on Windows, unless a process captures volume control input, modifying the volume control affects system wide volume. This doesn't work all that well if you just want to affect PCSX2's volume and have music or something playing in the background.
Not sure if Jake is interested in implementing this on the SPU side of things. Volume messages can already be passed to PCSX2 through the KeyEvent stuff, so only the SPU api would need to be modified.
Right now I use Vista's single process volume control stuff to do all this from the pad plugin, but it might be nice to do something more general that doesn't depend on using a single pad plugin and is cross-platform compatible, at least in theory.
Also, thought pDsp was already documented:
// s32 CALLBACK GSopen(void *pDsp, char *Title);
Opens the plugin, return 0 on success, else -1.
The plugin must fill the 'pDsp' arg (32bit) that'll be
passed to other plugins (*1), this is OS dependant (*2).
On Win32: pass a HWND value, ie:
*(long*)pDsp = (long)GShwnd;
On Linux: pass a Display value, ie:
*(long*)pDsp = (long)display;
*1 Even if this value is passed to every plugin, this
may not be used by the plugins.
*2 This could change anyways, ie. maybe you can code a
GS/PAD plugin for a speacial library, so the pDsp
will be a value that you need to communicate between
them (if you need to do this).
Hmmm... Perhaps we could pass keyEvent to all the plugins, rather then just GS, as an extended function.
And I was thinking of in-code documentation, and documenting what it's currently being used for, as opposed to the theory of what it can be used for...
matt: hmm, I have some problems with pDsp, casting it normally like
GShwnd = (HWND) *(long*)pDsp);
will suffice for pcsx2, but whenever I try/debug it for PSX Emus, it gives me
expression can't be evaluated! although GShwnd points to the same address as pDsp but it says unused?? I even tried IsWindow IsBadPointer..
anyways for now I get the GShwnd using GetForegroundWindow() as soon as GS window created (it's temporary solution)
I tried a debug build of your plugin LilyPad, with SSSPSX emu, it doesn't work and when pressing ESC the emu crash!! I thought you might give it a look :)
arcum42: about plugin spec, I don't know if there is anyway to let plugins send messages to GS plugin to display them for specific time (like savestate slots changing), does GSprintf() do that! and how can other plugins use this function sorry for the noobish questions, I am not familiar with pcsx2 code :)
Rebellious: Sometimes pDsp is an HWND and not and HWND*. Depends on the GS plugin. I copied SSSXPad's solution to this. (Use IsWindow on pDsp, and if it's not, it's an HWND*). IsBadPointer should prevent a crash, but honestly, haven't played around with it much. LilyPad works with epsxe and PCSX2, haven't tested it with PSXeven lately (Or whatever it's called), but it used to work with that, too. I used to use GetForegroundWindow() as a backup, but no longer do so.
If you were running fullscreen and using the fullscreen escape hack, then the hack's the reason, particularly if you weren't using the SVN version.
It's actually PCSX2 itself that uses GSprintf(), not the pad plugin. That's how ZeroGS displays plugin state changes, and how things should be handled. My display saveslot number in window title thing is just a complete hack, and not really how things should be done.
Also, you might want to look at either SSXPad's or my PADinit() functions. SSXPad's has less extra junk in it, so it probably a better choice.
Err...PADopen, rather.
SSSPSX's crashes are due to what I'd call an SSSPSX bug. I suspect it's not opening the plugins and subclassing the GS window in the same order it closes them and unsubclasses the GS window. As a result, any pad plugin that subclasses the GS window (Only mine?) causes a crash. Without source code, hard to be sure. Works perfectly with epsxe and PSXEven, though, both with and without the fullscreen escape hack enabled.

Revision 767

Forgot two files.

Revision 768

forgot to commit this...

Revision 769

wx: Get the wx port to compile in Linux. (Note: will not actually run games at
this stage.)
wxWidgets has it's own text formatter you should use instead, called wxT().
I didn't think it would be an issue in Linux (it's needed in Windows when I enable Unicode, which I haven't bothered to do yet). But yea, better off using wxT( "Text!" ) instead of _T  :)
Also! I plan to implement my new translator, which will take regular non-T strings always (as keys), which is the other reason I didn't add _T to everything. Hrm. I really didn't think Linux would need those _Ts since it compiles using UTF8 anyway. Oh well. :(
I'm learning WxWidgets now..thanks for the pro code :P
Yeah, it immediately started complaining about using const char*'s, where wxStrings should be. And I'd gotten the impression that _T and wxT were interchangable when reading the wx docs. I can change them, though.
Using wxBORDER_THEME instead of wxSIMPLE_BORDER was rather important, too. At least, if you think having a title bar and close box is important. :)
@ntcong.it: Keep in mind we're learning wx as we write this, so this may not be the best code in the world initially...

Revision 770

Further work on the block manager.
Grandia 2 is still broken but this is a little faster, less clear happy and
"impossible block clearing failures" shouldn't occur any more.

Revision 771

Adjusted the backwards timing on GIF for intermediate transfers, this resolves
hmm gonna make another small update to this, something ive done there i didnt realise before lol. stupid boolean..
Hopefully you got the dump to work? Was annoying to mess with I know. Regardless, gj.
i think there was a modification made to savestates in a plugin, which caused it not to work for me (as i had older plugins) but i got it sorted

Revision 772

Fixed a slight error in my last commit, fixed a bug from another previous commit
and put in rama's hack for FFX which was bugged from r604, i know why its
happening, but how to solve it properly is the issue.

Revision 773

Disabled whole program optimization for dev builds, it really isn't needed for
development builds, all it does is slows us down :P
Yeh, good thing :)

Revision 774

Grandia 2 is playable again. The old block manager was incorrectly clearing a
block which didn't need clearing and thus masking this constprop bug.
so no more freezings after FMVs?
uh sorry, i meant Grandia 3 loll..
For no FMV freezes in G3 you have to use Gabest's CDVD plugin (maybe giga's will work too).
Thanks! hope that works.

Revision 775

wx: Add a logging dialog box, and a debug menu.

Revision 776

Realised that I probably broke MOVZ/N with my last commit and tried again.

Revision 777

Made a rough start to what will hopefully be helpful in the future with dma
timing and control. So VIF1 (and MFIFO) now have a restructured layout, i have
left old code in place for the moment just incase its all a waste of time :p
ee cycle hack was broken :(
Jak & Daxter is playable now o_o
no more crashes when collecting precursor orbs :p
The EE cycle hack? can you check other revisions please, i dont think this should effect that at all
Older savestats don't work anymore,it gives me:
Error: Out of Memory
Not like before with error in the console,and the problem is on exactly this version(on 776 is ok)
yeh old savestates will no longer work :P

Revision 778

Made constant register saving more simple and certain. Grandia 2 is probably
the only game that this would've fixed, but maybe there are others.

Revision 779

Plugin APIs: Restored pDsp, renamed to pDisplay for clarity (Though arcum42's
right and about needing documentation). Renamed PADinit for psx emulator
compatibility. Played around a bit with SIO api, thinking for simplicity best
to just use one plugin of each type (SIO PAD/MTAP, remote, and memcard. Could
even be separate types, but no real need for it). Added PADFreeze() and its
friend SIOFreeze().
Oh yea... Also modified PADinit to not have a "flags" entry, so only one pad plugin can be active at a time. Multiple pad plugins has never really worked, and basically just been a nuisance in terms of additional support requests.
agree, but if pad plugin can be selected either as pad1 or pad2, so would it be the emu is responsible to check if both selected or what?
btw: I suggest to pass "char *configPath" as constant, plugins should never change the working/config path, that will lead to problems if it happened to other plugins and the emu.

Revision 780

Plugin APIs: Corrected a few things that got missed when I committed initially.
Moved the ini path passing to a separate function. Restored a few functions I'd
deleted, and depreciated them instead.
Is there a need for each plugin type to have its own *configpath function? Could just have PS2Econfigpath() or something, and just call it in or immediately after every call to SysLoadLibrary() for all plugin types.
Not really. I was just following the established convention, but it could easily be moved out, and that might be a bit cleaner...
I think there is a typo in GSApi.h, SGSconfigpath instead of GSconfigpath :p

Revision 781

The joys of unrestrained find/replace. :(

Revision 782

Rewrite immediate jumps from the block manager instead of having dispatchers to
do this at execution time.
Should be a tad faster.

Revision 783

Fixed a problem around the VU clip code, introduced in r659. GoW and Persona
(and more) now work without a gamefix.
I'll remove the gamefix if there is no problem.
All problematic games I had are fixed by this :)
well done :)

Revision 784

Removed a VU Clip gamefix.

Revision 785

Forgot this.

Revision 786

LilyPad: Removed "Axis" binding buttons. Try to autodetect full axis bindings
instead, also a dropdown in case that fails. Experimental, untested PADFreeze()
Fixed a bug with full axis binding, too... Since no one has mentioned it, and it's been around since 0.9.5, guess not a whole lot of people need/care about it, anyways.

Revision 787

Linux: Bring the gamefixes dialog up to date.

Revision 788

Plugin APIs: Now that I've figured out how multitaps work, fixed SIO API so it
can theoretically actually work.
Oo you probably don't know how much this means to me oO
thank you
To make the speed limit disable (with tab) more useful, it would be nice to make the GS api able to disable/enable vsync anytime. That way games could be played normally without tearing, and sped up using tab, disabling vsync only then.
Just a thought.
I thought vsync is broken and atm only halves the fps
When that does happen, it's usually gfx card drivers being broken. I've seen it with other apps/games on two of my old nvidias.
Sync to vblank works fine for me with hw/sw and dx9/dx10, with gsdx.
Vsync works here, but it instantly halves fps on any short stutter.
So except your game usually runs 80fps minimum, it will be annoying :p

Revision 789

Plugin APIs: Added the changes in r788 to PluginCallbacks.h. Changed the config
path function to be one of the general functions, not plugin specific, and it
now passes the whole pcsx2 config, not just the ini path. I can see all sorts of
uses for that...
Is a dependency on PCSX2 like that really a good idea? I know there aren't exactly a whole lot of other PS2 emulators out there that might want to share plugins, but still...
Also, should Pcsx2 continue to support pad plugins once I have SIO working? I'm planning on writing a very simple SIO wrapper than can be added to any existing pad plugin to convert it to an SIO plugin. Only real advantage of SIO plugins for pads is that they support multitaps, though I suppose we could just update the pad plugin spec to support multitaps instead of implementing SIO, and make multitaps be handled internally by PCSX2 (Requires like 10-15 lines of code, at least for my test game. Bunch of values don't seem to be used by it, so I can't play with them).
Just need to add a PADsetSlot function or something. Might be simplest to go that route, actually...
That's a point. Maybe I'll make it an alternate function, and leave it up to the plugin developer to choose.
I could go either route, as far as the plugin spec goes. The latter might be easier, as we wouldn't have to update every pad plugin in existance.
OTOH, I'm perfectly willing to take that SIO wrapper, and apply it to ZeroPad, and if gabest applies it to his pad plugin, we have most of the bases covered. (Except for SSSPSXPad, anyways...)

Revision 790

LilyPad: Fixed some binding stuff that some incompetant person broke in his
last release. PADfreeze fixed so should work when called twice (Once for pad 1,
once for pad 2).
Just to be clear... The aforementioned person is myself.

Revision 791

Save States: Added PADfreeze calls to PCSX2, though they're currently only
implemented by LilyPad. Also fixed a bug where a save state would failed to
load when the last plugin's freeze function actually saved something. Minor
changes to new plugin API as well.
Because of a convenient bug in load state function, older save states with no
saved pad info should still work. Don't blame me if they don't, though.
Combined with the LilyPad update, this will get rid of the "You need a DS2 plugged in, damn you!" messages in FF12 and other games when you load state too soon.
Looks like this breaks savestate loading with PadSSSPSX, since it has its own PADfreeze function for some reason. Can't find any reference to anything actually using it, and it's not open source, and there's no documentation on it...Hmm....
Really I cannot load from new revision's save state from any pad plugins from recent revisions. Load from old revision's save state work fine though (before r791). But from new revision save state I got hang (Trace back into Lily.dll).
Unhandled exception at 0x0db7ad8a (LilyPad.dll) in pcsx2.exe: 0xC0000005: Access violation reading location 0x00000004.
And yes PadSSSPSX cannot even save (pcsx2 close its self), but it can load old revision's save state.
Game: FFX and FFX-2
Try on r791, r794 and r797.
I hope this help.
I can't reproduce the crash - save states work fine for me with LilyPad (latest and the one released in the SVN plugin update, which was 694). Works with SSSPSX 1.6.0 (It's on the SVN, though it doesn't automatically compile), too. Only thing I've tried that it does not work with is SSSPSX 1.7.0. You are using LilyPad for *BOTH* pad 1 and pad 2, right? If you use SSPSX 1.7.0 for either pad, it will crash.
The freeze call in padssspsx is just a ret, no one pops the arguments off the stack there.
But I also cannot use save states, pcsx2 just crashes upon reload, going to debug it.
Found it :P

Revision 792

implemented all vu lower instructions (second pass).
All? and what about lines 599-606^_^ in microVU_Lower.inl
those are branches, they're handled differently.
i can't implement them till later on :p
Nice one
btw ... are you sure you want to keep line 878 like it is now ?
The domain seems kinda dead and sold ...
mehh line 878 in microVU_Lower.inl
forgot that ^^
Why do you avoid SET** in FCOR and not in FCAND and F*EQ? You can do something similar in both.
FCOR only sets VI to 1 if the result is all 1's.
that's why i can do the trick to avoid set**
the same trick won't work for FCAND and FCEQ.
AND r, imm
SUB r, 1
SHR r, 31
XOR r, whatever
SUB r, 1
SHR r, 31
there :P
the one for FCAND you posted gets the reverse of the result we want.
so it work work unless i add a few more instructions:
AND r, imm
SUB r, 1
SHR r, 31
AND r, 1
that might be more expensive than using set**, i'm not sure.
but that trick of subtracting 1 seems to work nicely for the F*EQ opcodes, i didn't think of that :p
Whoops, yeah.
AND r, imm
ADD r, 0xffffff
SHR r, 24
that would also work.
hmm yeah that works :D
i had thought about that trick before, but initially i thought it wouldn't work for all possible values, but after reviewing it again, it does seem to work :P

Revision 793

Looks like the new PCR/TIMR code wasn't called correctly in recMFC0.
This broke Fatal Frame (yes, again..).
Thanks to Nneeve for finding and fixing it so fast :)
I don't know what should to say, rama :P
nice work !!
but the ee cycle hack still was broken for FF
Use intc_stat hack then.
Yeah, looks like an oops. I deleted some code by accident.

Revision 794

LilyPad: Lots of new code that (ideally) makes absolutely no difference. And a
fix for saving rumble settings in PADfreeze.

Revision 795

seems i had misunderstood ACC's pipeline rules.
turns out there only needs to be 1 instance of it, so i had to fix all opcodes
that use ACC.

Revision 796

LilyPad: Couple GUI fixes and cleanups, with intention of releasing soon. Added
mysteriously missing check for binding same control on different pads, fixed
rearranged pad type stuff.

Revision 797

work in progress stuff...

Revision 798

Disabled global optimization properly, and enabled Incremental Link, on devel
builds. Minor code changes compile fairly instantly now. ;) I'll make some
property sheets for enabled/disabled LTCG/WPO in the future.
Added a new Threading class: ScopedLock. Used as an automatic unlocking mutex
(safe for use with C++ exceptions, and cleaner/simpler code too). It works like
C#'s "using" and "lock" directives, for those familiar with that.
Optimized the AtomicExchange implementations for MSVC.

Revision 799

LilyPad: fix0red the save state reload crash (memset overflow randomly null'ed
the global dm variable and other things).
Tyvm, i was wondering whether to report this or not.
federelli: In general, best to report something that significant if it's not getting fixed quickly, IMHO, especially when the author of the buggy code (me) can't reproduce the issue and if you know what you're doing and speak articulate english. No offense to those who don't, but someone who can tell you exactly what problem they're running into, making it clear he knows what he's doing quickly, really helps quash these things quickly.
Indeed, but you guys keep a clean issues list, unlike Dolphin project, and i wouldn't like to see it cluttered with stuff that is likely to be fixed due to the obviousness of the issue. Will report more often from now on though!

Revision 800

Emitter: encode negative 8 bit immediates for some instructions and EAX forms
for MOV

Revision 801

more W.I.P. stuff..
Just because I love to nitpick irrelevant things:
#define writeQ ((mVUinfo & (1<<5)) >> 5)
.. is generally compiled more efficiently when written as:
#define writeQ ((mVUinfo >> 5) & 1)
(compiler uses an 8-bit immediate instead of a 32 bit one)
yeah i should have used the latter method you mentioned.
most those macros were copy+pasted, so i didn't really pay attention to efficiently, but rather if i got the shift-values correct.
i'll probably fix it on my next commit :p
eh, i meant 'efficiency' :p

Revision 802

LilyPad: Minor GUI rearrangements and attempts to beautify. Relabeled "Hacks"
that aren't really all that hackish. To be released as 0.9.11.

Revision 803

xpad: repaired broken keyboard event forwarding to pcsx2

Revision 804

Improved CDVD seek timing; should speed up some games that had abnorally long
load times -- hopefully without breaking other games. (testing needed)
Fixed a condition in the INTC hack that could cause it to hang in rare
yay!! gonna test "Test Drive: Unlimited", "Street Racing Syndicate" and "Need For Speed Carbon". Will report in later :)
ok i tested TDU, it's the same...not a single thing has changed...still runs at 50FPS (PAL) while it actually displays 1 frames per minute. (GPU usage is at 3% and CPU usage is at 62% . i have a core 2 duo P8400 at 2.26GHz and an ATi HD3470)
As for Need for speed carbon, it starts to slow down on the "Loading" screen (just like it did before), but now it's causing the emu to stop on a Tlb miss. (dunno when this started happening. Haven't tested anything for at least a month).
Still haven't tested street racing syndicate tho.
hope that helped a bit. And if anyone needs some dumps, just let me know :)
There is a typo in CDVD.cpp
static const uint Cdvd_FastSeek_Cycles = (PSXCLK*30) / 1000; // average number of cycles per fastseek (37ms)
may be should be
static const uint Cdvd_FastSeek_Cycles = (PSXCLK*37) / 1000; // average number of cycles per fastseek (37ms)
static const uint Cdvd_FastSeek_Cycles = (PSXCLK*30) / 1000; // average number of cycles per fastseek (30ms)

Revision 805

Fixed a bug in the vtlb constprop support (stores weren't using the right
Reduced the BIOS rom warnings from gaudy red text and stars to simple yellow
warnings (since they really don't matter).
Gah I keep saying stores, but it was actually Loads. >_<

Revision 806

R3000air: Revamped the interpreter's setup to use some nifty virtualized
functions for super-compact and clean interpretation + constprop + optimization
info tracking. And, oddly enough, using virtual functions yielded a speed
(merged trunk revisions to current)

Revision 807

Removed unnecessary rs flushes for loads and stores

Revision 808

Save a few bytes on const flushing using 5 byte eax movs for 0 and -1 instead of
10 byte immediate movs.

Revision 809

Minor optimizations to vssprintf.

Revision 810

* Added support for the R3000A's DIV unit (runs mult/div instructions parallel
to other instructions)
* Moved Instruction Implementations into .inl files and added some forceinline
directives (15% speedup, thanks to MSVC's global optimizations being bigtime
fail still, when it comes to class member functions).
* Improved the disasm diagnostic, both in terms of speed and output quality --
tho it's still incredibly slow.
For those keeping score:
I'm up to 95 fps in Disgaea's menu .. original IOP interps were ~65 fps (tested by specially enabling the IOP interpreter with the EErec).
The latest speedup came because I implemented pipeline perfect cycle timing for the R3000's DIV unit, which as it turns out, is almost never used in parallel by the IOP kernel code (so it generates tons of 35 cycle stalls, which cut down on the instruction throughput considerably).
Oh and for the record, I get 154 fps when using the current IOPrec, so the interps are still plenty slow in comparison to that, obviously. (however my experimental Threaded IOP Interpreter got about 147 fps ;)
Compiled error.
1>..\..\SaveState.cpp(143) : error C2065: 'PAD1freeze' : undeclared identifier
1>..\..\SaveState.cpp(144) : error C2065: 'PAD2freeze' : undeclared identifier
1>..\..\Plugins.cpp(74) : error C2146: syntax error : missing ';' before identifier 'PAD1freeze'
1>..\..\Plugins.cpp(74) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>..\..\Plugins.cpp(74) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>..\..\Plugins.cpp(91) : error C2146: syntax error : missing ';' before identifier 'PAD2freeze'
1>..\..\Plugins.cpp(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>..\..\Plugins.cpp(91) : error C2086: 'int _PADfreeze' : redefinition
1> ..\..\Plugins.cpp(74) : see declaration of '_PADfreeze'
1>..\..\Plugins.cpp(91) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>..\..\Plugins.cpp(358) : error C2146: syntax error : missing ')' before identifier 'SysLoadSym'
1>..\..\Plugins.cpp(358) : error C2059: syntax error : ')'
1>..\..\Plugins.cpp(391) : error C2146: syntax error : missing ')' before identifier 'SysLoadSym'
1>..\..\Plugins.cpp(391) : error C2059: syntax error : ')'
1>..\..\x86\iFPUd.cpp(394) : error C2065: 'CHECK_FPUMULHACK' : undeclared identifier
1>..\..\x86\iFPU.cpp(656) : error C2065: 'CHECK_FPUMULHACK' : undeclared identifier
Kenz: You must manually do Svn update your /Common and /3rdparty folders, if using the r3000air branch. That will fix your errors.

Revision 811

pcsx2: got rid of the compile warning.
microVU: minor changes/cleanup.

Revision 812

Added a BastTaskThread class to the threading tools.

Revision 813

Implemented more correct support for the IOP's "isc bit" (bit 16 on the COP0
status register), which in turn allowed me to simpify some of the IOP's memory
access and paging logic.

Revision 814

More changes to the IOP's memory model. Some of these are experimental and
might cause problems (needs testing). Quick rundown:
* The R3000 does not have a TLB, and has no valid addresses mapped above page
0x2000 in physical memory [lower 512M]. Thus all addresses can have the top 6
bits masked off and still retain full validity. For example, address 0xbfc0 is
simply a mirror of physical address 0x1fc0. Technically speaking, a full
emulation of the IOP memory model would raise bus error exceptions for accesses
between 0x2000 to 0x8000 segments (instead of treating them as mirrors of the
lower 0x2000 segment), but buss errors are generally fatal (unrecoverable)
program errors that would never happen within the context of game emulation.
* The IOP's SIF register space is only 256 bytes, and then mirrored repeatedly
through it's 64k page at 0x1d00.

Revision 815

Major overhaul of the savestate system!
Since backwards compat of savestates got totally broken a few revisions ago
anyway, I decided to take this opportunity to revamp the savestate system with
some significant cleanups (yes it loses all backward compat once again).
Improvements include:
* Reduced state size by removing some unneeded data (faster saves now too!)
* Added string tags to varios "sections" of the states to assist in
troubleshooting and retaining savestate compat in future versions.
* Better error handling and fewer memory leaks.
* Removed some unused/obsolete data from psxRegs, Counters, and psxCounters
* Removed all old savestate versioning code, since none of the old versions are
supported anymore anyways.
Woot, no longer 5-10second pauses when saving :D. A good milestone's been reached today, grats.
does(/should) this solve the IPU issues with savestates?

Revision 816

LilyPad: Svn release builds now have svn numbers, some configuration
load/save/populate code cleanup. Two additional checkboxes that at the moment
do absolutely nothing useful, so don't get too excited, probably be quite a
while before I get around to hooking everything up...

Revision 817

A few very minor comment cleanups; getting all my code branches in sync for when
I hit the road today.

Revision 818

Linux: Fix a minor breakage in the gui code I just noticed...

Revision 819

Fix for some random slowdown introduced in 815 (bad cacheline coloring caused a
random 30% speed drop when not using speedhacks) >_<
I can't compile pcsx2.I get error message:
..\..\vtlb.cpp(53) : error C2086: 'vtlb_private::MapData vtlb_private::vtlbdata' : redefinition
c:\documents and settings\VSUB\my documents\visual studio 2008\projects\pcsx2\vtlb.h(89) : see declaration of 'vtlb_private::vtlbdata'
The problem is in this rev. not in any other(811-819) and I've tried to rebuild pcsx2 including pthreads and zlib.Everything is up to 819
Sorry,ignore my post...after I reinstall my windows I forget to add the common folder back to my update program(the common folder was rev 798)

Revision 820

Linux: Make some of the assembly look a bit better. Change the

Revision 821

wxgui branch: Full merge of trunk into the new wxgui, including a revision from
way long ago that somehow got missed (when I renamed Windows folders in some
plugin dirs)

Revision 822

Nneeve worked a bit on our lovely floating point cpu's (mis)ability to do rsqrt
the way the ps2 does.
Should be better now ;)

Revision 823

Get rid of some duplicated code in cpuException...

Revision 824

LilyPad: Fixed PADfreeze bug. Also some stuff that shouldn't do much yet.
what's the purpose of PADfreeze anyways..?? can you enlight me.. is it saving PAD mode and state or what?? without this function seems I can't resume execution when I pause the game..
Just saves the state of the pads. When you're configured for both pad 1 and pad 2, it's called twice with different arguments. Just look at SaveState::FreezeAll(), memSavingState::FreezePlugin() and memLoadingState::FreezePlugin() in SaveState.cpp. Or LilyPad's implementation of PADfreeze(), though LilyPad's a bit of a mess.
*Twice with the same arguments, rather. Called with different arguments for loading/saving/determining how much memory you need.
Thanx alot, didn't notice since I debug with earlier revision builds..

Revision 825

microVU: implemented first pass for upper instructions.

Revision 826

GSdx: a few games should be sharper (example: persona 4, guitar hero), blurring
effect done inside the output merger is overridden when detectable, hope nothing
got broken by it.
This is a nice fix. Agreed, Persona4 just looked like crap with the blurring.
You couldn't make out anything really, even at highest render targets :p
Does this remove blurring effect of FFX?
If you mean the blur in battles then no, that's a different thing.
Excellent, there's lots of games I've tried that have the same issue like Persona 4 that looks blurry and refuse to look great whatever internal res I set.
Would be great to list titles that improved, or did not improve, those I could examine further.
I think God of war 1 is a little sharper.
Can't test God of war2 because of the Green screen when using hardware acceleration. (like God of war 1 used to have some month or if not a year ago.
isn't it possible to remove the blur completely or just shift everything to center that pixel for pixel is correctly displayed?
hope you know what i mean
I'm not sure what you are referring now, ffx?
nice work! gabest
but this don't work on blurring
effect of dragon quest V ,check it out if you can
@ gabest
no, i mean games like god of war, jak1, GT4, etc... they are also blurred
ok, going to check dq4, gow, gt4, I have those
- gow was similar to persona4, just shifted the other source
- dq5 also used the output merger for blurring, just a bit different
- gt4 does not seem to do anything suspicious there

Revision 827

Linux/SPU2-X: A bit more work on the Linux port of SPU2-X.

Revision 828

2 more things by Nneeve. Let's see:
A few changes to the full fpu mode, so it behaves as erratical as the ps2 fpu.
And a fix for a MMI opdcode.

Revision 829

Buildsystem improvements - Added two new property sheets for Incremental Linking
and Global Linking. Incremental Linking is fast and allows for Edit and
Continue debugging (debug/devel builds), Global Linking is for Release builds.
Applied new property sheets to Pcsx2, SPU2-X, ZeroStuff, and NULLs.
Not sure if having Edit and Continue enabled is worthwhile or not. I've never had much success with it in the past. But I don't think it really hurts compilation times either, so I guess it's not a loss either way.
Stuff now fails complaining /Ox and /ZI can't be enabled at the same time.
Lowering them to /Zi fixes that, but it's the same as reverting this.
Lowering optimization would also fix it, but it'd make devel slower, which isn't desirable.
Ok, I'll set it up so that Edit and Continue is disabled by default. I don't think it's a very useful feature anyway.

Revision 830

microVU: implemented CLIP instruction + minor changes...

Revision 831

microVU: moved stuff around, and implemented some other stuff... also added the
file microVU_Analyze.inl to project.

Revision 832

Linux: Fix up console logging so it both doesn't insert newlines every time the
color is changed, and doesn't log the color change codes in logs, as unless you
are using a console based text editor, it's harder to read.

Revision 833

Linux: All right, this will have to be fixed properly at some point, but hack in
a printf so that Linux users can at least see the exact exception games crash on
if they crash (Though it won't get logged at the moment).
And, yes, there's a reason why I'm not using 'Console::Whatever' here.
And I have tried to catch the exceptions; I'm just having no luck with it.
Chances are if the esp or ebp registers aren't holding the right info (and I think we use one or both int he current recs, which is bad) then the exception stack unwind could fail depending on how the compiler implements SEH exceptions. The current recs fail to preserve either of those registers. Someday that will be resolved I hope. :/
In any case, my idea for SEH exceptions for instruction-perfect error handling from the recs won't work in its current form. I neglected the impact of register alloc and const reg flushing, meaning that when an exception is thrown, the register state in cpuRegs is not current. There are two ways to go about fixing that, but neither is especially neat or easy.
Sounds messy.
The printf statement I put in will work for now, I suppose. I noticed it because I was looking closer into why Star Ocean's unplayable on Linux.
The last warning before crashing was:
terminate called after throwing an instance of 'R5900Exception::TLBMiss'
and was never displaying:
(EE) Tlb Miss, addr=0x33eb3434 [load]Aborted
Which it should have been. Of course, one could argue that it shouldn't be displaying that either, but at least it's more informative... :)

Revision 834

- more thorough blur detection
- makesnapshot delayed until the next vsync (so shift+f8 won't crash randomly)
- fixed " Issue 38 : Bad performance with Xpad"
wow it auto-linked the bug report page :D
Yeah, that's one of the cool things google code does for you. It links to issues and revisions.
Though it doesn't check to make sure the link actually works. It will quite happily link to invalid revision numbers, in my experiance.
Thanks a lot again for the nice fixes gabest.
Does this changes only for SW? Thanks anyway
God of war blur is gone now :)
Would hbe great if God of war 2 green screen be gone too :)
Nice job.
the revison number is still 826.
and what's the difference between 826 and 826m ?
m means there may be changes to that revision not checked in yet
I re download the gsdx code and compile again, the m seems related thread safe opitimize (some scene increase 10fps).
and the revision number is cerrect :P
The white fog in GOW is fixed ??!?! Wow ! Great job! If you fix the green screen in Gow2 you're a GOD! Thanks Gabest !
Its not the white fog that is fixed. The game is just less blurry. (It look sharper.)
Will try with Gran Turismo 4, for some reason in previous revs the higher the internal res, the blurrier the game became, i'll try this rev tonite.

Revision 835

- Various fixes to MMI and more changes to opcodes to mimic ps2 behavior, thanks
to Nneeve.
- Brought back a gamefix for Persona games. They still have missing geometry
without it (VU clip flag problem)

Revision 836

microVU: backing up current code, going to have to rethink some things :/
looking for the best solution, don't implement it so quick temper
Look for worst solution, implement it with a quick temper.

Revision 837

wxNewGui: Cleanups of the Logging dialog layout (yet unfinished).. added some
helper functions for common dialog layout stuff. Still learning my way around
wx. :/

Revision 838

LilyPad: Loading savestates made with other pad plugins should work a bit
Attempt to fix keyboard input sometimes not working until window is
unfocused/refocused. Happened to me once (And only once), when I was
experimenting with disabling read input in GS thread. There are a number of
potential causes of this, and I've added workarounds for several of them.
Slightly updated code to determine when to update pad state - added both a
timer, so read state less when fast forwarding, and Multitap support (to that
particular chunk of code).
Just to be completely clear, Multitap is not yet actually working. Change refers to the particular chunk of code that determines when to read the state of controls, which now works with my extra Multitap stuff, which isn't fully hooked up yet. This just prevents me from reading the state of all controllers each time the state of any of the 4 multitap pads is read, when reading pad state in GS thread is disabled (When it's enabled, there's no problem, even with the old code).
"Attempt to fix keyboard input sometimes not working until window is
Oh, at last :P

Revision 839

LilyPad: Fixed logging bug, log slightly more data.

Revision 840

GSdx: disabled blurring can be re-enabled in the settings or with the END key,
the image shifting is corrected back to 1 pixel even if the internal rendering
resolution is upscaled.
is possible to implement something like postprocessing on-off with a key ingame?
It's disabled because it does not work, not because slow :P
:) i didn't say it was for slowness.
beacuse of some games works better without but we have to manually find them and tell the CRC to you.
it was a curiosity to know if it is tecnically possible.
I've just noticed that DirectX March 2009 is out...
<a href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=24a541d6-0486-4453-8641-1eee9e21b282">DirectX SDK</a>
<a href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=0cf368e5-5ce1-4032-a207-c693d210f616">DirectX Runtimes</a>
Oups, I thought it can handle HTML... Sorry...
cool, let's see what's new in dx11
Well, if there is no crc added yet then there is no drawing skipped, you won't miss the garbage appearing on screen.
I think only one thing will interest you - COMPUTE SHADER!!! Yeah!!!
Can't wait when it will happen... I'll buy new PC when DX11 hardware will be available for reasonable price...
Compute shaders should run on dx10 cards with limited blocks or something, but november's sdk was a bit unfinished to try even with the reference rasterizer, documentation was sparse too.
I don't understand what's up with GT4's car selection, it looks better in native res than 2048x2048 (looks uber blurry).
Looks awesome in 4096x4096 tho :P.

Revision 841

GSdx: persona 4 character shadow error fixed, might break other things (hope it
doesn't :P)
This is great.. One of the more annoying bugs down :)
is "shadow error " mean those rainbow floor texture?
nice work :)
Wow! I thought this would never be fixed :P
You are te best, thank you!!!.
PD: I do not want to be thankless, but you can watch the ICO error in Hardware? Thanks
This is great Gabest. Thanks a lot for improving the hardware part of GSdx again. Just wanna report a tiny bug. The shadows under the characters in Dragon Quest 8 are missing. No big deal. Anyway, just reporting, nevermind. Thanks man.
Looks like that last post of mine about the rainbow floor caught your eye? :D Excelent work!
Persona 3 had the same floor issue and it's gone now too!
i was waiting for the day the persona 3 rainbow floor bug would be fixed :D
great fix, now I can play persona 3 without any problems :) Thanks gabest.
it doesn't happen anymore but i am getting missing floor textures on Persona 3 FES, software or hardware doesn't matter dx9 or dx10 ether.
P3FES here works like a charm (but still,noticeably better in DX10 over DX9! dx9 cuts off some textures a bit like the old gsdx in dx9 did too) with no "missing floor",latest pcsx2 build.I tried it all over town and tartarus,I'm guessing SPS?There is a gamefix for it but I didn't encounter any in P3FES even when it's off,only in P4.
Found the problem it needs the VU Clip Hack the same for God of War.
Dunno if its this revision, but the annoying ghosting in digital devil saga is fixed :)

Revision 842

Linux: A little bit of catchup with Windows; Add the VU Clip hack back in for

Revision 843

Replaced more SysPrintf's with Console:: functions then I want to think about. A
few minor changes in passing, mainly format-related.

Revision 844

Since WriteLn is used for logging, and it automatically appends newlines, remove
a bunch of legacy newlines from various logging functions.
It doesnt automatically append new lines, ive just got a big mash of text now, it might do in linux but it doesnt in windows.
Ow, yeah. This really messed up logs ><
nvm fixed it :p
I hate Windows/Linux differences. :(

Revision 845

LilyPad: PADfreeze() now saves state of current poll, just in case it hasn't
been completed. In practice, state never seems to be saved in the middle of a
poll, but best to be safe.
Note that this "breaks" old LilyPad savestates, but that just means you'll need
to wait for your pad to be initialized before loading older states for picky
games, like you do when using states saved with other pad plugins.

Revision 846

Added a new CheckedStaticBox panel, which is something I like to use a lot
(semi-working test use in frmLogging).

Revision 847

Included Nneeve's recent fixes to DIV / DIVU instructions, regarding MIPS
specific behavior in div by 0and div by -1 scenarios.
Added a preliminary codebase for new IOP memory system (not anywhere near
finished, but my laptop is failing and I don't want to risk losing it before I
get home).
forgot to mark my last 2 commits as branches, sorry. :/
hm the Harddrive is dying? this is indeed bad.

Revision 848

- Nneeve fixed the Tri-Ace gamefix so Gradius5 doesn't crash with it enabled
- Moved one global variable for the VU interpreters, which surprisingly speeds
up Star Ocean 3 for me.
- Set Flush to Zero for FPU and VU back to on. Let's see how long it lasts this
time :p
- Removed the FFX hack from pcsx2! It's still toggled in the GS plugins, the
correct behaviour is having it always on.
Oh, and most likely fixed a few bugs concerning the cop2 or vu interpreters by reverting a strange hack :p
"- Moved one global variable for the VU interpreters, which surprisingly speeds up Star Ocean 3 for me."
Hm... how much? I don't have speedup at all.
85 to 87fps here.
Given the nature of the code change, I'd mark it as random :p
That's like 2.3% increase, so yea don't expect to see a difference unless you do very accurate comparisions while checking the fps meter closely. :p
I suppose I should probably set ZeroGS to default to the Final Fantasy Hack being on rather then off now...
Yeah, please do so :)
All right.
I'll take care of that once I figure out the best way to do so. I'm just not sure if I should turn it on by default and allow the user to turn it off, turn the current hack into a "Disable FFX hack" option, or just remove it...
Bets to completely remove it.
We determined that what the hack does is correct gs behavior.
Sounds good. Guess I'll take care of that tomorrow, then. (Tomorrow probably still being Saturday, just Saturday after I've gotten some sleep).
Then it'll just be up to Gabest to remove it from GSDX, and Zeydlitz to remove it from ZZogl...

Revision 849

Fix the vu interpreter thing again. This should be right now (according to
cotton, blame him if its not!) :p

Revision 850

General cleanup in Gif.cpp && IPU.cpp. Did a bit of refactoring in Gif.cpp.
Moved the path3hack to patches.
Always irritating when you notice typos in your comments after committing. Guess I'll get those next commit.
Great stuff, arcum. Hope you find the time and will to take care of SIF and maybe even VIF, too! ;)
Thanks. I had several projects going, and I didn't really feel like working on any of them.
So I decided to polish some code instead...
I may look at Sif and Vif at some point. I was also looking at Cache.cpp, and realizing that all the code in it is dead, broken code. Most of Decode_XA is unused, too. In fact, all that's used is one structure in the header... :)
Oh, and if the IPU changes seem fairly minor, I managed to break the Atelier Iris 1 opening the first time on my local copy, reverted it, and redid some of the changes. :)
I'll probably be returning to it at some point.
Oh my. Just noticed. You know you've been coding too much when you use && instead of & in your sentences. ^_^
LOL, I also didnt notice :D
Freaks. :D

Revision 851

LilyPad: Fixed bug detecting enabled multitap pads. Multitap support now seems
to be working on the LilyPad side of things now. At least it seems to work with
the one game I've tested, after modifying PCSX2. Necessary PCSX2 changes have
*not* been committed.
Still need to hook it up to the PCSX2 GUI and figure out how to say the extra
memcard slots are all empty.

Revision 852

ZeroGS OpenGL/Linux: Took out the FFX hack, and turned it on by default. Removed
a few options that weren't doing anything, and added a few into the Linux list
that were missing.
I might do the same for the DirectX version at some point, and the Windows gui of the OpenGL port. I'm just not as familiar with either...
Would have committed some cleanup work on Sif and Vif, but:
a) I broke old savestates. (mainly because I turned some ints to bools that clearly should have been bools.)
b) I broke the background on FFX's opening. It looks like it was done by Gust. ^_^
aren't there some games wich tend to crash when the FFX Hack is forced on?

Revision 853

LilyPad, Plugin APIs: Slightly changed how multitap API additions work. Now
enabling is handled completely by the pad plugin. If anyone ever really feels
like adding support for more memcards, can move it over to PCSX2 itself.
Also add some documentation to PadApi.h.

Revision 854

Pcsx2: Added experimental mtap support, must be enabled through pad plugin.
Fixed bug in default PADfreeze function that would fail to load states created
with LilyPad when using other pad plugins. Added support for disconnected pads
(Mostly a convenience for mtap support, for games that use pad presence to
assign pads to players).
PADfreeze bug would affect loading any state made with a pad plugin supporting PADfreeze and trying to load it with a pad plugin that didn't. LilyPad's just the only plugin that currently support it.
Also, I updated the SaveState format, but save states should be backwards compatible.

Revision 855

LilyPad: One more quick bug fix in mtap stuff.

Revision 856

Forgot to remove a couple debug lines.

Revision 857

More work on Gif.cpp & IPU.cpp. Got fed up with straightening IPU.cpp up by
hand, so I ran Artistic Style on it, and then strightened the results out.
For anyone who doesn't know what I'm talking about, Artistic Style is a little code reformatter I use occassionally:
Since we have several programmers with several different coding styles, I don't use it that often, but it can be very useful on occassion.
I keep it with fairly minimal settings:
Oh, and I actually did pull a few pieces of code out into new functions in IPU.cpp, to get rid of some redundant code, incidentally...
3>HwWrite.obj : error LNK2001: unresolved external symbol "void __cdecl dmaIPU0(void)" ([email protected]@YAXXZ)
3>HwWrite.obj : error LNK2001: unresolved external symbol "void __cdecl dmaIPU1(void)" ([email protected]@YAXXZ)
3>D:\EMULATION\EMULATORS\PS2\SRC\\bin\\pcsx2.exe : fatal error LNK1120: 2 unresolved externals
Let me take a look...
The 2 have to be declared "extern" in ipu.h ;)
Got it; I'll be committing shortly.
Yeah; I didn't notice because gcc didn't care about it...
Btw, I kinda like this tool. Seems we could use it on a lot of files in pcsx2.
(SPR, Vif, VifDma come to mind :p )
I'd love to use it on a bunch of the files, honestly. I've already used it on a few plugins in the past. (CDVDiso and ZeroSPU2, possibly others.)
Always scan over the code afterwords, though. It'll ruin ascii art, for one. And I seem to recall some of the complex defines being messed up before I figured out the settings I wanted.
It'd be a good idea to use it on some of the really badly formatted files. (The ones you mentioned *are* some of the main ones that come to mind.)
Credit where credits due; this tool was pointed out to me in the comments on one of my revisions in pcsx2-playground...
uh, much edits on the IPU.
are there noticable Changes? :x
No, shouldn't be. Except it looks better now ;)

Revision 858

Add dmaIPU0 & dmaIPU1 externs. :(

Revision 859

LilyPad: Fixed a binding bug due to old debug code still hanging around, added
ability to swap pad bindings (Right-click context menu).
Сколько можно...
Сколько нужно.
DantePinky все что не делается все к лучшему
When will make vibration?
It is necessary to sit on sssspsx 1.6.0...
как то так
Huh? Vibration has been supported and working since at least 0.8.4.
English only. k thx.
Vibration is working, both motors even (as opposed to ssspsx which only drives one motor).
Vibration? It's not work on my gamepad (made in China)
I don't particularly care if it doesn't work for your controller. You either haven't configured vibration, which is hardly my fault, or your controller adheres to no open spec (In other words, it's buggy), and I can't be expected to get it working.
But,it's work with SSSPSX 1.6.0! I even get it vibrating without any complex Configuration.
My code adheres to DirectInput spec. Blame either your hardware vendor or Microsoft for your hardware or its drivers not adhering to spec. Code is open source, so if you have any doubts about that, feel free to take a looksee. I can't fix problems with buggy hardware that I don't possess myself.
I get it vibrating after going through your $%#%^&@! configuration.
WTH,why does it have to be so complicated?
And one thing: The FF Effect much too long than SSSPSX,and it's one thing which's not real.
Ex: In GOW,when I use combo with the final strike,SSSPSX make a soft and quick vib,but your little Lily make it a whole second.
Anyway,perhaps i don't config it properly?
Because I believe in working with every device out there. SSSPSX only works with devices that behaving in a certain manner. Some devices don't like forces with more than one dimension on them, some don't like forces with a bunch of dimensions. Some devices only trigger certain motors with periodic forces, others adhere to spec and trigger motors based on which motors you actually tell them to trigger. My code should work with all of them, rather than just those that behave as I hope they will. Regardless, it only takes a minute to configure, for most devices.
I vibrate until I receive a signal not to, while SSSPSX vibrates for 10 milliseconds and then stops. If GOW doesn't tell me to stop vibrating, I don't.

Revision 860

miscellaneous microVU changes...

Revision 861

microVU: some lower opcode changes...

Revision 862

More cleanup. Ran Artistic Vision on a few of the files rama had suggested, and
did a few changes that make things easier to read. Still more work to be done

Revision 863

removed an incompatible option from devel builds (it refuses to build),
presumably whoever changed it wanted the debug option on, so ive removed the

Revision 864

Fixed issue with DBZ Tenchaichi 2 not booting, also fixed line endings for the
logging to file, man that was hard to read!

Revision 865

Set zlib to use fast compression for savestate (big speedup for when making
Disabled Edit and Continue and re-enabled optimizations in devel mode (thought I
disabled Edit and Continue earlier, but I guess it didn't get saved/committed
Save states are much faster now. Thanks a lot.

Revision 866

Fix for crash of the titans, unbroke FF12 in my last commit, fixed a couple of
other things. Now handles DMAs which are enabled while the DMAC is stopped, so
they start when the DMAC is re-enabled. Might need some testing to make sure
stuff isnt broke :p
I guess it will break something :P
probably :p

Revision 867

Fix for Crash N Burn
Whoa, Refraction is on a Rampage ! Go, go ! Fix everything you come across man :D
Next commit, everything works! :D
i wish lol
keep on, everything will perfect.
How to download these DLLs? i can't find it
next WTH are you talking about? XD
nice going refraction *cheer*
i mean how can i download this updated emulator? cause in the official website i found only the release of march the 1st
you can get it from the official forums

Revision 868

GSdx: just increasing the revision number of gsdx to test something...
doesn't look like "just" rev# raising XD
strange way of "just" increasing revision :)
Gabest,just let you know,this reversion crash when I hit Esc,it didn't happen in R841
Replaced individual pointers to the privileged registers with a large struct, so the compiler only has to care about one pointer now, but I did not notice any problem with it.

Revision 869

wxGui branch: More improvements to CheckedStaticBox. It's mostly complete now,
and I'll likely move on to implementing some new dialog boxes now.
Will this new UI be used in all platforms?
If I remember correctly that is the very reason why they began to implement new gui in the first place.
Someone correct me if I'm wrong.

Revision 870

LilyPad: Fixed a bug in list of bindings when go to config screen after running
Pcsx2 for a bit, and some devices enabled on the config screen were not enabled
in game (Either due to focus issues, or, more probably, due to mouse API not
being disabled, but not running with mouse focus).
Also bug fix for cursor clipping rectangle not being reset after window resize.

Revision 871

I don't think we really need someone's random Thumbs.db file on the SVN.
Not really worth its own commit, but Thumbs.db files spewed everywhere just annoys me.

Revision 872

Increased the MTGS ringbuffer from 2 to 8mb. Fixes slowness in games with lots
of data moving.
(Xenosaga series for example)
Thanx rama, this sounds very promising. I have a feeling (wishfull thinking?)it will affect many other games with slowness probs.
Depending on how much difference this makes, might be interesting to have this adjustable in one of the dialogs...
great ^^ but now i'm curious why don't we set all buffers a notch higher? is it because memory bandwith?
whats the impact on overall performance by doing that?
Mostly it just benefits games which make frequent use of large texture uploads, since those large uploads were previously 33-50% th size of the mtgs buffer and caused the MTGS to stall to the point of nearly being single-threaded in nature.
The buffer was supposed to be 4MB but it was bugged and set to 2MB instead. 8MB yields a very small benefit over 4MB on a select few games such as XS.
Does this improve the slow mech scenes in XS2?
Nope, the mech scene slowness is a GSdx problem.
I'm going to test this when I get home tonight. Quick question though (since I'm an impatient ass :D ). Is Breath of Fire V one such game that'll be affected by this?
BoF 5 is slow because of one function in GSdx thats not optimized.
Doing a profile guided build of gsdx using this game fixes it.
Nice work!Does it Fix Tales of Legendia Slowness or is it gsdx bug too?
Gabest, I've sent you on the forums the modded function by chickenliver, if you want to take a look at it. I think it would be worth it.
OMG. Thanks very much, Jake! I tested Xenosaga with my usual setup and noted an amazing increase in performance with my poor E2180 @ 2.8GHz. Xenosaga is one of my few and favorite ps2 games. Again, thanks very much :)
Sorry, I said Jake :P I meant ramapcsx2. I was reading the changelogs and got confused when writing this. Anyway, sorry rama for the mistake. And Thanks very much again and again =)

Revision 873

GSdx: updated the delay loaded directx dlls to match the latest sdk
any real difference using older directx versions? because i have a modde dx10 on XP but it is stuck at rev "39".
It will search for the dll version it was compiled with, but I don't think dx10 would work on xp anyway.
There are modded 'hacks' of DX10 available that do work on XP, so long as you have a DX10 compliant video card. They get updated later tho, since obviously they're not a microsoft thing.

Revision 874

A few tweaks to more often called functions = general speedup :)
How much more fps?
Ghe, test it, will ya? :p
Its not much, but its there..
When rama talks about speedups he means like 85 -> 87 FPS. j/k :p
Even 1 fps is significant. Little by little folks and even an atom cpu will be able to play at normal speeds all the games. J/K
Exactly, and that in every game. For free.
Add that to the 20 other small speedups and see where you are then ;)
Nope the speedup really is here, i get about 5-12 fps+ in MGS3 and about 3-6+ in God of War, didn't tested my other games yet, anyway thanks Rama

Revision 875

wxGui Branch: Added some console logging code (not yet finished). Can't really
use wxWidgets built in version because it's not extensible (grr).

Revision 876

wxGui branch: Merged with trunk (2 weeks of changes!)

Revision 877

Shortcut for intc_stat reads. Speeds up games that use it a lot.
85-87? :P
Thanks for all those tweaks Rama. I come along observing Pcsx2 for a long time, I know that those little improvements makes a great difference in the end. An 1 Fps gain tweak is worth gold xD

Revision 878

<cotton>for april fools i can put on my next commit that microVU is finished and
doubles fps
<cotton>but i guess i shouldn't do that on the svn :D
<cotton>or maybe i can >.> <.< >.>
:) imagine that!
Hehehe !
oh, it fix the green screen issue for GoW2. :D
is the green screen problem is solved, but GoW2 PAL version at the end of the mission (the cavern hand) the game freezes on the movies and does not go ahead .... sorry my English

Revision 879

Still messing with Sif, Vif, and SPR.
VS2008 compile error - Sifcmd.h(61) : error C4430
1>d:\emulation\emulators\ps2\src\pcsx2\Sifcmd.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>d:\emulation\emulators\ps2\src\pcsx2\Sifcmd.h(61) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
line 61 : u32value; -> u32 value;
Already noticed. I'm just in awe that that compiled and ran in Linux. And even emulated several games properly.
It'll be fixed in a moment.

Revision 880

How that compiled with a space missing, I may never know...
I really have to assume value isn't used for much. :)
I think declaring stuff like that in C/C++ defaults to int, if I remeber
Right, but anything trying to access "value" should have errored out. Unless it's unused, anyways...

Revision 881

wxGui branch: major progress on many fronts!
* Added new files AppConfig.cpp and StringUtils.cpp, and removed memzero.h
(we'll use the win/linux platform dependent implementations)
* Enabled wxWidgets memory tracing since we don't use a memory trace util of
our own.
* Switched many instances of std::string to wxString.
* Added preliminary support for configuration settings and ini file creation.
* Added a set of parsing and splitting tools to StringUtils.
* Set it up so that the Console log is attachable to the main window, when
dragging (fun!)
* Main window and console log window record and restore window positions
between runs (only partially implemented yet)

Revision 882

wxGui branch: Moved and renamed some files and classes. I'm quite a bit more
fond of the C# / Java naming schemes for forms and dialogs over the wxGlade
frm/dlg prefixes. Namespaced all dialogs into Dialogs::. (all two of them at
this point, but many more will come! .. someday)
..\WinMain.cpp(84) : error C2143: syntax error : missing ';' before '*'
..\WinMain.cpp(84) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
..\WinMain.cpp(85) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
..\WinMain.cpp(86) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(87) : error C2146: syntax error : missing ';' before identifier '_argv'
..\WinMain.cpp(87) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(100) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(100) : error C2059: syntax error : ')'
..\WinMain.cpp(103) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(103) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(103) : error C2064: term does not evaluate to a function taking 1 arguments
..\WinMain.cpp(106) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(106) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(118) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(127) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(127) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(137) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(146) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(146) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(149) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(157) : error C2065: '_argv' : undeclared identifier
..\WinMain.cpp(158) : error C2065: 'argv' : undeclared identifier
..\WinMain.cpp(161) : error C2065: 'argv' : undeclared identifier
Error log. :(
compile the debug version not the release config
Yeah I hadn't even bothered to test compilation of release builds on that branch yet. Noit much point after all -- it doesn't actually run anything yet. :)

Revision 883

Implemented some more vtlb optimizations: Regalloc should be working a bit
better now, and removed some unneeded code on the LWL/SDL/etc interpreter
Emitter: Added Rm/RmOffset forms for AND32 - Untested. I'm pretty sure they're
valid instructions but I could be wrong.

Revision 884

More vtlb optimizations: Switched over to full const resolution of the TLB, and
added a shortcut for the INTC_STAT register (replacing the one rama added to
HwRead.cpp a couple days ago).

Revision 885

Final pass of today's vtlb optimizations: Improved the codegen for const-
propagated direct reads and writes (very minor optimization).
Optimisations are almost always good...
Can someone tell me is making PGO build for my most played game worth doing?.. It seems that there's almost no perfomance boost... Maybe I'm doing something wrong, I have no experience with that... Tried to make PGO build for pcsx2 and gsdx for Final Fantasy X...
The general speed increase is 1-2%. Sometimes it's more, sometimes it's less.
A very few games benefit more, especially in case of gsdx (but then again, gsdx has other problems when doing PGO...)
AT any rate, all our betas of the pcsx2 exe already have PGO, you could just use those...
Yeah, don't expect pgo to speed up your casual games (especially ffx).
It helps on many other areas of emulation, but not so much with games fps.
Optimizations are always a good thing no matter how small they are. Today's slew of updates makes me very happy.
With rama's advice, I did a PGO build of Gsdx and PCSX2 on BOF V. After an agonizing profile session, the speedup was well worth it.
Good job.
Don't work too hard.
I found only one noticeable improvement in FFX after building PGO build: When you're on a savestate selection screen, moving between save states and some other menu items is much more responsive...
To krakatos: What do you mean saying "all our betas of the pcsx2 exe already have PGO"?.. I thought PGO is game specific somehow...
whats PGO?
PGO Profile Guided Optimization
eliofur, that's not exactly correct. Not for a program as complex as pcsx2. Well, you can do that but it's not really worth it. What IS worth is doing PGO on a good pool of "cases"
Read here for a more detailed explanation

Revision 886

T/D flag interrupting was missing on the VUs.
Nneeve implemented it :)

Revision 887

GSdx: the BoF5 speed fix
Thanks a lot :)
*eagerly awaits GT4 fix*
Gabest,it's a fix for god of war 2
Now there is no green background, there was a sphere of visibility and the condensed fog
Can to you it will be possible to continue idea
Author - ZEROx
Как смог так и перевел,не обессудьте)
cannot download it, I'm not registered there
thank you gabest.works fine!
do you happen to know what causes the Tales of Legendia slowness (i think it's gsdx hardware mode based as software mode works much quicker (but not playable)))Thank you (sorry that i ask you this question via comments)
X-pad doesn't want to builds:
Error 7 error C3861: 'XInputEnable': identifier not found d:\Dev\Emu\PCSX2\plugins\xpad\xpad.cpp 666
Error 8 error C3861: 'XInputEnable': identifier not found d:\Dev\Emu\PCSX2\plugins\xpad\xpad.cpp 694
To zantezuken:
Apparently VS2008 installs part of the windows platform sdk v6.0A. The bad thing about this is that it includes a XInput version from september 2007, which doesn't include some features. And even if you add the DX SDK lib and include directories, VS2008 still prefers the files in the windows SDK for some reason.
SO, long story short; you need to install the latest windows platform SDK. Here it is, in .exe or web install form: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdc

Revision 888

Oh well, a problem with the T/D flag code made the bios screw up.
Since it can't be fixed without further code in superVU, full revert for now :/

Revision 889

Fixed a bug from an earlier vtlb commit that caused some slowdown when INTC_HACK
was disabled. Turns out games spinning on INTC_STAT don't do it in a way that
allows the recompiler to propagate consts.
Btw, 32 bit resolution is also unneeded option -- it appeat in sources, but really does not do anything.
Oops. Sorry, miss a revision to comment :-(.

Revision 890

wxGui branch: Fixed Release build errors, removed WinMain.cpp and Remote
Debugger stuff from the build project (slowly but surely eliminating
dependencies on old code!!), and added AboutBoxDialog files, which I plan to
work on next. (gotta have an about box!)

Revision 891

Fiddle with ProcessFKeys a bit, and hack in a key to turn logging on and
Dev note: The extra modifier keys I put in that new struct should work, but haven't been tested much.
Also, some function keys are used with modifiers by the system. alt or control with F9-F12 have conflicts in Linux, at least under XFCE, for example.
Release Build Compile Error.
..\..\SourceLog.cpp : error C2065: 'enableLogging'
Yeah, only checked the dev build, mainly because I was testing both Windows and Linux, and it slipped through the cracks. Easily fixed.

Revision 892

Patch r891 so the release build builds.

Revision 893

Multitap should now work in BIOS (Oops).

Revision 894

wxGui branch: Finished the About Box!
oops, this is a partial commit which does NOT compile.
I'll have a compiling commit soon.

Revision 895

fixed 1-cycle branch delays
fixed an issue with FDIV instructions whose operands are vf00
fixed recompilation of SRA and SRL when shift amount is 0
fixed conditional recompilation #defines a bit
(as an aside, this fixes a crash in Ratchet and Clank, but the game has other
I glad that now you're officially in the team :P
I doubt PCSX2's ever had this many active coders, even after all these years it's still going stronger than ever. That's really nice to see.
Sweeet! One more talented developer.
Welcome Nneeve!
Thanks for your good work.
Finally, you are here!

Revision 896

Fixed devel building again, assumably as jake turned the optimizations back on
that he didnt want them off.
Devel builds *should* work fine with debug information format 1 (which is a program database without edit and continue). I did a clean rebuild of devel and ran into no errors. What errors are you getting?
it was saying /Ox and /ZI are incompatible and refused to build with them on, so i turned /ZI off completely, then moaned it needed /Zi or /ZI for minimal rebuild, but the updated one puts /Zi on, its happy with that :p

Revision 897

went a bit mental lol :P
Yeah I assume a full rebuild fixed the problem on your end. :)
Whenever core target settings change it's a good idea to full rebuild (debug formats, rebuild types, linking types, etc). Usually not needed for basic project changes tho, like adding/removing files (although sometimes with incremental link enabled, removal of files from a project also requires a clean rebuild).
well VC was whining about the options :P initially it wouldnt build, so i removed the option it was complaining about, but it wanted it for minimal rebuild, just at a lower setting lol

Revision 898

Further fix for crash n burn (videos were invisible) hopefully fixes ATV too,
but i dont have it to test.

Revision 899

wxGui branch: Added the About box, and embedded images/icons into the exe.
Since images are embedded now, I moved them from the /bin folder to the
/pcsx2/resources folder.

Revision 900

Reworked the unpacking code in Vif.cpp.
I get a few warnings here:
1>..\..\Vif.cpp(435) : warning C4390: ';' : empty controlled statement found; is this the intent?
1>..\..\Vif.cpp(436) : warning C4390: ';' : empty controlled statement found; is this the intent?
I see it. That's the trouble with lots of copying and pasting. Fixed in r902.
Happy 900th commit in either case :)
That was definately needed, however the code is rarely used due to the SSE version being forced on. Can sometimes be good for debugging tho :P
This commit breaks Ape Escape 3.
SuperVUGetProgram is called with a startpc of 0xffff9e60
You tried revision 902, right? I missed two size--; in this revision that I put in there.
Yes, forgot to mention, game is still broken in r911.
Well, noticed one issue so far.
Several of the unpack functions move the data into a function of a different type before passing it to UNPACK_PART_, which assumes it's a u32.
I just changed that function to a template. Still getting the same issue, but I may be closer...
OTOH, it's passing to a function that looks for a u32 anyways, so that may not be the issue...
Looks like it's due to the change in where size is decreased. Makes very little sense to me, since as far as I can tell, the only operation being done after it is _vifRegs->offset++; , but who knows with these things.
I'd made enough changes by the point I spotted that one that it immediately went to the start screen, with no one running towards the screen, so I have to figure out what behavior I changed while doing that...
Fixed the friggin' thing by changing two pieces of preexisting code that looked wrong (That I hadn't modified in this revision). I have no idea why this worked previous to this revision.
I'm going to do a few tests before committing, and clean up the changes I've made.
See r912.
Interesting: r900 to r911 (inclusive) had the loading screen of outlaw tennis fixed, before r900 and in r912 and up - the screen has one of the loading box's corners in a different place.

Revision 901

wxGui branch: Removed some win32 platform-specific code in main.cpp.
The default paths thing is confusing. I know it's doing what I want it to for Win32, but it's unclear to me what the expected behavior for linux should be, and if it would be achieved with something #ifdef-free. Maybe GetDocumentsDir()/GetAppName() is ok on linux also?
Well, GetDocumentsDir looks like it returns the home directory, so that would probably work. I was going to suggest using GetAppDocumentsDir instead, but the fact that it returns GetDocumentsDir if the app directory doesn't exist could cause issues...
GetAppDocumentsDir returns a location on Win32 which is hidden and mostly unreachable without jumping through a lot of hoops, so it doesn't "fly" too well for things like savestates, screenshots, or memcards (but could be passable for ini files, except at the point we have everything else saved in the User Documents, might as well save the inis there also). So GetDocumentsDir is a must on Win32.
Ideally I'd like to have it optionable to use either the user documents folder (GetDocumentsDir), or act as currently and use the pcsx2 working directory -- since that's potentially convenient for testing purposes. Although really the only thing that needs to vary from sandbox to sandbox is the ini file portion (which in turn can direct pcsx2 to different memcards, plugins dirs, etc). So the question then is when to decide to load/save ini's to the pcsx2 working dir, or load/save them from the user documents dir. (perhaps that could be a function of Release vs. Devel/Debug builds? Dunno)
Also, for the record, wxWidgets places the "global" ini file in c:\windows\, which is total fail as far as I'm concerned. I'm not interested in having local and global ini settings anyway. Local only is all we need.
I'd like to have that option, too, especially since I've had requests for it on the Linux side.
I think it'd be better to have it be switchable in the program. The only trouble is figuring out how to have the program remember which setting to use. (Can't put it in the ini file, after all.)
Hmm, that might be doable actually.
The trouble with Win32 side is that the /program files folder is write-protected on Vista nowdays, so Pcsx2 needs admin access to run, and then it runs through some virtualized filesystem that grants write access to that one program only. So in order to save .ini files into /program files Pcsx2 has to be run as admin.
However, if Pcsx2 is run from outside /program files, then presumably it works, and an advanced user could then enable the alternative ini file option (which would save the ini to the program;'s working folder).
As for loading, Pcsx2 would attempt to open the .ini file in it's working folder first, and if missing or empty, fall back on the one in the Documents folder. That way, when you enable the 'working dir ini' option, it creates the ini in the working dir, and will then opt to use it from then on. :)
To clarify my incoherence: the virtualized filesystem in Vista is slow, which is why it's nice to avoid it, even if granting admin access to Pcsx2 is otherwise fairly easy. That's the primary motive for the new wxWidgets branch using /My Documents as the home folder.
(and granted it *does* make more sense from a sysadmin standpoint, since program installations and data files are always safer having a degree of separation -- makes running backups and reinstalling apps easier and safer, etc).
That and it also means that different users can have different preferences, which is a bonus.
I like doing it as a fallback, though. And the preference takes care of the remaining issue of people not knowing where their preferences went to an extent.
Other things on the new gui:
a) Should the frame limit settings actually be in the Cpu dialog, should we reshuffle things?
b) What do you think about managing the savestates through a dialog box instead of the current menus? Seems to me that we could get a bit more flexability that way...
On a), that should be "*or* should we reshuffle things?". Like having one central preferences dialog, moving it to adavanced, giving it it's own dialog box, etc...
On a) I've already alloted a menu option under "Video" for it. The Video menu will have a section of Pcsx2-side options (MTGS / Frameskip) and then whatever the GS plugin programs into it through the future plugin API for adding menu items to the gui. :)
On b) I'm kind of impartial since I don't really use the menu option much. Although a dialog does sound nicer, since it could, for example, sort the savestates by timestamp for the user (which would be useful indeed).
Well, as plugin api changes, remember, the future is now. Feel free to make whatever changes you want to the new api files in common (common/include/Pcsx2*.h, PluginCallbacks.h, and the api folder). ChickenLiver's already made a bunch of changes to the plugin api.
Reminds me; if we're going to do anything with Pcsx2 sending iso file names to the cdrom plugin to load, we should put the hooks in now...
As far as the dialog goes, I was thinking ability to delete saveslots, copy them to other slots, import them from external files, export them, and assign labels to the save slots.
Timestamps is a good idea. And if we were feeling really ambitious, send a snapshot message to the GS plugin if saved from the keyboard, and give thumbnail images of the screen.

Revision 902

Fix typo in r900.

Revision 903

- removed some obsolete 'iCWstate' code.
- implemented more rec first pass stuff for the lower instructions.
this change log is so simple.....
Cottonvibes commit legacy grows! He has uncovered the profoundness of simplicity in his latest commit log!
If you ask me, the last two comments were way too simple. If you're going to make completely pointless comments, at least use complex sentences!

Revision 904

Assorted cleanup. A few compilation errors went away, a few useless variables
are gone, a few if statements are now case statements. Added comments on a few
potential problem areas.
Well this is going to be a fun one to merge with the wxGui branch. ;)
(the swath-like changes to misc.cpp will conflict heavily with the wxString modifications I had to make on the wxGui side -- so likely some of the formatting changes will be lost when I do the merge)
With Main.cpp, it's mainly that I copied back in ProcessFKeys from r891, and changed it just enough to have the changes in r891 work, losing the formatting changes I had made (as well as a bug that had crept in somewhere).
Misc.cpp, I mean.
I'm doing my merge now, and I just realized that Misc.cpp is completely butchered. :/ All the tabs were removed and replaced with spaces, and it was expanded to 8-character tabs. So nothing lines up at all anymore. :(
Also, look at vssprintf.cpp -- A single line change where it added a space to the while loop semicolon (yay?), and then removed the tab and replaced it with spaces. (sigh)
I assume this is that util you mentioned doing these oddball things. In any case I think I'm going to revert Misc.cpp. It's totally fuxored in its current state. :(
Actually, didn't use that utility at all this commit.
The space was just me getting rid of a silly compiler warning. No idea how the tab turned into spaces, though. I normally do the reverse.
With Misc.cpp, the problem is probably that I copied it straight from browsing r891 on the google code website.

Revision 905

wxGui branch: Did some heavy work on the configuration/ini stuff.
Just to check, is wxgui compilable on Windows right now?
Or does it give you lots and lots of errors about wxStrings?
Just curious whether it's just Linux that's broken at the moment...
It works fine here. I removed several files from the Win32 build, though. WinMain.cpp, for example (I moved the Languages part at the bottom to another file temporarily since I still had dependencies on that code). I'll be removing a lot more shortly.
All right.
Just wondering, because on my side, the exception code is refusing to compile unless I wrap every string even remotely related to it in wxT, change c_str()'s to mb_str()'s, and format_string to wxString::Format.
And at that, I still haven't gotten it to compile.
ugh. That doesn't sound too promising.
There are platform inconsistencies in how wxString converts to and from std::string, and we're going to have to resolve the precise behavior in order to come up with a neat solution that satisfies both Windows and Linux/GCC. Clearly on Windows, the conversions are working pretty well (at least to now -- I'm still not to the point where I can enable unicode here). Maybe once I get to that point, the code will compile more consistently.
You know, it occurs to me; I'm using the unicode version. I bet that that's why it's still compiling properly on your side...

Revision 906

Fixed a simple bug from one of arcum42's cleanups.
Cleaned up multitap code a little in both PCSX2 and LilyPad.
Some extra safety checks in LilyPad when loading state.
BaseblockEx.h was checking if id was -1 and then using it directly as an index in a vector. Returned -1 regardless of how things turned out, but still...just not a good idea.
Just to be clear, not meant as a criticism of arcum or his cleanups. Looks like the code could really use it. (And that should be idx, not id).
Yeah, if I'd noticed that the -1 matched the index, I'd have done the parenthesis differently. I wasn't absolutely sure at the time; that's why I left the comment there.
Everything was running properly in the games I checked, but I'm always amazed how much you can break in pcsx2 and still run things.
And no offense taken. Part of why I committed when I did was that I felt that if I kept going with the cleanup, I was sure to break something, and I didn't want to start from scratch when it did. (Which has happened in the past)
And, yeah, cleaning up the code's been an ongoing mission for quite some time of mine, though the Linux port takes priority. I remember doing several cleaning passes back in playground, too, mainly based on compiler warnings...

Revision 907

wxGui branch: Removed several unneeded files from the Win32 builds (removing
them since I can reference them from trunk, and if they're deleted I won't have
to spend time merging possible changes and stuff later).

Revision 908

wxGui branch: Merged with trunk up to r903, and resolved some Win32
compilation/link errors.

Revision 909

wxGui branch: Finished merge, and added a new wxConfig28 project file that
allows the wxCore and wxBase libraries to compile in parallel on multi-core
There always been some annoying glitch on the main window... Some kind of border around logo (image) containing last state of the screen... It doesn't refresh correctly... I didn't tried it on Vista, but on XP it was always there...

Revision 910

Found a small typo in IPU, don't know what videos it will effect, but it could
have potentially stopped them working :P
It was first appeared in r601. No, I seen no troubles around r601.
Using 64 bit accesses for the command bits of most hardware registers is technically invalid (I think there's a couple GS exceptions, and the 128-bit FIFO of course). So chances are the 64 bit IPU writes are never used, or used once by something but in a non-important manner the the PS2 itself might in fact ignore.
That is, that would be an explanation why it didn't appear to break anything. :)
probably the case, but id rather not have the bug there just in case xD

Revision 911

Revered Misc.cpp and vssprintf.cpp from r904. See r904 comments for details.
Also, I removed some options from the .vcproj, but these should have *no effect* -- they were just duplicating defaults assigned by the IncrementalLinking property sheet. I'm trying to keep the projects as dependent on property sheets as possible, since it ensures pcsx2 and most plugins have consistent settings across build targets.

Revision 912

Fix the breakage on Ape Escape 3 from r900. Clean up the unpacking code some
more while I'm at it.
In UNPACK_V2_32, it was passing 0 instead of data for W. I have no idea why, and removing that, and a const that probably shouldn't have been a const did it.
Hopefully this didn't break anything else, but if it did, I'll hunt around in this code again.
I probebly will mess with this code again. After all, if I templated UNPACK_V1 - UNPACK_V5, all those other functions are mostly extraneous...
Sent you code explaining why it did that.
Wonder how accurate it is right now. I was tempted just to revert it back, but I really didn't like leaving those defines there...
For the record, neither not writing a 0(the code in this revision) nor writing a 0 in that function(the code before I reworked it) were correct. It only writes a 0 there at certain times (at the end of a 64 bit block). That's what r916 was about...

Revision 913

Implemented another block lookup method.
Fixed an unused instruction in the emitter.
Yay my awesome emitter contribution! Woe is my copy/paste jobbing!

Revision 914

LilyPad: Fixed "Swap with Pad 1"
Vibrations are not present now
Nothing in this change should affect force feedback. When I added multitap support, did make a change that would destroy old force feedback vibrations, but that was well over a week ago...
Vibration bindings, that is.

Revision 915

microVU: more recompiler first-pass implementation stuff...
Kudos for making consistent updates to this. When do you suppose this will finally go live?
it won't "go live" till krakatos and the rest of the beta testers thoroughly test it and its more compatible than the current vu recs.
but if you're asking when its going to be 'usable', probably in 1~2 months.
it would be sooner if i didn't have school+work+boredom dragging me down :(
also every time i think i'm almost done with it, i realize there's some complex problems that have to be solved/implemented.
its pretty annoying TBH, i'm past the 'fun' part of coding this thing, and its more the 'annoying and hard' part right now...
anyways, i don't want all my work to be in-vain, so that's my motivation for finishing this thing xD
I look forward to testing the finished code :)
If you don't mind my asking, what is the idea behind microVU?
"more compatible than the current vu recs"
I like the explain rather than the change log :P
more compatible and multi thread aware i think
see this...
nice reading, at least now i understand more of the crazy talk in the changelogs

Revision 916

Did some testing on the V3_# unpacks, they do some strange stuff for what goes
in the W vector every 6qw of original data. Also fixed the use of the size
variable so Xmen works again.
Note: Nobody will notice this as SSE unpacks are forced on (for now)
GRADIUS 5 and some other game is broken since rev 912。Anyone can fix it?
i haven't looked at the code in detail, but in this function:
static void _UNPACKpart(u32 offnum, u32 &x, T y, int size)
you removed the ampersand in "int &size"
but later on it does:
so either the 'int &size' was correct before, or the 'size--;' should be omitted (since the variable isn't used again)
Well, I know before what it was doing was checking if size was less then 0 each time, and decreasing it, so that if it ran out of data to unpack, it wouldn't keep unpacking. (though I'm not sure that's actually needed.).
Though that probably should have been <= 0, thinking about it. But that's why it was a reference before. I was basically carrying over what it was doing with size before the rewrite, trying to keep the code as close as possible to the way the defines used to be set up.
So unless that isn't needed, it should be a reference. For that matter, we probably need to set up the SSE Unpacking functions to handle W properly on V3 now, too...
the problem was, because it was a pointer to the size variable (rather than passing it), once size was zero i was doing the check and Ape Escape would crash again, some games only have say half the packet left over so it might do 1 or 2 vectors, so it would do that once or twice, size would become 0, then try and do it again and crash because "size" doesnt exist (VS quirk? maybe) but this also effected XMen as it has 2 vectors to write at the end of each packet, so without the size check it would write 2 vectors of crap then start in the wrong place with the new packet.
wisestudiodev: Ill have a look at that tonight, i think i have a Gradius V dump, if not ill hunt one down ;p
Thx refraction;)

Revision 917

Emitter renovations of a large scale sort (only up to phase 1). Intel's 'group
1' instructions now use a completely new ModRM/SIB encoder, along with a nicely
object-oriented interface. I created some macros to retain backward compat for
now, and will continue implementing the rest of the instructions later as I have
Also: Removed x86/64 instructions from the emitter.
Sorry, where WriteRmOffset defined? It used in ix86.cpp:442, and I see you remove this function from header.
And gcc disallow to wrote (ix86.cpp:45):
const x86IndexerType ptr;
without initialization. I comment this line, and it's compile and run.But maybe you want to made initialization?
WriteRmOffset used in ix86.inl, not in cpp.
hm, but why not just use xbyak? :P

Revision 918

Linux compiles again. Added back in potentially obsolete code, since it's still
Where were you getting the const error?
The const should be added to a function (or more), and not removed from the variable, preferrably.
This is a problem with how MSVC and GCC differ in template code handling. Msvc doesn't parse templated code unless it's referenced. GCC does. So GCC picks up errors that don't exist on msvc for unfinished code (annoying).
ok, I checked and I can find no reason that value shouldn't be const. Can you poaste her the errors you get when it's const, so I can figure out why GCC's being annoying again?
This value could be const -- it could not be uninitialized.
Right; the error is because you didn't set it to equal anything in ix86.cpp. A const, by definition, can only be initialized once, when you create it, and if it's not initialized, it's value is undefined for the rest of the program. And gcc is not willing to let you get away with this.
It's *supposed* to run the default contructor. I'll just add an explicit constructor, even though it's not supposed to be necessary. Whatever. >_<
I've uploaded a patch into Issue 139 for trial. Check the description for details.

Revision 919

Switched the emitter over to using Thread-Local storage (TLS), which removes all
the templates and brings us back to a more traditional-looking, macro-free, and
intellisense-friendly implementation. Plus it's a lot less prone to errors and
will make debugging easier down the road. (next commit will rename the files
back to .cpp and get them out of the header includes)

Revision 920

couple of changes, very minor speedup

Revision 921

Reverted the emitter back to a c/cpp form from inl files (probably wasn't
necessary, but I don't like having code in header/inl files when I can help it).
* Fixed a couple potential bugs in some Rm forms of MMX instructions.
* Improved compilation times by isolating BaseBlockEx.h to the files the needed
it (it uses STL junks).
* Removed some dead code form emitters and BaseBlockEx.

Revision 922

Implemented the 16 bit forms of Group 1 instructions into the new emitter.

Revision 923

More updates to the new emitter: switched over some Push/Pop instructions, did a
fully compliant implementation of LEa (both 16 and 32!), and fixed a couple
small bugs in the ModRM/Sib encoder regarding EBP as an [index*scale] formation.

Revision 924

-fixed rm instructions to work with Jake's emitter changes
-implemented the case where upper and lower instructions write to same reg at
once (the lower instruction's result is discarded)
-implemented more first pass analyzing stuff
-fixed various bugs...
Hope you will make it alive some day...
BTW... What I have to do to enable that "buggy, laggy, incomplete and all that stuff" microVU recompiler instead of zero's?.. I've uncommented that define in pcsx2config.h, but I can't see any difference in speed or compatability in games I have... The only thing that changes is executable's size... What I did wrong?.. I expected bugs and crashes... :-)
PC: Nice graph here: http://pics.livejournal.com/eliot_cougar/pic/000bh99y
uh, it's still not working at all...
if you were to enable microVU recs fully now you'd just get a crash or something as soon as you try to run the game.
its incomplete so nothing works ;p
its like trying to drive a car with no engine xD
Ah!.. I found your ifndef PCSX2_MICROVU_ stuff (with underscore) in two files...
I've got the crash now, and I'm satisfied... =^.^=
Good luck and a lot of patience to you in your challenge...

Revision 925

Fix Linux again (and again and again and again...)

Revision 926

backing up some changes

Revision 927

Disabled a VU recompiler option that caused some SPS in Ratchet and Clank and
didn't actually affect speed.
Modified VU stalling logic of MR32 and MTIR instructions and modified FDIV
Actually it brings slow downs in MGS3 for example, is there anyway to fix it with rec enabled
Sorry it was my fault

Revision 928

Fixed Gradius V, had to destroy the templates arcum did a bit to get it to work
without ape escape crashing (sorry mate lol. Took out my V3_# discovery, ape
escape is getting spikey now, so ill just remove it. Also altered V2_# to work
slightly different incase the packet starts on the Y vector, it now wont suffer
underrunning (possible bad data)
That's all right, I know how delicate that area of code is. If you send me a dump of Gradius V, I'll see if I can clean it up without breaking Gradius V during the weekend...
Something to note :
r900 to r911 (inclusive) had the loading screen of outlaw tennis fixed, before r900 and in r912 and up (this revision inclusive) - the screen has one of the loading box's corners in a different place.
Can you put a dump up somewhere for me Nneeve? either post me a link on the forum or put it on here, either way :)
And if you could pass that along to me as well, that'd be great. I'm starting a collection. :)
Dump: http://senduit.com/54aaec
fixed it, dont know HOW r900 to r911 fixed it, wasnt even in that file! lol
anyhow ill update in a bit

Revision 929

LilyPad: Small/large motor defaults should work for most devices, when creating
new effect bindings.
Keyboard queue fixed up a bit, mainly to favor escape down when PCSX2 is dying.
Fix for ignore bindings being swapped with the swap pad bindings buttons.
Updated version number, thinking of releasing soon. No known bugs, not that
much more to do.

Revision 930

LilyPad: Debug line removed.
No, the last updated did not magically give anyone an invisible XBox 360 controller, contrary to what the device list showed.

Revision 931

More Vif Unpacking cleanup. (And probably not the last of it.)

Revision 932

[No log message]
Gota love how the log message got lost in the way eh ?
branched for vtlb-rewrite code merge.This is not a rewrite of vtlb, its support for vtlb to rewrite the code on the fly.
Interesting feature, but I could not imagine where could it be used. Maybe you've got an example?
This will be only for windows ...

Revision 933

Fixed Outlaw Tennis error on the loading bar, as a strange side effect, this
fixes the missing textures in Crash N Burn too. What is more annoying is this
code use to be in the emulator ages ago (before processing skipping) and it was
removed as we didn't think it actually had a use! :D
I hoped this commit fixed missing textures in "Crash: Mind Over Mutant" too... Seems that it's not... (r942)

Revision 934

--This breaks linux.
--Basic vtlb code rewrite for full mapping using exceptions
--This is buggy & leaks ram for now
Also, P will reset the dynarec cache.
It has been reported it randomly generates cookies, but i'm not too sure about that
It seems like EVERY more or less important part of a code will be rewritten from scratch. wxgui, VU, the interpreter, vtlb, EERec...
Playground merging was best event in project history!

Revision 935

The last changes to clean up Vif wouldn't have worked in some situations, tried
to rearrange it and space things out and skipping unnecessary checks
Fixes Tekken5 and seems to be a good bit faster, too ;)
Yep. Nice work optimising things. I was going to work on that after my last commit, but was too tired...
make sure you get r937, i missed some rather important code.. lol

Revision 936

--No longer uses 2 hacks/buffers, it just stores the info needed to generate the
memops directly on the code
Good work!

Revision 937

Slap my wrists for the silliest error ever :p only thing that gave it away was
the sirens on top of the heads in Ape Escape 3 had no light lol
Yeah, that would make a difference... :)
so will the next commit lol

Revision 938

last silly mistake, promise :P
As long as I get equal chances to break Vif in silly ways... :)
of course :p

Revision 939

Yes, more Vif work. writeX, writeY, writeZ, and writeW are all merged into one
GJ, might be worth setting the rowreg back only when its added to tho, no point in it setting it every time :)
Good point. My original design for the function turned r0-r3 & c0-c3 into arrays, and after deciding that wasn't going to work, I had to improvise a bit...

Revision 940

More unpack changes, tried to simplify a few sums a bit when processing skipping
and a few other misc bits
Looks good. Shame 0xC does something different in that first case statement. Otherwise, I'd pull
vif->tag.addr += (size / unpack->gsize) * 16;
out of it, and make the case statement only happen in the developer build...
well i was going to make them all do that, as C will come out with the same result if i use the complex equasion or the simple one, but i chose speed over cleanness

Revision 941

A few tweaks to the unpacking code. _UNPACKPart isn't really neccessary anymore,
and optimised writeXYZW a little.
These last unpack changes are starting to make a real difference in speed.
Keep doing these ;)
But please check Tekken5 from time to time, too!
This is the second time it breaks due to vif unpack changes :p
Not sure how many more optimisations there are to be made here, but we'll see. :)
As far as Tekken 5, do you have a dump with the issue?
Nope, sorry.
Tekken5 dumps are hard to make, since the opponents are random.
Refraction has this game though, and since you're both coding on this part of the emu atm, maybe he can fix it?
We'll see i guess :p
Yeah, he fixed the last one, so he'll probably be able to fix this one too.
And my collection of games is heavily RPG-oriented, so I don't have Tekken around...
Looks like Vif.cpp now has about 200 less lines then when I started the unpacking cleanups, too, which is always nice.
BTW, did Tekken 5 break on this revision, or one of the earlier ones?
This one, I'm fairly sure.
Didn't do a full test, but it's either this or the const one (rev942).
Heavy SPS and stuff make me think it's this here ;)
Probably. You might try changing:
dest = setVifRowRegs(offnum, vifRowReg + data);
vifRowReg += data;
dest = vifRowReg;
setVifRowRegs(offnum, vifRowReg);
dest = getVifColRegs((_vif->cl > 2) ? 3 : _vif->cl);
if (_vif->cl > 2)
dest = getVifColRegs(3);
dest = getVifColRegs(_vif->cl);
The other changes would be harder to check...
This causes SPS in Tekken5
Read the conversation right above your comment.

Revision 942

Take care of Issue 139 .

Revision 943

GSdx: this should probably fix taking snapshots with dx9, also upped the version
to .15, since the revision number has passed what the last release still had
from the old repository.
CComPtr<IDirect3DResource9> res = m_surface;
if(CComQIPtr<IDirect3DSurface9> surface = res)
operator = calls QueryInterface (for IDirect3DSurface9) on res, but that returns NULL...
D3D objects were always a bit broken, COM-wise.
broke tekken 5
Nope, Tekken5 broke earlier. Please test a bit better before reporting breakage.
You guys make us work uselessly with these false reports!
[email protected]
And anything that on old gsdx the problem remains? Think at a leisure
Where a fix for gow2?
[email protected] T5 is not caused by gsdx
Gabest, i'm just interesting i've uplosded GoW2 without green, is it helpfull to solve the problem?
can't fix gow2, not just the green overlay is the problem, much earlier at the beginning of the frame it clears the z buffer by setting it as the render target and painting it black, that will never work in d3d.
Fix for GOW2.
Index: plugins/GSdx/GSState.cpp
--- plugins/GSdx/GSState.cpp
if(GSUtil::HasSharedBits(fi.FBP, fi.FPSM, fi.TBP0, fi.TPSM))
//skip = 1;
skip = 3;
but what about half of the missing geometry because of the uncleared z buffer?
Wasn't GoW1 suffered same problem before it was fixed or it was just green?
Anyway if change second part of GoWfix code
else if(fi.FBP ==0x0000 && fi.FPSM ==smth && fi.TBP0 ==0x0000 && fi.TPSM ==smth)
skip = 1;
else if(GSUtil::HasSharedBits(fi.FBP, fi.FPSM, fi.TBP0, fi.TPSM))
skip = 3;
background textures this srange wall sometimes will go out it makes other bugs but it much more chances to complete game in HW now *i almost complete game with this code*
smth = just don't remember what was writeh there

Revision 944

Fix for one small bug, doesnt fix tekken 5 tho :(
Now that's interesting.
This mistake dates back to the last commit that you fixed Tekken 5 on. :)
yeh, i fixed it, then you missed it again when you did your changes, so i put it in again :P

Revision 945

Why this broke Tekken 5 i don't know! (answers on a postcard) anyhow, fixed :)
The only explination i have is the double break caused by jNODEFAULT was causing some of the while loops (like on UNPACK_V4) to break before they had actually written any data. Tekken tends to mask everything but say Y, so it'll go to write X, break (because its masked) not write anything else.
Other than that, im baffled
Well, that's the last thing I would have expected to break it.
Wonder what the value of n is in Tekken?
back to normall again)
Or I suppose it could be the double breaks. That's bizzarre, though.
I think the problem is the double breaks, some how it confused the compiler with the while loops we've used while it "optimized" the code.
You're probably right. If it was an issue with n, it should have asserted, not just looked bad...

Revision 946

Fixed recently discovered bug from VIF which could have potentially happened
anywhere jNODEFAULT is used (nobody noticed lol)
Probably a good idea, since break seems to be used before jNO_DEFAULT in 90% on the code...
Tekken 5 back to normal, thanx :)

Revision 947

Fixed alignment problems noticed in Digital Devil Saga
OMG, no more ghosting! Thanks a lot Ref. ;)

Revision 948

- added microVU_Execution.inl
- dispatcher stuff is now recompiled with pcsx2's emitter instead of using
inline asm, its cleaner than inline asm and its more portable since the asm
won't have to be ported to GCC.
- lots of first-pass implementation for lower opcodes
- implemented documented branch behavior (first pass stuff only)
Note: theres some undocumented stuff branches do according to Nneeve's tests,
but i won't implement those for now since 99% of games shouldn't need it, and
according to the tests, the behavior seems kind-of random/erratic.

Revision 949

forgot to add microVU_Execution.inl in the last commit xD
This commit made a new linux issue, and the strange one, Drakan the Ancient gates start to freeze at random points. I was unable to obtain this issue on windows, and no other game was touched yet, so I still searching the correct testcase.
This was a microVU commit: no active code currently. Last commit that could have affected things would have been 947...

Revision 950

GSdx: GoW2 fix, 16 bit drawing that caused the green overlay is skipped
(character shadow)
As always, since it's based on one single .gs, there might be other parts of the game that still have errors.
Thanks a lot Gabest.
I wish I knew how to program this.
Thanks Gabest, i think issue 30 can be closed now
Nopes, it's a CRC fix again ;( Only NTSC games affected ;(
Yea, the Green screen it's there in Pal version.
SCES_54206 CRC=44A8A22A include, but not working.

Revision 951

--BTS r/m+r added for emitter
--Uses BTS + bit arrays for manual block tracking, instead of full
invalidation.It makes some games much much faster and doesn't seem to affect he
rest (still, testing is needed).Okami that uses some sort of SMC works .. but
i'm sure there are some bugs left in it
Speeds up FFX from 300 to 400fps, dragon quest 8 menus are 10% faster.
Seems to slow down all the other games a bit though :p
How much slow ?
Scratch the getting slower part. I forgot that 912 is quite slow to begin with :p
Also: Kingdom Hearts 2 and Odin Sphere got a good bit faster (20% for odin sphere!)
Finding more games that speed up :)
One game got slower though, and thats suikoden5.
It was the worst case example for the old tlb build, vm beeing 100% faster in menus.
The game used to hammer the exception filter. I bet it still does that..
nice work and good news
rama, I think you only have one game: tekken 5 :P
I was excited to test this,but it broke Virtua Fighter 4 Evolution.
this is my 1st comment btw
There are some sps in Resident evil 4 Pal in latest build,i think it's because of this changes
Odin Sphere's faster though there's still a massive slowdown during blended particles (i.e. very end of the intro). Probably gsdx related though?
Gregorio: These changes arent even part of the main branch.
BTS? Isn't that one of those old clunky instructions that run on microcode, far outside the fast path of modern CPUs?
scratch that comment. it's fast in its reg to reg form, on Core2 at least.

Revision 952

GSdx: GoW2 fix #2, pal version this time
Hah ! You're the man ! You're the man ! Thanks a bunch ! :D
Outstanding, Gabest! Any chance you could take a look at issue 23 so we could actually finish GOW1?  ;-)
Is that a gsdx issue? How could I repro it without actually playing it through? At what point of the game does it happen?
Not sure, but if the posts in issue 23 are any indication it definitely sounds like it's related to gsdx. See details in issue 23 . Someone posted a block dump there if it helps.
It happens immediately prior to the final battle with Aries and makes completing it impossible. Shame too, since everything right up to that point works just fine.

Revision 953

more microVU stuff...

Revision 954

Fixed bug from Issue 144 .
all your commits is one same file :P
thats because im workign on the same file and this gives good bug tracability
Good job, as usual :) Thumbs up! I hope that VP2 will be playable soon :P

Revision 955

Optimized and split up the unpack call a bit so less checks are being run,
should bring an overall speed increase. Also got rid of some duplicate pointer
rubbish which was all over the place.
You missed a _vifCol[1], and it's not affecting things. In fact, searching, I don't see anywhere vifCol is being used. :)
Except aVif.asm, anyways, and since none of the variables were changed there, I'm assuming that code is dead.
[1] Vif.h, line 87.
dont know if its used or not, youre rigth tho i did miss it :P but it was never allocated to in vif anywhere, so i presumed it was done elsewhere if it is used
second thoughts, some how much find and replace in entire solution just missed it :O
Well, I just deleted where vifCol is defined and the extern, and the compiler didn't complain at all and everything ran. I'd presume it's unused, and can be gotten rid of. I sertainly didn't see any uses when I did a search on the whole project...
possibly none then :P

Revision 956

Look over there! A THREE HEADED MONKEY!
Guybrush Threepwood :D
Oo this is the second biggest monkey head i've ever seen XD
Haha :) Cool
A bit faster and virtua fighter 4 evo works again.
Haven't you used that commit comment before?
Not that I'll ever object to Monkey Island. I'm probably one of the only people that's downloaded the ScummVm ps2 port, and tried running it on pcsx2... :)
hey it worked the first time, didnt think itd hurt trying the same comment twice :p
Yeah, that's true...
Wow, it's again! :P
Oh you commit code like a dairy farmer.
Three headed even lol
gabest11: how appropriate, you code like a cow!
I'm shaking, I'm shaking
I'm rubber, you're glue!
Wow, you're good enough to fight the Sourcemaster!
Have i passed the three compilers?
Let's see... Visual C++, GCC, and ICC.
I know this commit passes the first two; not sure on the third. :)
oh bum :(

Revision 957

--updated to r956
--uses test8 instead of test32 when possible
--exception handling checks are a bit more strict

Revision 958

resolves Issue 143 Altered Beast
don't you need rest ??
rest is for the weak :p
refraction is not human, that's why "it" doesn't rest. Just kidding, awesome job!
Hey Refraction, since you are on a rampage, take a look at issue 152 . See if you can do anything about it man. :) Thanks my man. Keep up drinking the energetics :D
dhalaila: Not with that amount of information no :P when did it break, did it ever work, what revision did it break on (if known) and a blockdump, all this info would be useful

Revision 959

microVU: fried my brain with some very-complex VU flag-handling logic/algorithms
(hopefully they work as expected)
hmm, seems they still need some work...

Revision 960

microVU: more flag stuff (div/sqrt/rsqrt flags set at proper time)
forgot to report that 956 broke Castlevania: Curse of Darkness at the save points. Is that fixed here?
cottonvibes' changes will never fix anygame unless he ( or she :P ) release microVU
He is HE :)

Revision 961

Fix for MGS3 corruption from r955, i don't know why but where vifRegs was set
previously, it was completely ignored, regardless of the fact the code has run
through there before doing anything else O_o
Wow that was fast i just want to report and you already fixed it, thanks
Damn you're unstopeable :D. Hey Ref, I posted the block dump you asked for issue 152 .
Have you tried Castlevania Curse Of Darknes break at the save points? Just wondering :)
amazing work !

Revision 962

GSdx: GoW2, try #3
Junrgao, are you the Positive man ? Heheh.. Huh... What this revision does for GOW2 ??
you try delete the gsdx directory and re-download the code, maybe the revision number is correct. I don't care the revision number and only pay attention to the changes :P
He changed skip from 30 to 29, I really don't know why he did it, but it should fix something
This fix works for my NTSC version but someone told me that PAL still requires 30
Pal's fine now

Revision 963

Worked on savestate support a bit. It now remembers an update timing variable
more (could fix a few crashes).
This increases the savestate version though, so make sure you have a memory card
save ready before upgrading!
Also implemented a way of delaying audio output after loading states. This masks
the ugly noise that some games produce directly after loading, keeping your
valuable speakers intact :p
Btw, if for some reason you want to keep using your older savestates...
static const u32 SAVE_VERSION = 0x0005; << change it back to 0x0004.
It will most likely work still :p

Revision 964

Added a check to to clear QWC register if the upper 16bits are set. This fixes
most of the broken backgrounds in movies.
Grande pibe!!! Igual el commit groso es el otro :P

Revision 965

Added a check to to clear QWC register if the upper 16bits are set. This fixes
most of the broken backgrounds in movies.
Hmmm nice... Does that means it fixes movies like this one?
Fixed Star Ocean 3 videos :)
Awesome ;)
Yep, Tri-Ace games fmv got fixed. GUST games split backgrounds as well.
Great stuff :)
You really see movie? I saw only first several frames of staring video of SO3, and then it seems FMV's freeze (but start button is working).
Beautiful. I had Windows up for something else, and probably won't have time to reboot and look at it in Linux tonight (I just got home, and I'm getting ready for bed), but the opening movie in Star Ocean looks shaky but is there (past a few frames), and spots that I know had split screens in Atelier Iris 1 & 3 & Mana Khemia all look normal. ( The Atelier Iris 1 tutorial, for example, or Mana Khemia's opening screen)
Looked a little odd to me, actually, because I've gotten so used to how it looks broken. :)
I even tried Star Ocean in the Windows version of ZZ OGL, with no issues....
On the FMV, at least.
Yep, tri-ace fmv all work now.
I've had them working to some extend with a hack, but that one would freeze somewhere around half of the intro fmv.
At this spot this version here continues, but it has a fraction of garbage.

Revision 966

microVU: changed flag handling algorithms some more...

Revision 967

microVU: minor changes...
:) BTW the graphical bug in VF4 evo in their life bars is gone under DX10 :) Great stuff...!
You do realize that microVU is not used yet so these changes you are reporting are not due to these microVU commits right? :P
Exactly. ^

Revision 968

Small cleanup and made it a bit faster.

Revision 969

fixed a minor bug from saqib's earlier commit

Revision 970

microVU: bug fixes on some flag handling stuff.

Revision 971

Many Emitter updates:
* added implementations for MOV and Shift instructions (SHL, SHR, ROL, ROR,
* Improved compilation optimization considerably, by improving inlining
selection in cases where constant propagation can be resolved reliably.
* Moved lots of code around, so that the new emitter and the legacy emitter are
more clearly separated; and renamed some vars.
* Changed recompilers to initialize the recBlocks array to 0xcc instead of 0xcd
(fills the blocks with the single-byte instruction INT3, which fixes the
misalignment mess that would sometimes happen when using disasm views on the
RecBlocks contents).
* Switched back to /O2 (Optimize for Speed) instead of /Ox, since MSVC (for me)
generally fails to optimize Thread-Local storage in /Ox mode.
What are the emitters for in terms of their placement in ps2 emulation?
xatnys: https://code.google.com/p/pcsx2/wiki/RevisionReviewEtiquette
I dont see what was wrong with his question. He was asking where on an actual ps2 those emitters were used (or thats how I interpreted his question anyway). Which isn`t a insulting question, but one of curiosity.
pcsx2 'recompiles' the ps2's code into x86 code your PC can read.
the emitter is a bunch of functions that are used to write the x86 code that your PC will read.
so basically, the nicer the emitter is, the nicer it is to write new rec-code.
there are also some optimizations you can do at the emitter-level to speed stuff up, but mostly the change will just be for cleaner/nicer code.
Maybe it would be better to drop Linux build? Because this update got all bunch of c++ stuff, that gcc does not like: uninitialized constants, extern declaration of variables after usage, well, if it compilled under VS, that I am an elephant.
hockl: It's irrelevant, idle curiousity that serves no real purpose here. As the page says, this is not a forum. Intended for useful comments on individual revisions for the devs, not idle questions of end users.
Arcum42: If you have some complex errors, please post them to a new issue. I'll help resolve them from there. I had to do some code juggling to get MSVC to optimize things in an intelligent manner, and I'd like to retain that if possible, which means moving code around to fix GCC needs to be done with some measure of forethought.
Maybe this would be a good time for me to try that ubuntu-under-windows thing so I can do some GCC compilations.
Haven't had a chance to test it yet, and I've got to fix up my copy of X Windows a bit before compiling, because I messed up a few config files during an update. Think I just need to tell it what windows manager to use again, though.
And it looks like Zeydlitz already has the neccessary changes in issue 156 , so I'd look at that, and we'll use that issue for the moment...
Got X Windows working. Since I updated the nvidia drivers doing that, I'm getting my 32 bit chroot in sync before looking at compilating issues, though.

Revision 972

microVU: more flag "stuff" xD
<JakeStine>cotton: your commits always contain "stuff"
<JakeStine>I think you should rename one of your files to "microVU_stuff"
<Dwarg>And maybe others called "microVU_junk" and "microVU_crap"
<Dwarg>Then you could be much clearer
<Dwarg>"Fixed some junk, broke some crap, added some stuff...."
lol :)
Ha ha ha ha!!!
hahaha :D
if the prophet doesn't want to come to the mountain....
kabooz: what does that mean? :p
cotton: there is a saying "if the prophet doesn't come to the mountain, the mountain has to come to the prophet"
meaning if you have not the enviroment to play minigolf for example, then just create it yourself XD
basically what jake and chickenliver proposed XD
ah and the saying is based on moses climbing the mountain sinai
i see, i hadn't heard that saying before ;p

Revision 973

got the okay from Saqib to delete the obsolete pcsx2v2 branch (old attempt to
convert pcsx2 to c++)

Revision 974

Fixed a bug in the Emitter the caused the VU1 to screw up a bit (bad gfx and
freezeups and stuff). Also: Resolved some GCC/C++ troubles.
I'm wondering, all these emitter updates as of late, are they for improving the quality of the emitter's code, improving the quality of the code it generates, or both?

Revision 975

LilyPad: Changed how device updates are handled to be more multithreaded
friendly. Mutexes when "read input in GS thread" is disabled removed, as they
should (hopefully) no longer be needed. May just ditch the option entirely in
the future, since enabling it doesn't seem to make much difference, and slows
things down for some people.

Revision 976

Linux: Fix the Makefile.
Is linux compiling ok now?
It does for me...

Revision 977

Port 2 Multitap should be fixed (PCSX2 bug).

Revision 978

Cleaned a few things up, and moved a few things around.
As a dev note, most of the spr0->qwc = 0; and spr1->qwc = 0; lines that were removed were removed because the variable in question would already be 0 at that point...

Revision 979

Some work on Vif & Hw.
By the way, all of those labels you changed from numbers to constants is #ifdef'd out (more unused reference code). Although the 'bad' news is that this particular case of old code is, in fact, no longer useful. I left it in originally in case the new vtlb versions of hardware (in hwRead.cpp / hwWrite.cpp) were buggy. Seems they're not -- it's been months without problems now, so the old reference code can be removed.
The old VM code in LoadStore is still useful because we haven't converted *all* load/store functions to recompiled asm, and the VM code is a nice guide for when we want to do that. :)
Ah. Noticed the one #ifdef 0, but didn't notice the other. Mainly because I started from the bottom and went up.
Oh well, suppose I should remove that code before anyone else works on it... :)
You know, the one problem with having that much reference code in LoadStore, is there's more reference material then code there. It might be easier to work with if it was pulled out of LoadShare into a separate file, so you could see them side by side...

Revision 980

Fix compiler warning.
Not that anything uses the return value of this function anyways, but it gives a warning in Windows, and people tend to bug me if I leave compiler warnings that show up in Windows in...
I like this crazy commits, where is the iron man Jake and refraction? :P

Revision 981

-minor change
-fixed a lot of various errors
-partially implemented some clip flag stuff
-partially implemented some branch/jump stuff
And here comes more "stuff"
> zeroRecs:
> -minor change
You better spend this time to microVU! ;)

Revision 982

Implemented Jmp/Jcc and MOVSX/ZX instructions, and added 'i' prefix to most
things (will add 'i' to a few more soon -- I think iRegister will be nicer than
It will be like iPod, iPhone, iTunes, and so on...
Apple's marketing make us think that "i" prefix is nice...
I've used "i" prefixes since long long ago actually. Coders I worked with used to prefix things with i and m to denote intel/x86 vs. motorola/mac specific code back in the 'old' days (1994-1998). That's kind of ironic when you think about it .. the Mac using an 'i' when to us coders that made it look like an intel.
But yea it's easy on the eyes. We tried about every letter in the alphabet, and it came down to either 'x' or 'i' -- and 'i' made more sense. :)
Dropping a negative on this commit as a marker that it's causing a regression in Dragon Quest 8 (missing geometry). I'm pretty sure it has something to do with the LEA instruction optimizations. I must have goofed the logic up somehow.

Revision 983

Add an include so things compile.
The include is due to using Console in ix86_inlines.inl...
More of that gcc template parsing weirdness. That's highly annoying honestly, since C++ isn't really set up to have code in header files (in that it ends up running to interdependency issues because names need to be resolvable on the first pass of compilation), but templates require the code to be in headers. When GCC demands that things parse sanely, it means I have to spend lots of time including lots of crap headers, and including lots of crap forward declarations, even if they're never actually needed or used. :(
Well, I don't understand how VS allow you to compile code that have some sort of symbols that was never declared. It's some strange style of programming, really.
>> It's some strange style of programming, really.
Yes, it's template style programming. It's by nature evil hackery, and little more than a slightly more type-safe and backslash free method of using #defines. That's what templates are, and like #defines, they shouldn't generate syntax errors or external reference errors until you actually try to *use* them.

Revision 984

New speed hack mainly targeting 3D geometry.
Works Great with MGS3 and GOW2. Nearly 100%+ speed in some zones
Awesome speedup. Works very well on FFXII, FFX, Valkyira Profile 2 is playable at fullspeed, Star Ocean 3, and so on.
Really, Really awesome.
Keep the good work up.
Works very good with Tales Of The Abyss.
Well, I only had issues with Tales of the Abyss. Same with Grandia III, too.
Works very good with Captain Tsubasa, Without this options, sometimes framerate will drop to 1xfps... now, mosts of times are around +5x fps :D wow
I don't know which svn exactly has caused it but Resident Evil 4 suffers from some light SPS now.
Find out which revision RE4 broke, and a fix for it may come sooner ;)
DQ8 has been broken since r982.
Confirmed that DQ8 is broken by r982. I'm looking into it.
I tested with a few games I have. My setup: E2180 @ 2.8GHz + 9600GT.
It didn't worked with Xenosaga,breaks it completely, unfortunately.
But for my pleasure, Shadow of the Colossus is running at fullspeed All THE TIME with this speed hack ON(sometimes at 100fps or more) on my poor 2.8GHz C2D. I was amazed. The same for God of War.
Thanks very much for this, sudonim1 and all the PCSX2 team :)
Won 10+ FPS on Dragon Quest 8, thanks a lot !
Game Tested: dot hack//gu vol.2
I think it gives a minor speedup but i have noticed that the fps counter rises but the game is running alot slower except for the music
noticable speedup in MGS3, however putting EE 2x speed and using this vu speed hack makes 60FPS but the game speed itself is slow.
In GOW, this speed hack makes everything smooth and playable, the only noticable side effect is Kratos keeps flickering (disappears and reappear quickly).
Great speedup in GoW2, magnificent!
cpuRegs.cycle += s_TotalVUCycles * Config.VUCycleHack
only this small change? what's the difference between it and vu skip?
maybe cov can explain it. :P
No speed up at all, only FPS counter speed up... but games are even slower.
turn off your frame limit cap, you should see much faster frames than without the speed hack on. Play around with it.
Speed is the same but but shows higher fps
another cycle hack.. this one looks very simple.
Any compatiblity issues with it?
i'll check it out when i come home.
There is no speed but it seems allow to upscale some very though games like MGS3 and SotC
That's amazing!!!
It seems that I can play most of my games even on my laptop now... Awesome... Tested on ECCO the Dolphin... I'll try other games this evening...
If only FFX will be playable(on my laptop), I will disappear for several weeks...
It works very well. If the speed hack skips the frame set it to medium
Yes, I noticed that on "high" it skips frames and sound gets desynced... On medium I can't see speed improvements in FFXII for example...
PS: I think PCSX2 needs benchmark already... Something as simple and basic as writing average FPS in .csv file every 1-5 seconds for example...
>> PS: I think PCSX2 needs benchmark already... Something as simple and basic as writing average FPS in .csv file every 1-5 seconds for example...
That's still a questionable feature, since many games increase in fps with speedhacks, but otherwise run slow or choppy due to emulation errors induced by the hack. For sure, adding benchmarking for speedhacks isn't ideal.
But I will improve some of our code profiling tools soon (when done with emitter and wxGui and stuff), unless someone else beats me to it. :) That won't add any fps features tho... it'll just be a per-block profiler for the recs (which will be pretty handy for performance tuning).
Nevertheless, it will be possible to compare different builds or different plugin options using the same speedhack options (or no speedhacks at all)...
But yes, it's a questionable feature...
Isn't a "per-block profiler" a debug-build-only feature?..
s_TotalVUCycles counts how many emulated vu cycles we've spent in the vu recompiled code.
What we're doing is "stealing" these cycles from the EE, quite simelar to what the sync hacks do.
This was meant to enhance the sync between ee and vu, but that didn't turn out so well.
We noticed it's nice as a speedhack though, so here you are, one more cycle hack :p
I get to 100FPS from my original 40FPS on God of War using this speedhack. No speed improvement on FF12 though the FPS read got higher.
this hack increases speed ONLY if GS part have enough resources. When GSdx set to 2048^2 hack makes everything slower. With 1024^2 - faster. Speedup usually somewere around 20%. Tested with Warriors Orochi 2, Virtua Fighter 4 Evo, Soul Calibur II/III, Tekken 4, Hand of God, SW: The Force unleashed and some other games - everywhere same results.
So, if you playing with GSdx on 2048^2 (just like me), you'll get no impact.
BTW, EE sync hack works just the same. No impact if there is not enough resources for GS. Yet no slowdouns usually...
I've been playing far too much star ocean since adding this, it's a barrier to development.
OMMMMMMMMMMGGGGGGGGGGGGZZZZZZZZZZZZZZZ I'M NUMBER 40!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
upfloor, you are 41 :P
cotton will make r1000 - MicroVU's working, +250% speedup on most games.
Or it could be: "Fixed minor typo". :)
good of war is indeed faster, but the characters are flickering.
GT4 has SPS in the distance and got not speedup,
very strange in FFX: graphics are slower, even at fullspeed and the music still plays at normal speed.
KH1: no difference.
This speed hack is fantastic!
On personal test, It work better when your not ussing the VU-SKIP (less onscreen error)
That's great!
Thanks a lot
uhhmm, im new here, how should i use these codes on pcsx2 emulator?
read the source very loud and imagine you're playing the game... ^_^
Seriously, try to get Visual Studio 2008 and TortoiseSVN, get the latest source, open it and compile it...
Maybe it'll be easier to get latest installer, latest SVN binaries of the emulator and plugins, copy one over another and be happy...
Try to google something like "how to compile things in VS2008"...
thanks eliotfur!!

Revision 985

Added CMOV to the emitter, renamed x86Struct stuff to iStruct, renamed XMMREGS /
X86REGS / MMXREGS defines to iRegCnt_XMM / iRegCnt_GPR / iRegCnt_MMX, and undid
a couple u32 optimizations which could have caused unexpected behavior in the
future, if we ever decided to employ some particularly obscure case of self-
modifying code.
ix86_legacy.cpp:125:1: error: pasting "iMOVSX" and "(" does not give a valid preprocessing token
ix86_legacy.cpp:131:1: error: pasting "iMOVZX" and "(" does not give a valid preprocessing token
I hate trying to decypher defines that create functions. ..
Will fix in my next commit.
I don't like those defines either, but they're just there to patch the legacy emitter in to the new one. Eventually we can delete them, when the legacy emitter is dead (someday...).
... for the record, it's just some extra ## in front of the '(' -- but I'm still busy adding iMUL stuff. Will commit soon. :)
All right, cool. I've just been in and out of my apartment, and fiddling with other things, so haven't really had time to look at it beyond getting the error message.
For example, I thought I'd be a good idea to install Wubi on my Windows 7 partition, and see what's necessary to get pcsx2 running on it. I like installing oses in virtualbox and vmware as a bit of a hobby, anyways,so this is just a bit of an extension of that...

Revision 986

* Added MUL/DIV/IMUL/IDIV to the emitter, renamed as UMUL/SMUL respectively (to
remove ambiguity of the instruction behaviors).
* Fixed a bug in the shift instruction emitter that would have caused it to
emit the wrong instruction type (like a SHR instead of a SHL, for example).
* Added type strictness to the shift instructions that take the CL register as
a parameter. Passing anything other than CL will generate compile time errors
* Fixed a syntax error in one of the legacy defines.
The Shift instruction bug may have been what caused missing geometry on DQ8 (although unlikely). Someone let me know if the DQ8 missing geometry problem persists, and if so we'll create an issue and troubleshoot it further from there.
Ooops! I forgot to add a file! Blast it. >_<
DQ8 still broken by r987。

Revision 987

Forgot to add a new file from the last commit... >_< [ix86_impl_dwshift.h]
Just because it can be rare occassionally, just thought I'd let you know; Linux currently compiles ...

Revision 988

Emitter: fixed a bug in MOVSX/ZX's reg->reg form [resolves Issue 159 - missing
geometry in DQ8], and moved some files around.
Thanks for the fast fix.

Revision 989

Minor bugfix for unpack mode 2
Fixed split videos in Gradius V
Fixed Spyro hanging problem in Issue 112
Put in a hacky fix for FFX videos into IPU to compensate the spyro fix (which is
actually correct).
Implementing unpack overflow protection (Guitar Hero 3 & Toni Hawks Project 8)
Writing XGKick to a temp buffer before sending to the GS (part of the GH3 / THP8
Note! THP8 and GH3 will STILL crash with any VUrecs on and MTGS on, these must
all be OFF. Also use GSDX in software mode with the NLoop hack on for now. Slow
i know, but it works :P hopefully we can fix the rec side of it soon.
Just as a note:
#define gif ((DMACh*)&PS2MEM_HW[0xA000])
in IPU.cpp shouldn't be necessary. A few revisions back, I moved that definition to Memory.h, along with several other definitions involving PS2MEM_HW, mainly because the same definitions were being used in multiple places.
And Memory.h is in Common.h, so it'd be included in IPU.cpp...
yeh but i started on these changes before you did all that messing n didnt realise :P
you're free to remove it in future commits if you get there before i do
Figured it was something like that.
If you haven't removed it when I have a chance to commit, I'll remove it (If I remember at that point).
Right now, I'm still wrestling with Jakes changes...
Note for Tony Hawks Project 8 & Guitar Hero: The Nloop hack tick box must be black! this feature has to be on, else it looks quite bad lol
hi,refraction. this revision breaks DQ8's word display.
yeh ill look at it
Issue with DQ8 only effects GSDX, looks fine in ZeroGS

Revision 990

Emitter: Implemented INC/DEC/NEG/NOT instructions. Plus: many code cleanups
using a better form of template parameter inference.
We tested the template inference thing on gcc before I used it here, so *hopefully* everything compiles ok on gcc.
Actually, I'm getting:
ix86.cpp: At global scope:
ix86.cpp:243: error: uninitialized const 'x86Emitter::iMOV'
ix86.cpp:262: error: uninitialized const 'x86Emitter::iNOT'
ix86.cpp:263: error: uninitialized const 'x86Emitter::iNEG'
ix86.cpp:264: error: uninitialized const 'x86Emitter::iUMUL'
ix86.cpp:265: error: uninitialized const 'x86Emitter::iUDIV'
ix86.cpp:266: error: uninitialized const 'x86Emitter::iSDIV'
Just looking at that right now...
Just noticed that in the maze of compiler warnings before that, the following two errors were in there as well. Not sure if they are from this one, or 988:
implement/movs.h: In static member function 'static bool x86Emitter::Internal::CMovImpl<ImmType>::Is8BitOperand()':
implement/movs.h:184: error: 'OperandSize' was not declared in this scope
implement/movs.h: In static member function 'static void x86Emitter::Internal::CMovImpl<ImmType>::prefix16()':
implement/movs.h:185: error: 'OperandSize' was not declared in this scope
Note: these may be easy to fix; I've just barely started looking at them...
I'm down to the latter error, about OperandSize, incidentally.
Ok, r993 takes care of the compilation issues. Though I get a million warnings when compiling now. Most of which would be errors if I hadn't added -fpermissive to the flags a long time ago.
(Yes, most of the issues we've been running into are when it's in permissive mode, and giving you some slack. Linux wouldn't have survived the C to C++ transition otherwise.)
The compiler warnings are along this line, in case you're curious:
./x86/ix86/implement/group2.h:49: warning: there are no arguments to 'prefix16' that depend on a template parameter, so a declaration of 'prefix16' must be available
Is it your ClassDiagram1.cd link in the project file, Jake?.. :-)

Revision 991

Fixed Issue 157
removed redundant code arcum pointed out I'd committed

Revision 992

Look out, the monkey is back
Holy monkey bladers it's Monkey Island!
Always love it when we know whats going on

Revision 993

Here we go again.
Typo fixes too, excellent sir :)
Yeah, I like to fix those if I notice them. Unless they are sufficiantly entertaining, anyways... :)

Revision 994

Reduce compiler warnings to a more reasonable level in Linux.
An alternative would have been to make all these functions non-static, and use this-> instead of ImplementationHelper<ImmType>:: , incidentally.
Jesus. It's like anything that's designed to be useful becomes useless once the full on suckage of the C++ standard is adhered too.
Yeah. Didn't like this commit, really, but the noise from these warnings was drowning out any real warnings. I thought about making them no longer be static, and using this->, instead, because it'd look better, but I figured I'd let you make that decision.
What's irritating is that given a choice between adhering to the letter of the standards, and acting like most other compilers do, it seems like gcc's developers will adhere to the standards every time...
Yes, GCC plays by "principle" over "practical."
The problem is that the C++ standard is developed by monkeys with no real-world experience in programming. They've proven time and time again that they really have no idea what a programming language should be like. And so even when they do finally come up with a good idea, they mess it all up by imposing idiotic standards that both complicate the compiler's job and the programmer's job, for no benefit.

Revision 995

Added a check to make sure the unpack REALLY overflows, sometimes it can be dead
on the limit or count the skip, so it doesn't need to break to slower code.

Revision 996

Bring the new speed hack to Linux. (I just quickly hacked it in, so I may make
it look nicer later.)

Revision 997

GSdx: reworked the gs transfer function a bit, and removed the nloop hack, which
does not seem to be necessary anymore.
Wasn`t nloop needed for GH3 to work?
Because now it's always enabled.
Now the NLOOP is enabled by default :)
finally, the nloop hack has confused a lot of people.
Yes, finally... I don't understand what NLOOP stands for, anyway... I thought it's SQUAREENIX-FIX...
Gabest, don't you think that "Logarithmic Z" should be enabled by default... All my games have better appearance with that enabled...
It shouldn't. It breaks Rumble Roses shadows for example.
So? make Logarithmic Z the default and have a tick box for the other option, sounds more plausable to me
Gabest, Great work. this revision doubled the speed for FF12 on the first teach scene for my old N6600 video card (from 16 to 33, still slow :P). and FF12 other scene increased about 5fps too.
But DQ8 seems has some issue at save/load frame, lost the word.
the DQ8's issue is caused by 989 and refraction :P
if it is what i think it is, then ive passed it on to gabest to look at cos the reason that happens baffles me as well :P
DQ8 issue only effects GSDX, use zerogs if you need to see it
This rev. makes the INTC Sync Hack useless.
On r962 with INTC on Ar Tonelico 3 I get ~150fps,without it 50fps
On r997 with/without INTC I get 50fps on the same game,same place.
wow really? considering it has NOTHING to do with it, i cant see how. try turning vsync off?
On r962 and INTC disabled I get the same speed as on r997 with or without INTC.
On r962 with INTC I get ~150fps and without it is 50fps.
I've never EVER used the vsync option(it's disabled)
I've writed about this in the GSdx thread and sorry if I'm double posting with this post but I don't know if its possible to edit my post here.
FFXII in the begining of the game i had 37fps is now 60fps, there were much slow down before and after the fight with spaceship, now it only slowdown when spaceship is coming down to atack, Tekken 4 that had slowdown is the last fight, now it only slowdown 1 second on fireworks.
Grandia 3 got some boost but not that much, in the begining increase between 1-6fps, it still gets as low as 22fps with 3.0Ghz SSSE3 and ati 2600.
It's still awesome improvement between this one and 0.1.14, on FFXII and Tekken 4 maybe for grandia 3 i really need a better gpu to get better fps.
INTC stat hack is still working as expected, tested with AR Tonelico.
Still getting 450fps ingame, which should be enough ;)
I can also confirm that FF12 got faster with this in 3d, I'd say about 15% plus. Nice work :)
Check the GSdx thread,I posted screenshots on Atelier Iris 1,2,3 and Ar Tonelico 1 and 2.
On all of them expect Ar Tonelico 2,the speed differences between r962 and r997 is really huge.
It works now???
I didn't change anything from the configuration?
I restarted my PC and the problem is here again :(

Revision 998

Extremely insignificant optimization applied to recADD/ADDI instructions (omg it
might save a cpu cycle per minutes or something!)
Also: Reverted the addition of the ImplementationHelper<> class, since it failed
miserably under GCC. -_-
That'll work...
yeah, it's more readable this way. And same amount of copy/paste in either case.
who will be the 1000th commit :P
~> it might save a cpu cycle per minutes or something!
It'll be alot if we play game for many hours, lol
Yeah, 1000 is coming. Or it will be PCSX2 0.9.7
I guess after cov complete the micro VU stuff, and Jake complete the new GUI and IPU stuff, 0.9.7 will be released :P
i think 0.9.7 will come when the microVU's are finished and lot of beta tests has been made.
I see a lot of work coming for us.
Let me KINDLY remind you that comments on svn should be more or less useful, unless done by project members. Yeah tough luck, the world is unjust like that.
KINDLY. For now.

Revision 999

-Scaled back the EE load/store cycle count to the theoretical minimum of 1
cycle. (Fixes Digital Devil Saga PAL fmv)
-Added a safety to the VU cycle stealing hack, so it doesn't go berserk :p
Due to the changed cycle count a lot of games will get "slower".
Especially FMV will be affected.
This is unfortunate, but correct emulation comes first.
You can however enable the ee sync speedhacks, as they're more stable now as
This can bring back the lost speed.
ee cycle *2 works for Fatal Frame now :P
can't you add this modification as an optional gamefix ?
>> can't you add this modification as an optional gamefix ?
Yes, it's optional. Enable the X1.5 speed hack, and it'll behave roughly like the old cycle rates. Problem solved.
The problem is that the EE's average load instruction is pretty much 1 or 1.2 cycles per (stores may average slightly higher on the EE, but it's very subjective based on code being run). Thus the load store cycle rates up to now were essentially speed hacks of their own.
>>The problem is that the EE's average load instruction is pretty much 1 or 1.2 cycles per (stores may average slightly higher on the EE, but it's very subjective based on code being run). Thus the load store cycle rates up to now were essentially speed hacks of their own.
Did not yet catch a word :) but I think it is one again the time to thanks you a lot guys for your great and amazing work
A lot slower now maybe make this commit optional like Jake said?
But it surely much more like the real not skipy like previous even with hack
Read Jakes comment again, THIS is the correct behaviour.
You have the option to enable hacks and bring back the lost speed however.
After some test i realized it too, Thanks rama, this carries games right way
I saw you low down 22 to 8 and 28 to 8 if i increase it a little does it bring more speed without safety loss?
"Safety" is lost as soon as you change any of these values.
Consider them all as possible speedhacks.
The EE sync hacks basically multiply these values.