(03-05-2014, 10:52 PM)shadow Wrote: (03-05-2014, 09:13 PM)AlexAltea Wrote: Heh, but aside from that, I have to say that I use PPSSPP as my main reference, not only because I prefer C++, it's just that its code is very nice structured and some parts of it could be entitled "This is how you write a good and clean emulator". Besides, my relationship with Java.. is... err... complicated. Don't ask me why, or I could break EmuNewz server with a 20GB rage post of raw text complaining about it and wishing death upon so many people at Sun Microsystems... I don't want to get banned for that.
Meh, too much work.
ppsspp as reference ? sad ;/
anway you can always wait for pspe4all emu coming from jpcsp coders (in c++ )
To be fair, PPSSPP is indeed a good reference for PSP research and documentation. But of course, JPCSP was the first to really tackle and reverse-engineer the PSP, so most of the it's code is poorly structured and most times subjected to several re-writes.
Like I've stated before, I see JPCSP as a good reverse-engineering and testing platform for PSP (whence why I still work on it, despite it's Java bound limitations).
It was thanks to the work done on JPCSP that PPSSPP could grow into a very efficient and structured emulator in such a short time.
With JPCSP we could actively test back and forth several PSP functions very quickly, specially since Java has very user friendly environments and fast compilation processes.
This doesn't mean PPSSPP is the pinnacle of PSP emulation and it also means PSPE4ALL could prove to be even more efficient and structured.
Anyway, back on topic, RPCS3 is also a high level emulator like JPCSP and PPSSPP, so their emulation process is identical.
It attempts to translate the functioning of several portions of the PS3 system without depending on any pre-compiled code parts (like a low level emulator).
This way, the reason behind the small speed hit in such emulators is directly linked to how they are coded and the only limitations are imposed by the user's computer.
A low level emulator on the other hand doesn't depend as much on specific computational resources, mainly because it already has pre-compiled code portions incorporated (e.g.: BIOS files).