TwoSpacesSG
He/They
🇲🇪 Montenegro
Joined: 9 days ago
Posts: 1
Location: 🇲🇪 Montenegro
I've been told to put my knowledge somewhere like on the forum so that it is not lost in discord convos. FreeJ2ME-Plus is a wrapper around Java runtime environment (version 6 or higher) that allows you to play games for old J2ME cell phones, providing the functionality of an emulator of these games. You can learn more info from its page at https://github.com/TASEmulators/freej2me-plus . Since it's one of the better open-source and clean-room J2ME emulation projects of the present time (alongside J2ME Loader, but that one is closely tied to Android), it would make sense to use it for TASing, but how exactly? Due to JRE's highly multi-threaded approach, it doesn't cooperate well with libTAS. An idea has been thrown around for a while to use libTAS on PCem running some operating system running FreeJ2ME-Plus in JRE, since that way it would actually be possible to sync everything up. It's been thought that the default Pentium (450 MHz) in PCem for Windows XP isn't enough performance-wise, but upon some testing i found out that it's specifically the case for Java 8, whereas the older Java 6 (which has been supported by FreeJ2ME-Plus for a little while) works smoothly in seemingly a decent amount of games (it's possible that the Windows setting "Adjust Windows for performance" improves smoothness a bit). The version I like the most is Java 6u31, which (afaik) is the very last version to include the miniBAE sound engine for playing MIDIs. All the next versions of JRE (the next updates of 6, and then all versions of 7 onward) use an entirely different driver for sound that uses Microsoft GS Synth (Windows) or FluidSynth (Mac/Linux) and has its own bugs alongside not having the signature bundled soundbank that usually fits games better than either of the two aforementioned OS synths. Java 6u31 (Windows 32-bit) is still available from this public link https://javadl.oracle.com/webapps/download/AutoDL?BundleId=62314 though I haven't looked into the Linux version which might be restricted to the sign-up-walled Oracle Technology Network. Some of the other challenges as of the latest stable include:
  • FreeJ2ME-Plus doesn't hide the cursor on the screen, which is displayed right in front of the window if mouse support is off. The easy idea I came up with (if using an installation movie to pre-install Java 6, throw all the files onto the drive, etc.) is to also set the standard cursor and the two "thinking" cursors to a transparent cursor. If there needs to be a reproducible one, then "mameWAH" has one called "transparent.cur" bundled with the package.
  • The very first time FreeJ2ME-Plus is launched with Java 6, it flicks the screen to 640x480 and then back to 800x600. I suspect it's some weird Java 6 thing and not something FreeJ2ME-Plus does though. It never does so on subsequent launches.
  • feos in his WinXP setup movie does not press numlock, which is critical, again necessitating a setup movie where you don't forget numlock.
  • There is a typo in the readme as of this writing. If making a batch file for easy game startup for the movie on Windows, there need to be four slashes at the start of the path, not three. "file:////C:\path\to\midlet.jar" - otherwise the game might launch, but I'm not entirely sure if correctly, because the console will definitely say some stuff.
  • Last but not least, while some games only require the JAR archive with the data to fully function (and those might be available in their original form but some games or versions are only available with edits from whoever from the piracy scene dumped the game back then), some might also need the JAD text file with additional app properties, and those in their original form are pretty much never reproducible (depending on store, they're different depending on the purchase or on the buyer) but the most commonly-found JAD text files with app properties are the ones released by dumpers (predominantly from the piracy scene), which are pretty much reproducible. Of course, good judgment also has to be used when choosing the JAR file for a given game/version, because not everyone might be equipped to tell good dumps from bad ones, and there's no comprehensive No-Intro-like human-sorted good dump collection for any good amount of games (notably, Gameloft Store and Bemobi Apps Club still sell J2ME games, including a small amount of big-name ones).

1764937765