Repository navigation
Things to do
Expose the input data to the core, allowing remaps and giving the user more info on what each key does (DONE)
Update the config and save paths to allow both the libretro and the other frontends to save correctly (DONE)
Expose the core configs to the frontend, allowing screen res, rotation, FPS, etc. to be changed. (DONE).
Expose the analog-controlled pointer speed to the frontend, as well as add the possibility of changing the pointer's colors (DONE)
Expose the audio on/off config to the frontend as well, some games currently only boot or work well with sound disabled (DONE)
Revamp the way core settings are updated. Currently the core requires a restart in order to apply changes like rotation, phone keylayout, etc. due to the way it's implemented. Idea: On the function that gets the core options from the frontend "check_variables()", find a way of packing all of the options and sending them through the pipes with a distinct size, so that the java app can detect it and call the config update function to change most of those settings without needing to restart. (DONE)
Add some extra pointer visuals for games that might use it as a crosshair for example. (Scrap that, not really useful)
Find a way of allowing the core to log its output in the libretro frontend, and expose a config for it. (Adding log support to the libretro Java app isn't particularly useful, usually i only set up some debug code in a specific block where i want to implement something or check how to do something differently, so there's no practical use to have logging in places i have no idea what to look for)
While the retroarch core can rotate its screen to be able play some touch-based games (and also a few that use something like 240x320 but in landscape, becoming 320x240), the awt frontend (and possibly the sdl one) do not.
Currently, the core only builds on windows with the help of MinGW and a few other unix/GNU tools such as cygwin. But this is far from ideal and is prone to cause problems in Retroarch, that fails to load the windows core due to the heavy reliance on unix calls such as fork() and pipe().
FreeJ2ME's current AWT frontend is nothing more than a simple window with no options within, making the "ESC" menu the only way to change settings around. It's possible to use Java's AWT objects to build a mouse-friendly UI that's also more robust and easier to use than what is currently used.
Currently, there's no way of doing that and keys are hardcoded into FreeJ2ME.
A few games such as Medal of Honor Airborne, NitroStreet Racing 2 and Asphalt Nitro crash when sound is enabled, so improvements to the audio subsystem need to be made.
By far the most common media codec whenever a WAV audio file doesn't play as expected, it's used by many Gameloft titles, and also by many other developers.
Lots of games use this audio format for their files. For now, they aren't even played, according to Nokia's documentation on AMR, files using the "audio/amr" mime type are usually encoded as AMR-NB (NarrowBand, and it makes sense on J2ME devices where processing power is limited, and so is storage and RAM for applications), which means that decoding AMR-NB might be a good starting point given it's likely to be the most popular.
Same issue as above, although "audio/mpeg" is nowhere near as common as "audio/amr" or IMA ADPCM "audio/wav" files.
A bit rare, but games like the 320x240 version of Asphalt Nitro need FileConnection, otherwise they crash before even reaching the menu.
I didn't find a game that depends on PIM as of yet, but having JSR 075 present as a whole even with some parts stubbed should benefit games that weren't tested yet.
Some games use a few bluetooth connectivity classes not found in FreeJ2ME previously, most only check if the support is there, but nonetheless if the files aren't present, FreeJ2ME usually crashes.
Same as JSR082, some games usually only check if support for this JSR is present, crashing otherwise. Can probably be stubbed too.
Not many games use this, but ContrTerrorism 3D - Episode 3 crashes on boot in FreeJ2ME and makes J2ME_Loader ask for location permission (also seems to use internet APIs to some extent), so there should be some kind of library for that in J2ME.
Another one that i didn't find a game that uses it, but it's still part of the J2ME spec nonetheless.
Although i also didn't find a game that explicitly needs this, having a more complete J2ME spec support is still beneficial to FreeJ2ME.
Implement the JSR184 (M3G 1.1) libraries for 3D rendering, VERY complicated and time-consuming to do.
Most 3D games use this library to render 3D graphics, so a working implementation of it would boost the emulator's compatibility immensely on 3D games.
This one isn't as widely used as m3g, i only know about some Fishlabs games that use it on their Abyss Engine (Galaxy on Fire 2, Deep 3D), also, there's not much documentation about it and the only functional implementation so far appears to be the one in JL-Mod. Nevertheless, it should be implemented some time later.