Font Size

Profile

Layout

Cpanel
Jake Stine_avatar

Svn Comments are re-enabled!

As of Sept 30th, we've re-enabled user comments at our SVN repository (PCSX2 @ Googlecode).

Comments have been re-enabled primarily so that we can get user feedback again on plugins and the current legacy gui updates. The trunk of svn (the new wx gui) is still too volatile for user comments to be of much use, so don't be surprised if we pretty well blow off "bug reports" relating to it.

(and yes, top priorities for implementation in the new gui are framelimiter, savestates, and the advanced cpu options -- along with bug fixes and memory leak fixes. No timeframe estimates: They'll all get done when they get done!)

Jake Stine_avatar

New versioning/release pattern

From 0.9.5 onward PCSX2 has been a mostly open SVN revisioning process, where beta builds are SVN-marked and are widely built and distributed to users. 0.9.5 itself was never released as an official 'stable' build, and after the release of 0.9.6 we just called all subsequent SVN builds of PCSX2 "betas." (mostly because we were too lazy and/or busy to bother worrying of version numbers). This lackadaisical version pattern was a source of confusion for users and developers alike.

So starting with our next release of PCSX2 we'll be using an established versioning pattern (which likely won't be for some time -- implementing a new GUI is a complicated ordeal). The new patter will be based on some standard Open Source convention, where odd-numbered versions denote SVN/devel builds (and will have SVN numbers affixed to the version) and even numbered versions denote stable releases. By chance this is already how things have been playing out since 0.9.5, so mostly it just means we're making a conscious effort to continue to apply the pattern in the future. Thus, the past-present-future will look something like this:

Past:
0.9.4 - Official stable release
0.9.5 - Development build (SVN)

Present:
0.9.6 - Official stable release
0.9.7 - Development build (SVN) [wx-enhanced!]

Future:
0.9.8 - Official stable release
0.9.9 - Development build (SVN)
1.0.0 - Official stable release
1.1.0 - Development build (SVN)

This way when people file bug reports we can know from the main version number alone if the report is regarding a stable release or an SVN build, and furthermore users can have a clearer guide to the status of versions being released and such. Furthermore, odd versions will have the SVN revision appended to them by default, like 0.9.7.r1880.

... and yes the hope is that we're going to go to 1.0.0 after 0.9.9, and use a 1.0, 1.1, 1.2, 1.3, etc version pattern, shortening the primary version numbers from three digits to two. But that's a long way down the road yet, and anything could happen between now and then. Wink

cottonvibes_avatar

PS2 VU (Vector Unit) Documentation Part 1

This begins a series of blog posts intended for ps2 developers and ps2 emu authors.
Its purpose is to give some light to some of the secrets I've learned about the VUs while developing my mVU recompilers, and to describe what happens in situations that are a bit questionable.

All information has been at least somewhat tested, but of course there may be some errors.
I should also mention that everything described here mVU implements in some way (unless specifically noted otherwise).
I may even describe some tricks and clever optimizations I used in my recompilers in future articles.

Since these articles are intended to describe advance secrets, I will not bother to explain common concepts about the VUs, and reading this implies you have at least an intermediate level of how the VUs work or how to program for them.

Read more: PS2 VU (Vector Unit) Documentation Part 1

cottonvibes_avatar

Whats clamping? And why do we need it?

In pcsx2's advanced options dialog (if you've dared to look), you've might have noticed there's "FPU Clamp Mode" and "VU Clamp Mode" settings. You may even have experimented with some of these modes and found out they fix or break games.
But what are they doing? And why so many options?

Well first you have to know what a floating point number is. A float is simply a representation of a rational number from a string of bits, whose decimal point can change or 'float'. (This isn't the exact definition, but good enough for this conversation).

Basically there's something called the "The IEEE Standard for Floating-Point Arithmetic" (or IEEE 754), which defines floating point representation; and most systems abide by those rules (of course not our wonderful PS2).

Read more: Whats clamping? And why do we need it?

Jake Stine_avatar

C++ exceptions can be an optimization

One of the first things I sought to do when I first started contributing to PCSX2 was to improve the emulator's overall stability and error handling; and to this day it's still one of my top priorities.

My method of doing so was initially seen as controversial: I merged in drk||Raziel's VTLB code (which was C++), converted the rest of the PCSX2 codebase to C++, and started replacing the (lack of?) error code return values with modern C++ exception handling. The initial reaction from the public (and some PCSX2 team members) was either distrust or panic. Chants of "C++ is slow!" or "Exception handling is slow!" frequented the PCSX2 revision comments.

And admittedly, for some tasks and in some specific scenarios, C++ and it's exception handling are slow. But, of course, the key is to avoid those scenarios... which as it turns out is really quite easy. Better yet, clever use of C++ and its exceptions can actually be a speedup. How is that possible? I'll explain!

Typically in traditional error handling models, you check the return code of a function for errors, like so:

Code:
if( DoSomethingSpecial() == SPECIAL_FAIL )
{
    // Handle error.
}


This is simple, short, and quite fast compared to the overhead of entering a C++ try/catch block. But let's consider a more practical everyday example:

Code:
int DoSomethingSpecial()
{
    if( DoSomethingElse() == SPECIAL_FAIL ) return SPECIAL_FAIL;

    // Do stuff based on DoSomethingElse's success
    Console::WriteLn( "Success!" );

    return SPECIAL_WIN;
}

void LoopOfCode()
{
    do
    {
        // code [...]
    } while( DoSomethingSpecial() != SPECIAL_FAIL )
}


The above code snippet must perform no less than two conditional checks per loop just to propagate the error code up the chain of function calls, and this isn't even handling the possibility of a function returning more than one error code yet! This is a situation where C++ Exception Handling can come to our rescue:

Code:
void DoSomethingSpecial()
{
    DoSomethingElse();

    // Do stuff based on DoSomethingElse's success
    Console::WriteLn( "Success!" );
}

void LoopOfCode()
{
    try
    {
        while( true )
        {
            DoSomethingSpecial();
        };
    } catch( Exception:: SpecialFail&& )
    {
    }
}


The above C++ snippet performs the exact same operation, except now no conditionals are needed. We've traded off the two conditionals per loop for the entry/exit code for the try/catch block. But the block is outside the loop, so it will be run only once. Conditional checks are one of the slower operations on almost any CPU design, which means if the loop is a busy one which spins frequently this C++ code will certainly be a significant speedup over the plain jane C version. And that's just with one return code. Adding multiple exception handlers doesn't impact performance at all, so in a case where there are multiple return codes the C++ exception handling approach shines even brighter.

... thus dies the age-old rumor that C++ is slower than C. IT's all in how you wield your sword. Or... well... programming language.

Edit: I should add that the basic theory of optimization I'm using here is what I call "optimizing for the common case." It's a process of speeding up the code that's being run more frequently (which in our example above is a typically error-free running loop) by offloading the logic to an area of the code that's run much less frequently (the exception handler's entry/exit overhead). It's one of the most powerful optimization techniques any programmer can employ.

You are here: Home Developer Blog