Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libretro/RetroArch support #6

Open
kuba2k2 opened this issue Jun 10, 2024 · 7 comments
Open

Libretro/RetroArch support #6

kuba2k2 opened this issue Jun 10, 2024 · 7 comments

Comments

@kuba2k2
Copy link

kuba2k2 commented Jun 10, 2024

Hi,
I see that Libretro support has been removed in this fork. Do you plan for bringing it back at some point? If not, what is the reason for that?

@zb3
Copy link
Owner

zb3 commented Jun 10, 2024

I had no other choice, because I'd not have the energy and will to update and maintain these code paths and I didn't even know how these worked. I removed that so I could modify the FreeJ2ME class, that was a sacrifice I had to make in order to be able to finish this fork.

Currently I'm unable to update this further, ideally someone from the original FreeJ2ME project could help here, but I've done my part..

@kuba2k2
Copy link
Author

kuba2k2 commented Jun 10, 2024

I understand. Would you accept PRs to your repository if there are any, and/or have you considered submitting your work as a PR to the upstream repo? I will be building something based on Libretro at some point, maybe I'll be able to bring back the support in freej2me.

@zb3
Copy link
Owner

zb3 commented Jun 10, 2024

Would you accept PRs to your repository if there are any

If they're small enough that I can understand them :)

have you considered submitting your work as a PR to the upstream repo?

Initially I planned to contribute to the original repo by fixing bugs. Unfortunately, even the most basic PR that fixed searching for main class is still not merged, I guess they no longer have time to maintain the project.. That's why I forked the project and went "all in" to add stuff like M3G :)

I will be building something based on Libretro at some point, maybe I'll be able to bring back the support in freej2me.

Sounds interesting. I see that in the original integration, things were duplicated between the FreeJ2ME class and the Libretro class.. it'd be much easier to maintain if the same core worked for AWT and Libretro, and platform-specific code was only responsible for platform-specific things..

Anyway, wish you luck :)

@AShiningRay
Copy link

Initially I planned to contribute to the original repo by fixing bugs. Unfortunately, even the most basic PR that fixed searching for main class is still not merged, I guess they no longer have time to maintain the project.. That's why I forked the project and went "all in" to add stuff like M3G :)

Hey there, a bit off-topic here but... me and @vadosnaprimer have forked FreeJ2ME into TASEmulators/freej2me-plus with the intent of building off from where the main repo is, merging all PRs currently in there, as well as my own improvements that can't be made into PRs since they depend on other stuff already being merged. I noticed that you were still very active on your fork after submitting the "hex007#196" Pull Request and i'd like to ask you if you could send some of your changes into our fork as PRs there.

I could always cherry pick stuff from here, but i think it'd be better if you retained full authorship of your changes, seeing as you were still active rather recently. Given that we'd like to keep our fork as portable as possible, stuff like your m3g patch and anything that relies on external/native libs won't make the cut, but even your general improvements to FreeJ2ME's built-in classes would be greatly appreciated!

@zb3
Copy link
Owner

zb3 commented Sep 17, 2024

I could always cherry pick stuff from here

Go ahead! I see no problem with this, especially since I'm not a fan of so called "intelectual property". My changes are MIT-licensed, so they're for everyone to use, reuse and so on.

Note that this fork doesn't contain much original code, I mostly copied it from J2ME-Loader, my parts are only the ui support and these native bridges, all the rest is just copy-paste :D

Given that we'd like to keep our fork as portable as possible

For me, the only really portable platform is the web platform.. I once had the idea that the java part could work in browser via CheerpJ, however, native parts would require significant amount of work..

But if you plan to keep the fork java-only, then it should actually work with CheerpJ.. imagine having this on archive.org and being able to play j2me games directly there!
Wish you luck :)

@vadosnaprimer
Copy link

imagine having this on archive.org and being able to play j2me games directly there!

Oh god, that'd be incredible...

@AShiningRay
Copy link

Go ahead! I see no problem with this, especially since I'm not a fan of so called "intelectual property". My changes are MIT-licensed, so they're for everyone to use, reuse and so on.

Note that this fork doesn't contain much original code, I mostly copied it from J2ME-Loader, my parts are only the ui support and these native bridges, all the rest is just copy-paste :D

Thanks a bunch, i really appreciate it! Either way, if you ever decide to contribute there directly, you're welcome!

But if you plan to keep the fork java-only, then it should actually work with CheerpJ.. imagine having this on archive.org and being able to play j2me games directly there! Wish you luck :)

That's... a fantastic idea! So much so that i read this up and immediately got to work trying to get it up and running. Turns out it's fairly easy to get a test setup working:
image

However, improving user experience is going to be the more time-consuming part, because CheerpJ does not allow FreeJ2ME to access the user's filesystem, which means i'll need to use the browser's own filepicker through JS, send the selected game jar to CheerpJ's virtual FS, and only then launch FreeJ2ME with the now-local game jar as a launch argument, because CheerpJ's support for AWT is incredibly barebones and most of the time the UI glitches... also AWT's FilePicker doesn't work at all either.

Performance is also a concern, with CheerpJ running about 8 to 10 times slower on my machine compared to my system's own Java 8... then there's also the issue where they're a bit too "enterprise-focused" for my taste...

But anyway, once that's done, it can go pretty much anywhere, and i'm already preparing our fork's github.io page to include it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants