[Bounty] Create a pcsx2 core

[weirdbeardgame]

What would be required? rewrite PCSX2's plugin system to fit into Retroarch's core system adjust config files and pcsx2 settings to work with Retroarch adjust GUI config areas in pcsx2 to fit with Retroarch's quick menu

[i30817]

I think it's far more likely that dobiestation or some other emulator gets a port than pcsx2. It would be a incredible burden to port and redesign the plugin system to retroarch and you wouldn't have the benefit of getting upstream commits. It would be the hardest of hard forks.

Granted dobiestation is a toy emulator, being a one man show, but i still consider it more likely. Maybe i'm exaggerating, mupen has a retroarch port and it's plugin based. Not sure though.

[weirdbeardgame]

@i30817 Actually dobiestation has several contributers at this point, and whilst yes it would be a chore and a half i still think pcsx2 would be our best bet for now to get a compatible working ps2 core in RetroArch aside from play! or in the future DobieStation

[i30817]

Uh, interesting that refraction is contributing commits to dobiestation. One ps2 emulator was not enough.

[anothername99]

Perhaps look into Orbum: https://github.com/marco9999/orbum

It's a rewrite of PCSX2. It should be more portable than mainline PCSX2.

Also, a hardware renderer is more of a nice thing to have than something actually necessary. PCSX2's software renderer provides perfectly playable speeds in most games and it's the most accurate option.

[orbea]

I think step 1 is to fix the 64-bit build upstream and make sure -fPIC is entirely supported.

[natehaxx]

I think step 1 is to fix the 64-bit build upstream and make sure -fPIC is entirely supported.

its already fixed on the newest Play Forks ... Emulation runs now on the Nintendo Switch slow but it runs

[Zer0xFF]

I am considering looking into this bounty, however for Play!.

however, I want to confirm the validity of this, as the paragraph for Play! isn't encouraging.

Note: Play! though not preferred would be an acceptable alt if someone wants to do that,

[Zer0xFF]

@twinaphex thanks for the reply, but it didn't really address my question, the issue was original opened for PCSX2, but then Play! was added as an acceptable alternative, though the wording for that is somewhat discouraging, so I want to confirm if a core for Play! will indeed be accepted for the bounty? (as I believe the issue has to be closed for the bounty to be processed?)

as for your comments.

• the code will be pushed out
  • and no CLA is in place at the moment (while I don't foresee a CLA in the future, (1) its does not apply retroactive, (2) so my work regarding the core remains true, (3) should Jean (emu owner) does purse it, its his choice, but I don't see it having a bearing on this bounty as per point (1) and taking that into account, this could apply to ALL current cores, so not really my issue in the future) ()
• in the case of Play! license is MIT, and since there is no CLA in place, relicensing isn't a choice I even have (nor will I be able to obtain since I'm not the project owner XD)

[inactive123]

Hi @Zer0xFF, sorry for maybe confusing you. This was not related to Play!, more to somebody else who offered to fulfill this PCSX2 core bounty.

I'd also like to see a Play! core bounty, but ultimately the bounty backers decide. A vote could be done. Personally I'd still think it's best that Play! gets its own separate bounty, since I think we'd like to see both, but it's of course unreasonable to have that be part of the same bounty. But like I said, we can let bounty backers decide.

[Zer0xFF]

Thanks for the reply.

Well I presume, they only way backers can decide is after the bounty is fulfilled? in such case, I'm afraid, I will not be taking this on, since my main reason for doing this is the financial compensation, if this can be done ahead of time that'd be great.

[inactive123]

I believe it might be best if we built up a separate core bounty for Play! and we bring that to the level of $300 and then make that grow from there. To reiterate, I'd like to see both get a libretro core, but I understand that can't be done with one single bounty.

[Zer0xFF]

I believe it might be best if we built up a separate core bounty for Play!

I agree, and I've foreseen the inevitable confusion in this case, which is why I decided to ask 1st.

