Libretro/RetroArch support

[kuba2k2]

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]

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]

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]

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]

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]

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]

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

Oh god, that'd be incredible...

[AShiningRay]

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:

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.

[thenickman100]

In case it would help anyone's pursuit of a CheerpJ solution, here is example code to get it to boot into a J2ME game on load.

hex007#224 (comment)

I've run into some issues getting games to run with the zb3 fork of FreeJ2ME. I can get the zb3 builds to run great from my terminal, but not with CheerpJ. It the games I have tried just crash after loading.

The hex007 builds have great compatibility with CheerpJ... not sure if that is a nuance of the zb3 builds or if I am screwing something up.

[AShiningRay]

In case it would help anyone's pursuit of a CheerpJ solution, here is example code to get it to boot into a J2ME game on load.

hex007#224 (comment)

I've been taking some shots at this on my new fork of FreeJ2ME to introduce support to CheerpJ: TASEmulators#6

And yep, it does load games fine, through there are a few caveats, mostly on UI/UX aside from MIDI not working yet. FreeJ2ME+ does have its own webpage in a separate branch and is where i was intending to integrate the CheerpJ solution into at first... but between a lot of work on the FreeJ2ME's core and the SDL/Libretro frontends, i don't get much free time to actually implement this. More than open to pull requests and discussions over there though.

The hex007 builds have great compatibility with CheerpJ... not sure if that is a nuance of the zb3 builds or if I am screwing something up.

Probably because of the native lib dependencies to support additional media types, and the M3G + MascotCapsule v3 classes. Not sure if CheerpJ supports this at all.

[zb3]

My fork in its current state won't work with CheerpJ because of native libraries and incompatible OpenGL version requirements.. Besides, using AWT image abstractions with CheerpJ is probably very inefficient.

So currently it's best to try to run the FreeJ2ME+ fork: https://github.com/TASEmulators/freej2me-plus
That fork doesn't have any native code so it can be emulated even today.

However.. I'm actually silently working on making the native parts compatible with the web platform + slowly removing dependencies on problematic Java parts like MIDI / Audio and so on.. but don't expect to see any results until at least 2026, I'm extremely slow :o