PCSX2 Documentation/The PCSX2 Program Flow
The following article is a very general overview of the flow of the PCSX2 application.
AppMain.cpp - this is where the fun begins!
There is a lot that happens under the hood with wxWidgets. We don't need to worry about that. All we need to worry about is this this line of code:
in AppMain.cpp
<source lang="cpp">IMPLEMENT_APP(Pcsx2App)</source>
This macro tells the wxWidgets framework that we want to fire up Pcsx2App. Easy, right?
Pcsx2App - the part we care about
Next, Let's take a look at this code here.
in App.h
<source lang=cpp>
class Pcsx2App : public wxAppWithHelpers{}
</source>
You can see here that the Pcsx2App class is an extension of the wxAppWithHelpers class. WxWidgets applications are defined as classes, which are instantiated into an object when we start the program. Pcsx2App contains methods that wxWidgets is going to call upon at various times. So what gets called when we fire up Pcsx2App? That would be OnInit(). Let's take a look, I have written some notes on what happens here:
in AppInit.cpp
<source lang="cpp">
bool Pcsx2App::OnInit()
{
/* Enable logging, and write some stuff to the PCSX2 console.
- /
EnableAllLogging(); Console.WriteLn("Interface is initializing. Entering Pcsx2App::OnInit!");
InitCPUTicks();
pxDoAssert = AppDoAssert; pxDoOutOfMemory = SysOutOfMemory_EmergencyResponse;
g_Conf = new AppConfig();
wxInitAllImageHandlers();
Console.WriteLn("Applying operating system default language..."); i18n_SetLanguage( wxLANGUAGE_DEFAULT );
Console.WriteLn("Command line parsing..."); if( !_parent::OnInit() ) return false; Console.WriteLn("Command line parsed!");
i18n_SetLanguagePath();
- define pxAppMethodEventHandler(func) \
(wxObjectEventFunction)(wxEventFunction)wxStaticCastEvent(pxInvokeAppMethodEventFunction, &func )
Connect( pxID_PadHandler_Keydown, wxEVT_KEY_DOWN, wxKeyEventHandler (Pcsx2App::OnEmuKeyDown) ); Connect( wxEVT_DESTROY, wxWindowDestroyEventHandler (Pcsx2App::OnDestroyWindow) );
// User/Admin Mode Dual Setup: // PCSX2 now supports two fundamental modes of operation. The default is Classic mode, // which uses the Current Working Directory (CWD) for all user data files, and requires // Admin access on Vista (and some Linux as well). The second mode is the Vista- // compatible \documents folder usage. The mode is determined by the presence and // contents of a usermode.ini file in the CWD. If the ini file is missing, we assume // the user is setting up a classic install. If the ini is present, we read the value of // the UserMode and SettingsPath vars. // // Conveniently this dual mode setup applies equally well to most modern Linux distros.
try { InitDefaultGlobalAccelerators(); delete wxLog::SetActiveTarget( new pxLogConsole() );
- ifdef __WXMSW__
pxDwm_Load();
- endif
SysExecutorThread.Start(); DetectCpuAndUserMode();
// Set Manual Exit Handling // ---------------------------- // PCSX2 has a lot of event handling logistics, so we *cannot* depend on wxWidgets automatic event // loop termination code. We have a much safer system in place that continues to process messages // until all "important" threads are closed out -- not just until the main frame is closed(-ish). m_timer_Termination = new wxTimer( this, wxID_ANY ); Connect( m_timer_Termination->GetId(), wxEVT_TIMER, wxTimerEventHandler(Pcsx2App::OnScheduledTermination) ); SetExitOnFrameDelete( false );
// Start GUI and/or Direct Emulation
// -------------------------------------
if( Startup.ForceConsole ) g_Conf->ProgLogBox.Visible = true;
OpenProgramLog();
AllocateCoreStuffs();
if( m_UseGUI ) OpenMainFrame();
(new GameDatabaseLoaderThread())->Start();
if( Startup.SysAutoRun ) { // Notes: Saving/remembering the Iso file is probably fine and desired, so using // SysUpdateIsoSrcFile is good(ish). // Saving the cdvd plugin override isn't desirable, so we don't assign it into g_Conf.
g_Conf->EmuOptions.UseBOOT2Injection = !Startup.NoFastBoot; SysUpdateIsoSrcFile( Startup.IsoFile ); sApp.SysExecute( Startup.CdvdSource ); } } // ---------------------------------------------------------------------------- catch( Exception::StartupAborted& ex ) // user-aborted, no popups needed. { Console.Warning( ex.FormatDiagnosticMessage() ); CleanupOnExit(); return false; } catch( Exception::HardwareDeficiency& ex ) { Msgbox::Alert( ex.FormatDisplayMessage() + L"\n\n" + AddAppName(_("Press OK to close %s.")), _("PCSX2 Error: Hardware Deficiency") ); CleanupOnExit(); return false; } // ---------------------------------------------------------------------------- // Failures on the core initialization procedure (typically OutOfMemory errors) are bad, // since it means the emulator is completely non-functional. Let's pop up an error and // exit gracefully-ish. // catch( Exception::RuntimeError& ex ) { Console.Error( ex.FormatDiagnosticMessage() ); Msgbox::Alert( ex.FormatDisplayMessage() + L"\n\n" + AddAppName(_("Press OK to close %s.")), AddAppName(_("%s Critical Error")), wxICON_ERROR ); CleanupOnExit(); return false; }
return true;
} </source>
WxWidgets Frames
In addition to Application classes, there are also Frame classes. So when we call the OpenMainFrame function, what happens? Take a look at this code:
in pcsx2/gui/AppInit.cpp
<source lang="cpp">
void Pcsx2App::OpenMainFrame()
{
if( AppRpc_TryInvokeAsync( &Pcsx2App::OpenMainFrame ) ) return;
if( GetMainFramePtr() != NULL ) return;
MainEmuFrame* mainFrame = new MainEmuFrame( NULL, pxGetAppName() );
... } </source>
Here we're creating an instance of the MainEmuFrame class. That class contains members for all the cool GUI elements, buttons, menus, stuff like that. So let's take a step further. Suppose we want to boot up a game. When we select Boot DVD in the pcsx2 menus, we are calling upon this function here:
in MainMenuClicks.cpp
<source lang="cpp">
void MainEmuFrame::_DoBootCdvd()
</source>
Into The Core
OK, this is where things start to get a little complicated. PCSX2 is basically divided up into a few different parts:
SysExecutor
Handles the virtual machine
EE Thread
(See BiosDebugData.h) Handles the Emotion Engine instructions.