[inactive123]

Hi there @Zer0xFF,

please contact me at libretro@gmail.com. I might have a proposal if you're interested.

[inactive123]

I reached an agreement with @Zer0xFF to do a Play libretro core. This will be done outside this bounty.

So this bounty can instead be strictly dedicated to PCSX2 now. Play! will be taken care of outside of this bounty.

[Specced]

That´s good news! Happy coding!

[c4pt000]

you realize there is a dolphin pcsx2 wrapper for retroarch to load pcsx2 titles ?

[c4pt000]

@op https://github.com/coldscientist/libretro-pcsx2-launcher

[c4pt000]

I was just editing this about a week ago for better integration into retroarch

[c4pt000]

https://github.com/c4pt000/libretro-pcsx2-launcher

^ whats it worth to you? $650 ?

[inactive123]

Umm, it needs to be a real libretro core. A launcher core really is not going to do and wont be accepted.

[ddg00101]

This issue seems to have gone stale. I would love to be able to play ps2 games on my switch, and pcsx2 seems like the best bet for this since it has dealt with more of the compatibility issues already. Play! is interesting, but needs a great deal more work still for most games. I'd be more than willing to kick in money personally. Not sure how to officially do this though? I'd be fine with $500-$1k depending on what the true complexity and time would be. I'm not sure how much is already 'in the pot' so to speak. Hell, keeping a monthly maintainer to merge code in from upstream if it can't be easily merged regularly would be fine with me on top of that.

[DukeSkinny]

I'd be more than willing to kick in money personally. Not sure how to officially do this though?

@ddg00101 Here's the issue on BountySource, where you can contribute if you so wish. A bit late, but hopefully you'll see this and are still interested.

[GovanifY]

I figured I might as well update this issue, even though there's a long road ahead. I began merging pcsx2 plugins into its core, with the goal of merging all of them ASAP. The idea is after that to eventually have a clean core/gui separation, which would allow "easily" a retroarch port by this point; the scope out of retroarch is to eventually drop the WxWidgets GUI and get a new, cleaner one, probably Qt based.

With that said there is a high probability that only x86_64 builds will get a JIT on retroarch, since the 32 bit JIT basically makes PIE impossible, which I assume is a requirement for retroarch libraries. Of course pcsx2 new 64bit JIT isn't even finished yet.

No ETA for this as it requires rewriting most of pcsx2 codebase in major ways but I've already merged the CDVD and FW plugins, so 2/7. This is available in master.

The end goal will be to have everything into master to avoid having yet another fork.

[hizzlekizzle]

@GovanifY that's really exciting news! Thanks for the update :)

[inactive123]

Great to hear there's an interest in this. For now if it helps you get to a POC stage faster, you can focus on x86_64 for now. Hopefully the 64bit JIT is not too bad at this point. Later on we could re-evaluate it if 32bit is also possible, but best to focus on a realistic target for now.

[ghost]

Haha, it's hilarious!

Half a year ago I've spent a week working on a clean-slate rewrite of the jit, targeting amd64 and aarch64, and have had to scrap the work due to some nutcase embarking on a months-long crusade of hacking the existing jit to do amd64. It's not that I hated being one-upped, it's just that for the entire summer the codebase was as volatile as Nitroglycerin, precluding any meaningful work on my part. Now pcsx2 has 64-bit EE and IOP recs that are roughly twice slower than that they have any right to be.

Now it's more of the same: the same week I revisited the issue, spending some 16 hours to untangle the core's dependency graph, some other nutcase has just decided that it'd be nice to open the road for even more nutcases to break the plugins encapsulation and smear them all over the core, as if it isn't a fucking nightmare already.

Well, I've lost any shred of hope for those guys, so I'm starting my own fork. Because that's how and why forks are made - to have a comfortable codebase that doesn't turn to a fucking warzone overnight.

