11-29-2015, 01:39 AM -
I don't think it's mandatory to have background in emulation or reverse engineering, I hadn't ; some parts are easier to simulate without knowing too much of the internal.
For instance RSX is "moreless" a traditionnal desktop gpu and thus if you have some experience with OpenGL 3 or DirectX 10 it's not that hard to understand what is happening on the command queue, and where the emulation is inaccurate.
For some others parts there are docs online. For instance Cell's PPU is using PowerIsa 2.06 which is documented by IBM. Sony also provides public doc for the SPU. Since the Cell was intended to be sold in consumer electronic device in the longterm they share the manuals.
While "easier" PPU and RSX emulation still requires some experience in C++ and I wouldn't recommend working on them to learn a language.
On the other hand they are some area that are not related to emulation but that requires some work, GUI is one of them. RPCS3 GUI is fine but there are some bugs (games removal doesn't work with master, the Graphic backend is not properly destroyed when a game is exiting...) and above all it lacks debug tools.
The right panel doesn't work as far as I know, it was likely designed as an instruction debugger (similar to gdb or MSVC dbg tool) but the functions are not implemented. Plus I suspect that to be really usefull it would need to support several threads and not just one.
If you have time and patience implementing an instruction debugger would be a very good entry point to rpcs3. It will allow you to see several part of the project (the ppu/spu decoders, the thread management system) and give a good understanding of what is done.
Another area is removing some dependencies on wxWidget. In Emucore project (which contains all emulation logic) some files uses data structure from wxWidget ; this ties rpcs3 to wxWidget and thus we can't propose rpcs3 variant for platform not covered by wxWidget. It's also not good practice to let a non GUI codebase depends on a GUI toolkit. It's probably a good entry point since this require to find replacements for dependencies and eventually implement some (easy) algorithm. It might be tedious though.
Another area of improvement is documentation. A lots of our functions are not documented. I'm personnaly not fond of documenting for the sake of it but some functions have non immediate side effects or their arguments are mysterious. It's not really about writing C++ but more about reading it though.
There are also non C++ related task, like moving PPU Recompiler tests in a separate program in Visual Studio and make sure it's run in cmake/appveyor.
For instance RSX is "moreless" a traditionnal desktop gpu and thus if you have some experience with OpenGL 3 or DirectX 10 it's not that hard to understand what is happening on the command queue, and where the emulation is inaccurate.
For some others parts there are docs online. For instance Cell's PPU is using PowerIsa 2.06 which is documented by IBM. Sony also provides public doc for the SPU. Since the Cell was intended to be sold in consumer electronic device in the longterm they share the manuals.
While "easier" PPU and RSX emulation still requires some experience in C++ and I wouldn't recommend working on them to learn a language.
On the other hand they are some area that are not related to emulation but that requires some work, GUI is one of them. RPCS3 GUI is fine but there are some bugs (games removal doesn't work with master, the Graphic backend is not properly destroyed when a game is exiting...) and above all it lacks debug tools.
The right panel doesn't work as far as I know, it was likely designed as an instruction debugger (similar to gdb or MSVC dbg tool) but the functions are not implemented. Plus I suspect that to be really usefull it would need to support several threads and not just one.
If you have time and patience implementing an instruction debugger would be a very good entry point to rpcs3. It will allow you to see several part of the project (the ppu/spu decoders, the thread management system) and give a good understanding of what is done.
Another area is removing some dependencies on wxWidget. In Emucore project (which contains all emulation logic) some files uses data structure from wxWidget ; this ties rpcs3 to wxWidget and thus we can't propose rpcs3 variant for platform not covered by wxWidget. It's also not good practice to let a non GUI codebase depends on a GUI toolkit. It's probably a good entry point since this require to find replacements for dependencies and eventually implement some (easy) algorithm. It might be tedious though.
Another area of improvement is documentation. A lots of our functions are not documented. I'm personnaly not fond of documenting for the sake of it but some functions have non immediate side effects or their arguments are mysterious. It's not really about writing C++ but more about reading it though.
There are also non C++ related task, like moving PPU Recompiler tests in a separate program in Visual Studio and make sure it's run in cmake/appveyor.