FreeJ2ME-Plus v1.52 - The Holidays Release

Happy Holidays, everyone!

Made an extra effort to finally finish two relatively lengthy commits in time for the holidays, so here it is: V1.52

It's a bit bigger release than 1.51 considering the changes, so here's the quick rundown:

• M3G should run noticeably faster than 1.51, and is slightly more compatible as well.
• FreeJ2ME-Plus now uses hand-written code for lcdui.Graphics rendering, allowing it to properly support DoJa's Graphics2 blending modes, and also fixing quite a few applications where Java AWT's usage caused issues (it now renders more accurate shapes as well).
• Many improvements to KDDI/ezPlus and DoJa, resulting in more compatible apps (some of these were done in tandem with the recent preservation work for ezPlus apps!)
• Many improvements to Nokia Sound, with its OTA tone decoder being near-perfectly accurate (can't support infinitely looping patterns, it's a MIDI limitation), and also faster compared to 1.51.
• lcdui.game classes (and Siemens equivalents) were cleaned up and now support transformed Sprite collisions, which should fix some games despite being a rather niche use case.
• A few LCDUI fixes in regards to form, list and command processing.
• Libretro fast-forward rate is now respected by the core (thanks to @Magstic)

Pull Requests Merged

• fix: respect RetroArch fast-forward rate by @Magstic in #171

Full Changelog since v1.51: 1.51...1.52

_NOTE: As always, Libretro REQUIRES manually moving freej2me-lr.jar into the system folder, and freej2me_libretro.(dll/so) in the cores folder to work

Now for the (potentially) less enticing news:

FreeJ2ME-Plus has some serious limitations as far as Libretro and TAS support are concerned. Its reliance on using the standard Java VM were a boon early on when the original authors worked on it, but with time (and especially now that i'm working more on stuff that goes outside the official MIDP-spec), i began to notice the pitfalls of that setup more and more.

• For libretro, it's impossible to have a properly functional core for it, since a bridge is required to connect the Java app to the C core (which at this point is little more than an image and input handler, audio is entirely handled by Java)

• For TAS, it's a lost cause given since the JVM likes to multithread as much as it can, and it was never conceived to work well in this environment, so timing issues are plenty, and even hurt some actual J2ME applications. In the future, it could be possible to make FreeJ2ME-Plus run on top of SquirrelJME which is much more portable and doesn't rely on the HotSpot VM, but that would require some decent refactoring in FJ2ME's code, and in that case, it's not worth it.

Tie those with the fact i already had to hand-write code to support graphics operations outside of Java AWT's scope, and i began to think i'm nearing a dead end, and could very well start programming something that doesn't rely on the Host's Java VM to run (and that could thus be more portable).

From now on, i'll be focusing far less in FreeJ2ME-Plus than before, as there's not much else to do that doesn't involve the massive 3D libraries, and continuing to work on these could very well end up being a fool's errand due to the limitations above.

That doesn't mean i will stop developing for it, though

What this means, is that since SquirrelJME would be the "way out" for FreeJ2ME-Plus, i've decided "why not shift my focus to that instead?", and thus for the last few weeks, i've been far more active there than with FJ2ME+ itself and managed to push quite a few improvements. From the last month to today, it now transforms sprites and images properly, had all missing MIDP shapes raster code implemented (as well as some Nokia/DoJa ones), gained support for Nokia DirectGraphics, which should be about on par with FJ2ME+ 1.52 (it even runs Bounce Tales now! Despite some transparency bugs), and is about to get a Nokia Sound implementation in the next days... (a decoder that, as opposed to FJ2ME+, should be virtually perfect as it won't rely on MIDI, so it is intended to support the entire specification)... not to mention i'll be working on PCM and IMA ADPCM WAV support soon™.

So what you can expect from here on out is that, for the vast majority of the time, any new commits and improvements to FJ2ME+ will be, at least from my end, a byproduct of work i'm pushing to SquirrelJME. This repo will still be relatively active, but as a second-class citizen compared to SquirrelJME.

FreeJ2ME-Plus v1.51 - Minor Advancements

Quick rundown

This one doesn't have too much to add on top of 1.50, as it's mostly aimed at fixing some regressions introduced by it. Nevertheless, there are some nice features included, most notably, much faster M3G performance, and considerably higher DoJa compatibility (check the compatibility list for more info, you can search by "I-Appli").

The idea was to wait a bit longer until the next stable release, however, the next set of changes has the potential to introduce quite a few regression due to DoJa's Graphics2 class requiring a near-complete PlatformGraphics overhaul thanks to its off-spec image manipulations for which Java SE has no proper replacement for.

Pull Requests Merged

• Fix: Garbled characters issue in config path by @Magstic in #148

Full Changelog since 1.50: v1.50...v1.51

NOTE: As always, Libretro REQUIRES manually moving freej2me-lr.jar into the system folder, and freej2me_libretro.(dll/so) in the cores folder to work (until it gets integrated onto libretro's official list at least)

FreeJ2ME-Plus v1.50 - Sailing to Galapagos

Quick rundown

Despite the small change in numbering scale... this release is actually quite packed with changes, and as the (quite cheesy) release name implies, it was aimed mostly at overseas vendors like DoJa, Yahoo Keitai, KDDI, SKT, etc.

The stars of the show are the MLD and SMAF decoders, which now bring audio to pretty much all vendors that use them, and support for SKT's SK-VM, courtesy of @usernameak... but beyond that, many, MANY graphical, input and performance improvements were done under the hood. It's hard to write in detail everything that was done since v1.48, so i'll leave that task to the changelog.

FreeJ2ME-Plus seems to be making waves as well, and as a result, not only is there more testing being done and issues being posted than previously, but it is also receiving more pull requests than ever before as well.

My sincere thanks to all of the contributors since V1.48, Check them below! (and if i missed anyone, please reach out)

Pull Requests Merged

• Fix: setCurrent is not called before calling paint by @ohayoyogi in #99
• Fix: To handle number key, improve code of updating keystate by @ohayoyogi in #105
• Fix loading saved keymap by @ohayoyogi in #107
• Adding support playing SMAF on kjx game and fix display layout by @ohayoyogi in #102
• SKT API support by @usernameak in #125
• Fix: Path parsing error for special characters by @Magstic in #137

New Contributors

• @usernameak made their first contribution in #125

Full Changelog since 1.48: v1.48...v1.50

NOTE: Libretro REQUIRES manually moving freej2me-lr.jar into the system folder, and freej2me_libretro.(dll/so) in the cores folder to work (until it gets integrated onto libretro's official list at least)

FreeJ2ME-Plus v1.48

First Stable-ish release of FreeJ2ME-Plus!

This one marks the first of FreeJ2ME-Plus stable versions, containing just enough regression fixes since the last added features that it warrants a tagged release.

This release contains prebuilts to match the current FreeJ2ME-Plus state at this point in time.

Nightly builds

Nightly builds are the best way to get the latest changes

For FreeJ2ME's main jars, you can get them

HERE

And the libretro cores are available

HERE

NOTE: Libretro REQUIRES freej2me-lr.jar in the system folder, and freej2me_libretro.(dll/so) in the cores folder to work