[TellowKrinkle]

Half a year ago I've spent a week working on a clean-slate rewrite of the jit, targeting amd64 and aarch64, and have had to scrap the work due to some nutcase embarking on a months-long crusade of hacking the existing jit to do amd64. It's not that I hated being one-upped, it's just that for the entire summer the codebase was as volatile as Nitroglycerin, precluding any meaningful work on my part. Now pcsx2 has 64-bit EE and IOP recs that are roughly twice slower than that they have any right to be.

If it's a clean slate rewrite, why would it be affected by changes to the current one? And while there was all sorts of changes happening on the x64 work branch, the final merge was fairly clean and changed little. That was the plan from the beginning, so if you were worried about it, you could have asked on the PR thread and we would have said so. Same goes for the plugin to core merge, if you're working on a JIT you shouldn't have to touch any of the things touched by those merges, and can just ignore them.

In general, I would recommend that if you plan to make big changes to anything, that you make a fork from the start. Don't bother trying to stay up to date with master until you're ready to PR.

[GovanifY]

Now it's more of the same: the same week I revisited the issue, spending some 16 hours to untangle the core's dependency graph, some other nutcase has just decided that it'd be nice to open the road for even more nutcases to break the plugins encapsulation and smear them all over the core, as if it isn't a fucking nightmare already.

Thank you for the kind words dear stranger, now if you may allow me to speak: this whole "plugins smeared all over the core" is done for a reason: splitting core, old gui, new gui etc makes the application much easier to port and straightforward overall. Unless you're blind the dependency graph is basically lessened as plugins callbacks existed in the main codebase, and you can follow them into their respective folders. As tellow so kindly pointed out, if you want to work on something just ping us, exchange ideas, possibly open an issue or a draft PR to show people this is a thing. That's a concept that might be unknown to you but is actually crucial to FOSS development. It is called "collaboration". That is if any of what you said is true, which I am going to highly doubt seeing the contents of your GitHub account and how recently it was created.

Excuse me for the condescending tone, but I've had enough about people smearing over other's work by principle. And I'm not talking about just mine.

[inactive123]

My bad, I read that previous exchange between you two guys wrong.

@GovanifY for this libretro core you're preparing, is both Linux and Windows support planned?

[GovanifY]

@GovanifY for this libretro core you're preparing, is both Linux and Windows support planned?

Definitely. I am reiterating that this will take some time to go there and I'm prioritizing work on the core of pcsx2 over retroarch for now. I don't want to promise anything, so we'll see once we get there, but there's no reason for me not to support at least Linux and Windows

[aliaspider]

https://github.com/aliaspider/pcsx2 this is still a very early WIP, but since it kinda runs on linux already, I thought I would share it. windows isn't supported yet. to try it out you need to first build the standalone version

mkdir build
cd build
cmake ..
make install

the output will be in the bin directory in the root folder. launch the stand-alone version and make sure you can run games with it. after that copy the bin directory to your retroarch system dir as path/to/system/pcsx2. next build the core itself

mkdir build-libretro
cd build-libretro
cmake .. -DLIBRETRO=ON
make

as I said, this is still a very early work in progress, so expect a lot of bugs/crashes etc. the code itself contains a bunch of hacks at the moment to get things going and requires a lot of cleanups until it is ready.

@GovanifY sorry I didn't realize that you were also working on this until I was done xD

[GovanifY]

@aliaspider not a big deal, although pcsx2 codebase is currently undergoing huge changes. I'd wager it'd be safer to wait until we finish at least merging the plugins and splitting the core/gui base fully until you continue to work on it, if you so wish, unless you want another hard fork with development efforts split, which I'd rather avoid as a PCSX2 contributor.

[aliaspider]

most of the libretro specific code can be easily rebased on top of any refactors that are made upstream so that shouldn't be an issue at all, and besides the hard part is already done anyway.

