Incorporate SPU2-X into core
#1
Hello, PCSX2 Team.

As a person who would like to help PCSX2, I want to ask you guys something.

I would like to know if it would be useful to put SPU2-X features into PCSX2's core. As I have a lot to learn about programming, I wanted to know what things could make really talented people to be motivated to join this Project, along with the other talented developers here.

Why this?
For somehow, I see people not being encouraged enough to help develop PCSX2. They say that some things are hard to find in code and other stuffs. By that, one
thing that I can identify is the plugin architecture. Which is fair. And, as much as some people don't think that that way (not me, I'm a Dolphin fan), some things don't really need to be in plug-ins:
 * if the code is clean, there is not room for the "I just wanna mess with X feature" talk;
 * the things that the plug-ins provide are part of the
system machine (the PS2), not an isolated feature, like a shader pack, which means they should be in the main application;
 * although there are a variety of plugins, most people use the same ones, and the others don't seem to have advantages like accuracy or debug capabilities;
 * give a standart to the emulation development can be a starting point to performance boost and further understanding of the console hardware itself, leading to other improvements (ok, I'm dreaming, but again, see Dolphin's history)

So I thought, maybe it could be a good way to start to do these "boring" stuffs and leave the hard work for the core team. Again, no badass programmer talking. So I looked for an "easy" start, like removing D3D9 dependencies for Gsdx, merging GUI options for EE-related things, and then this idea for SPU2-X came out.

So, what do you guys think? Nice, nonsense?

Best regards,
Reply

Sponsored links

#2
not really a priority Tongue2
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Reply
#3
From a coding point of view building a project modular in sub projects is IMO the best you can do.
I am currently implementing a 'universal' (Laugh that probably doesn't exist) laboratory acquisition software currently containing ~45k hand written non-whitespace lines split into 38 subprojects (-> 3 .exe + 35 dll's) and it is really nice to handle. You don't build stupid cross references and can keep OOP extremely clean. Compilation time is much smaller and module tests are easy.

I would even split pcsx2 in more subelements and for example outsource components like ee and vu instead of creating a huge blob of code.

Creating many subprojects forces you to write nice clear interfaces and imo increases readability and maintainability a lot.



Full compilation time for pcsx2 currently takes on my weak media pc cpu some minutes (maybe ~10-15). If I now want to change a small thing in spu2-x I need to wait again this time if I am building a clean build. SPU2-X compilation time is much smaller.
Also somebody working on the core would need to recompile SPU2-X everytime he changes something.
Reply
#4
(11-10-2015, 12:17 PM)willkuer Wrote: Full compilation time for pcsx2 currently takes on my weak media pc cpu some minutes (maybe ~10-15). If I now want to change a small thing in spu2-x I need to wait again this time if I am building a clean build. SPU2-X compilation time is much smaller.
Also somebody working on the core would need to recompile SPU2-X everytime he changes something.

This is one of the neat advantages of the Plugin system Smile , back when I only had a core2duo it was easier to allow compilation of just the GSDX plugin in case of GSDX changes to save time whereas a clean full compilation took around 12-17 minutes on it.
We're supposed to be working as a team, if we aren't helping and suggesting things to each other, we aren't working as a team.
- Refraction
Reply
#5
Quote:So I thought, maybe it could be a good way to start to do these "boring" stuffs and leave the hard work for the core team. Again, no badass programmer talking. So I looked for an "easy" start, like removing D3D9 dependencies for Gsdx, merging GUI options for EE-related things, and then this idea for SPU2-X came out.

So, what do you guys think? Nice, nonsense?
From a programming PoV, incorporate SPU2x into the core is equivalent to build SPU2x as a static library. So the only differences are
1/ Lib is hardcoded, so no option to select it.
2/ you save 2/3 instructions every time you call the DLL API functions. (perf impacts is null on MFLOPS cpu).
3/ You miss the possibility to change the plugin (help to detect the source of a crash, detect dll incompatibilities on linux)
4/ No more debug capabilities (for example you can run GSdx as a standalone application).

Globally plugins have barely any impact on the code base (yes it just remove an indirection on a couple of functions). It is mostly a build option matter. On Linux all applications depends on various .so (even Dolphin). On Windows, there are statically linked. It just a matter of Politics, nothing more.
Reply
#6
(11-12-2015, 01:46 PM)gregory Wrote: It just a matter of Politics, nothing more.

Well said.
[Image: XTe1j6J.png]
Gaming Rig: Intel i7 6700k @ 4.8Ghz | GTX 1070 TI | 32GB RAM | 960GB(480GB+480GB RAID0) SSD | 2x 1TB HDD
Reply




Users browsing this thread: 1 Guest(s)