Understanding the Source Code (or trying to)

[mtmarco]

Hello. I'm trying from Yesterday to read and understand the source code, to get into the argument and understand how the emulator works.

But i need more info about the architecture of the emu:

(for now i'm following Windows source files)
1-> Starting from "Windows\main.cpp" i've found the WinMain start process, and various calls to the ini config load/save class, os version check etc., ending in the message pump OK; but basically from there we call MainWindow::Init;

2-> So we go to Windows\WndMainWindow.cpp; here (looking quickly) i can see there is, mainwindow initialization, wndproc callback to manage all events (menu, commands, resize, etc.) and I focalized on BrowseAndBoot()/BrowseAndBootDone() functions, that would load a rom and start emulation --> ending into NativeMessageReceived("boot", filename.c_str()); ---> so we are sending a message to Native framework to start emulating that file??;

3-> for how hard I searched where exactly we end up to read this message and start emulation, I could not find a sure/exact point... but for what i can understand in the entire solution, i think we end in "UI\EmuScreen.cpp"->class EmuScreen function sendMessage (EmuScreen::sendMessage), and from here in case of message "boot" we end up in bootGame(string filename):
here we configure coreParam object, and then we launch PSP_InitStart(coreparms,err_string) and PSP_InitUpdate function;

4-> This ending into Core\System.cpp: function PSP_InitStart() and PSP_InitUpdate(), in these methods I can see we call CPU_Init(); and GPU_Init();

5-> now we go into 2 different sourcefiles:
-> for CPU_Init() we remain into System.cpp, and in that method as I can see, we basically start up CPU emulation: we set some parameters, then some modules are started: Replacement_Init();Memory::Init();host->AttemptLoadSymbolMap();Audio_Init();CoreTiming::Init();HLEInit();if (!LoadFile(filename, &coreParameter.errorString)) {...} and we add to recent files the currently executed rom;

-> for GPU_Init() we end to GPU\GPUState.cpp, and in this method we switch case the type of GPU from: NullGPU,GlesGPU,SoftGPU, or DX9GPU, doing a SetGPU(T*obj) method that ends in specifing GPU Interface into a more specific GPU class

6 -> here i'm getting lost: i've tried to manipulate output randomly messing up the PixelShaderGeneratorDX9.cpp, thinking this was the display output generator for a Windows PC with dedicated GPU (thinking the switch will chose DX9GPU), but from some test i saw no result in games, modifying boolean values into ComputeFragmentShaderIDDX9(id); so i tried with changing the same code in the FragmentShaderGenerator.cpp from GLES GPU class, but no result the same as before;
So i understand that our software when executed on Windows pc, is not going through those portions of code: i'm sure our software is going through all the classes/methods/functions till the point 5, then i'm getting a bit lost... it's just a bit difficult to understand a so big source from 0, moreover with all these implicit calls/message exchanged.

7 -> in the end I've ended in GPUCommon.cpp, and i think our emulator is specifing the GPU class into the Common one (not the DX9 nor the GLES, that obviously is for mobile); unfortunately if I want to test my presence in a portion of code, if till the EmuScreen i could use OnScreenMessages.h (osm.show) or Windows.h (MessageBox), from System in advance I can't (headers not included), so to verify if i'm in those methods, i've used a little ugly thing: fopen(file,"w") of a new empty specific file(thinking the debug console isn't working with printf cause we are in a win32 app).... and ive discovered that the software go into gpucommon.


This for the GPU part, while for the CPU part i've not read much more code, but I only suppose that there (in the CPU part) we have the instruction translation (elf reading, relocation or what has to be done to get the instruction disassembled and reexecuted), and at the end of the process the execution of the correct task (audio/video/etc); in the GPU part we come to only after the translation, when we have a GPU minimal instruction to render, and so as I can see/guess in the Specific GPU classes we have specific methods for the particular GPU rendering system (dx, opengl, soft,null), that render Lights, fogs, polygons, blend, and all other effects/models... or at least generate parameters for the following rendering....

Ok now this last part is mostly my assumption, so my question is: from the point 5 in advance what does really happens??:
CPU_init() basically with which class/sourcefiles connects and what pactically does? And where does GPU_init() hook/end up?

Where and with which logic after we boot a Game, the system starts the ISO reading, elf/bin decoding/disassembling, and then in which methods the instructions are reinterpretated and redirected to the correct function; from this cpu-side elaboration how we will reconnect to the gpu side, and where we actually transfer the output to the directx device (in Windows case at least, using d3d*.h headers, and d3d rendering classes).

Thank you in advance Sorry if i've been too long, but I want also to "contribute" if I can; i really wanted to play Silent Hill origins, only to found annoying flickering starting the game, so i wanted to check into the source what call was causing this.... and also i have a snapdragon 800 smartphone with GLES 3 adreno 330 gpu (samsung galaxy Note 3), with not so high performance as expected with ppsspp on android, and so i want to see also this... But apart from these specific cases, I want to understand the code/architecture, and in the forum/site I can't find much informations; so I'm asking some help to you

It would be very useful if we could get more info, to work all together, understanding better where to put our hands Sorry if I ask all this to you, but it's very very difficult to understand the Whole code without the help of who has already deal with it from the very start; however thanks for every help. (Also a basic scheme would be good)
Another thing, sorry for my (very)baddd english, i'm italian

Bye, Marco