it is cool to hear though that you are planning to split the core/gui, since that would make a shallow fork finally a possibility. I don't like messing with the core code much so my plan right now is to minimize that as much as possible, most of it can't be avoided though due to tightly it interacts with wxwidgets.

hopefully at some point I can get something that integrates nicely with the main codebase.

[GovanifY]

Well that was the plan before you came in with your fork to be fair, it would have simply taken more time since, surprisingly, it wasn't on our immediate priority list :p

My idea was to integrate it into the master branch directly to avoid a fork, which is still going to happen probably, hence why I told you to probably wait. I can definitely tell you most of your work, notably on the FakeThread, won't be rebased easily at all. A mostly whole project code refactor will happen during the core/gui split, and would probably require you reprogramming from scratch entire parts of your fork.

I'm not after the bounty myself so I do not care about who gets to do what, I'd just rather wait if possible for that single reason(the refactor) tbh, but I'm not going to actively try to oppose your fork in any way, it's just bad timing to be fair.

[aliaspider]

the code is in no way final. and I still don't see why it is a bad timing or hard to rebase but ok. besides I'm the one who will do the rebase anyway so :)

[aliaspider]

some updates: added windows support and implemented the most important features. there are still a few issues left to deal with and but the core should be relatively useable by now.

compilation should also be a bit simpler. (no need to compile standalone first)

mkdir build-libretro
cd build-libretro
cmake .. -DLIBRETRO=ON -DCMAKE_BUILD_TYPE=Release
make

for windows you need to run cmake --build . -- -p:Configuration=Release instead of make for the last step.

you can get a precompiled windows binary from here: https://github.com/aliaspider/pcsx2/releases/download/v0.1-libretro/pcsx2_libretro.7z just copy the system folder and core to the correct locations, and copy your ps2 bios to system/pcsx2/bios

[inactive123]

Thanks for the update.

[Ether009]

@aliaspider I cannot get those precompiled bins to work. Stable does not even identify that this is a core. Nightly does, but x86 version when trying to load the core outputs [ERROR] Failed to open libretro core: "D:\Userdir\Downloads\RetroArch (1)\cores\pcsx2_libretro.dll" [ERROR] Error(s): %1 is not a valid Win32 application. while if I use the x86_64 nightly, I instead get [ERROR] Failed to open libretro core: "D:\Userdir\Downloads\RetroArch (2)\cores\pcsx2_libretro.dll" [ERROR] Error(s): The specified module could not be found.

So it seems that x86_64 nightly would be the required retroarch version, but it does seem to still be missing some dependency although it makes no mention of what that would be. It could be the bios, but you make no mention of which bioses would work, or what to name it. Could that be the module it's missing? Which should I put there, and named what? Or is it some mingw or cygwin library it needs or something?

Awesome work btw. Cant wait to get this working right. Last stand alone emu I use to finally be scrapped :)

[Joshndroid]

some updates: added windows support and implemented the most important features. there are still a few issues left to deal with and but the core should be relatively useable by now.

compilation should also be a bit simpler. (no need to compile standalone first)

mkdir build-libretro
cd build-libretro
cmake .. -DLIBRETRO=ON -DCMAKE_BUILD_TYPE=Release
make

for windows you need to run cmake --build . -- -p:Configuration=Release instead of make for the last step.

you can get a precompiled windows binary from here: https://github.com/aliaspider/pcsx2/releases/download/v0.1-libretro/pcsx2_libretro.7z just copy the system folder and core to the correct locations, and copy your ps2 bios to system/pcsx2/bios

thank you for your awesome work. I tried this in retroarch playtest (steam) and just get a black screen. The sound works so i know it loads. used a bios listed in here - same issue https://docs.libretro.com/library/pcsx2/ made sure i had visual c++ 2019 as within here - sa,e issue https://github.com/libretro/pcsx2

Am i doing something wrong?

[countfistula]

I did some searching around forums and this thread but didn't find anything, so I apologize if this has been asked already. I'm brand new to Github and the whole concept of "binaries", "source code" etc. are an alien language to me. I intend to learn a lot and I'm currently in school going for a degree in IT (I just started).

With all that said, can anyone tell me what files from this project I need to download in order to attempt using it with RetroArch on my Raspberry Pi 4? I've been tinkering with it and having a lot of fun learning Linux command line stuff, but the second I look at this big list of folders and files I feel completely overwhelmed.

[TellowKrinkle]

With all that said, can anyone tell me what files from this project I need to download in order to attempt using it with RetroArch on my Raspberry Pi 4?

PCSX2 currently requires an x86 (Intel or AMD) processor, which the RPi4 doesn't have. Don't expect this to change anytime soon.

[Jessomadic]

@tellowkrinkle How about a UWP file. Seeing as the Xbox One line of consoles use a CPU based off of AMD Athlon

[colejd]

@GovanifY do you have a link to a PR or something to track the rewrite / work separating the GUI from the core? How close would you say you are to clearing @aliaspider to continue without needing to do a huge rebase?

[GovanifY]

@colejd The work will begin once the last plugin (GSdx) has been merged, you can track the progress of this one here: https://github.com/PCSX2/pcsx2/discussions/4100

I never forbid aliaspider to continue, he can do so if he so wish, but there's already a non trivial effort required to rebase the core on the master branch because of how much changes have happened.

[RyanBram]

Finally PCSX2 is pluginless 🎉 https://github.com/PCSX2/pcsx2/pull/4436

Thank you very much for PCSX2 Dev Team.

[aliaspider]

so, finally got around to finishing this up. resolved most issues with the previous version and rebased on latest upstream. https://github.com/aliaspider/pcsx2

this is a precompiled windows binary if someone wants to test it: https://github.com/aliaspider/pcsx2/releases/download/v0.2-libretro/pcsx2.7z

make sure to copy the resources directory from the source bin folder to <retroarch system folder>/pcsx2

Edit: there seems to be a bug in atm where it refuses to load the core with the error "The specified module could not be found" unless libzstd.dll is present, so either use a mingw release, or copy that file from one to the same folder as retroarch.exe

[gouchi]

I tested it quickly on Linux and it is working.

Thank you !

[aliaspider]

solved the above mentioned .dll problem and some minor issues :

https://github.com/aliaspider/pcsx2/releases/download/v0.4-libretro/pcsx2.7z

[i30817]

It can't seem to find tls here (ubuntu 22.04) which then crashes when starting any game. edit: this has nothing to do with ssl. The crash is:

Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault.
__tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:33
33  ../sysdeps/x86_64/tls_get_addr.S: No such file or directory.
(gdb) bt
#0  __tls_get_addr () at ../sysdeps/x86_64/tls_get_addr.S:33
#1  0x00007fffa82179c4 in IConsoleWriter::GetColor() const (this=0x7fffa853fba0 <Console>) at /home/i3/Downloads/pcsx2-git/common/Console.cpp:327

mmh, that makes no sense. It's called on getting a color for the console. (to solve a warning i had to pass cmake .. -DLIBRETRO=ON -DENABLE_GNUTLS=ON, although note that this 'tls' is 'thread local storage' not 'transport layer security'. So nice to see things using the same acronyms). Might be because it's the first call to thread local storage.

might have something to do with the output shown just before: Code Memory Manager: host memory @ 0x00007FFFF4000000 -> 0x0000800007100000 is unavailable; attempting to map elsewhere...

This is in color btw, so obviously writing to stdout in color is working... or maybe 'was' until it tried to move LOL.

[MistyDreams]

I had no issues compiling on manjaro with

 -DLIBRETRO=ON -DCMAKE_BUILD_TYPE=Release -DENABLE_QT=OFF -DCMAKE_LINK_WHAT_YOU_USE=TRUE