Would you like to play Nokia (J2ME) games on Retropie?

[Hex]

Prince of Persia Two thrones with 240x320 screen size

[recompile]

@Hex Wow, that one hammers the CPU, though it does improve during game play. Fortunately, it looks like it's not the application, but the game, that's causing that.

MicroEmulator doesn't emulate so much as it provides an environment for j2me games. The JRE is executing the bytecode, so there isn't much that can be done about performance there.

[Hex]

@recompile I shall get the environment setup later in the day and checkout SDL bindings for java. If this works out nicely then It would be great. Considering the game were made for old nokia phones, I have no idea why it is taking so much processing. If this can be debugged then nearly most games should be fun to play I must say.

[recompile]

@Hex It's not likely a bug, just a poorly written game. (None of the other games I tested hit the CPU like that one.) I know it seems crazy that an old game would peg the CPU, but a tight loop will thrash a modern processor just as easily as an old one.

Remember that the JVM is actually running the game. MicroEmulator just provides the MIDP and CLDC API's and loads the game jar. I wouldn't spend too much time chasing that rabbit.

JavaFX looks like it's out, unfortunately. Oracle killed it on ARM for some crazy reason. It would have been nice to have just one build for Windows, Mac, Linux, and Raspbain. I'm trying to find a simple way to get OpenJFX working, but I'm not hopeful.

SDL is just as bad, I haven't found anything serviceable. Hopefully, you've had better luck.

I'm looking at JOGL/NEWT and LWJGL now. Let me know if you find something usable.

[Hex]

@recompile JavaFx would anyway be useless as it might need X11.

What do you mean SDL is bad. Can you elaborate on that?

Seems like more than me you are qualified to work on this. Lets see if this project looks promising before taking too much of time.

[recompile]

@Hex The reason I thought we should use JavaFX was that it doesn't need X11. If we had X11, we'd be done already. Sadly, Oracle decided they'd rather not support JavaFX on ARM.

SDL would be fine, but the newest SDL Java binding project I could find is 12 years old. It would need updated for SDL 2 and compiled for ARM. It seemed like a lot of effort when we could just use something else.

Though our options for that "something else" are getting limited... Anyone have any good ideas?

I doubt I'm more qualified for the project (I haven't touched Java in more than decade) I've just spent more time digging through the MicroEmulator source.

Anyhow, if you can get Java to draw a line on the screen, I'm on board. Otherwise, I doubt I'll do much with MicroEmulator beyond stripping out the last of the applet stuff and squashing a few irritating bugs.

If nothing else, MicroEmulator is now slightly less dead than it was a few days ago. That can't be a bad thing.

[Hex]

@recompile When you say draw a line, are you saying with SDL2 ?

EDIT: This thread is full of useful info https://www.raspberrypi.org/forums/viewtopic.php?f=81&t=73489

[recompile]

@Hex I mean with anything. If you can get Java working with SDL, that's the way to go. If you can get it working with something else, that's great too. The only requirement is that it doesn't need X11.

Ha! That's the link than got me started on JavaFX.

Anyhow, JOGL/NEWT is a possibility. Give it a go. If you can get a working example project, we can start porting MicroEmulator. It looks like they have an armv6-hardfloat noawt build, so that's positive.

[Hex]

Here is a OpenFX/JavaFX demo that i managed to get working on Pi zero. Needs root access to write to Framebuffer but works none the lesss.

[recompile]

@hex Perfect!

I'll get to porting MicroEmulator from Swing to JavaFX. See if you can work out a process to get that JavaFX test you have working on the Raspbain Retropie build for the pi2/3.

[Hex]

@recompile I ran it on zero. It would definitely run on 2/3. give me half an hour.

EDIT : You can get the proper sources from here https://github.com/tisoft/microemu
and binaries for openFX from https://chriswhocodes.com/

[recompile]

@hex I don't know what you mean by "proper sources", but I don't have any interest in starting that process over again. I've made quite a few changes already, and I'd rather not move backward.

I couldn't get my JavaFX test to run using the binaries from chriswhocodes.com on my pi 3 using Oracle's JVM. Are you using OpenJDK?

Ed: I installed OpenJDK and copied the binaries over. That didn't work either, so I switched back to Oracle (update-alternatives --config java) and it magically worked.

Very strange. I have no explanation.

[Hex]

@recompile at the end of the day that is what matters. As for the proper sources, the repository has proper directory structure, feel free to check it out. I didnt mean to imply that you should switch to that codebase.

The binaries on the website are arm6 and Pi3 is arm7. That might have caused some issues. I am planning on compiling from source so i have a arm7 binary. That way it can be tested on both architectures.

[recompile]

@hex As it turns out, the structure is identical to the sources on Google code and sourceforge. (I suspect that the code is identical as well) I removed the 'java' subdirectories for convenience as the entire project is in just one language.

"The binaries on the website are arm6 and Pi3 is arm7." Good to know. Still, as long as it's working I can test it.

[Hex]

I think we can change the openfx runtime framework "jfxrt.jar" for a better one later for performance.

I shall till then start working on getting the button mapping transformed.

Shall we create a github repo for managing the code ? You can host it on your profile or I can have it on my profile with the other as a contributor. Let me know what you think.

EDIT : Mapper file in microemu/microemu-javase-swing/src/org/microemu/device/j2se/J2SEButtonDefaultKeyCodes.java#76

[recompile]

@hex I wouldn't bother with that. I'm going to move all the mappings to config files. One for a default config, and one per-game. (We won't be building anything in the swing branch anyway once we've moved to JavaFX.)

If you want to work on key mappings, figure out what you want the format to look like. Be sure to include display resolution as some games won't work, or won't work correctly, if the display is the wrong size.

I'm working on it now, thought it may take a few days to get running. (Fortunately, I think we can simplify the code rather dramatically.) Once I have a working JavaFX build, we can put it up on github or wherever.

[Hex]

@recompile I shall get on the design stuff.

Regarding the mapping, I was thinking the following

Start , Select -> Soft 1,2
Dpad -> Dpad and hence (2468)
A - > 5
B -> 9
X -> 2
Y -> 7
L -> 1
R -> 3

Most games should work with this config. problematic would be those using 0,*,#

Regarding the resolution, If game is in portrait mode then y = Height, Landscape mode x=width.
microemu has a scale (2x, 3x, 4x) output feature so we can leverage that.

[recompile]

@hex I think I'm done with this project. It's just not going to happen.

I gave up porting MicroEmulator. It's ridiculously over-complicated. I figured it would be easier to just write the thing from scratch, so I did.

MicroEmulator, for all its absurdity, works very simply. It implements javax.microedition.* and uses the reflection API to read the manifest, load the application, and call the startApp method.

Simple, right? So that's exactly what I did. Granted, while my implementation of javax.microedition was minimal, it was good enough to get a few games to run for a while. Happy with my progress, and the significantly simpler code base, I added a JavaFx UI and some code to handle all the image drawing. That's when everything fell apart.

See, JavaFx doesn't like when you try to modify things from outside a JavaFx thread. Naturally, games will want to do this very thing. Short of a lot of very slow pixel-by-pixel image operations (yes, really) and some tricky message passing, a pure JavaFx solution was out.

Big deal, right? Just re-implement all the graphics stuff in AWT and use SwingFXUtils. It's simple and mostly solves the problem.

A test shows that the AWT works on the pi, you just can't display anything. So I gave it a try with a sample application. Unfortunately, SwingFXUtils is not available to us on the pi. It's like we're a niche market that Oracle doesn't care about.

So I'm out. It was an interesting distraction, but it's looking like a fool's errand.

All is not lost, however. For anyone interested in playing a few games that didn't previously work in MicroEmulator due to one problem or another, I have the last MicroEmulator build I made.

http://drichardson-shared.s3.amazonaws.com/microemu-2017.zip

You can even play Doom II RPG if you use the slowdown feature. It's not a total loss.

[Hex]

@recompile Thats sad. Its great that you were able to improve on the base emulator.

So if we can get swing to work without x11, will it help?

[recompile]

@hex If we could get Swing to work without X11, we're pretty much done. However, I don't see how that could possibly be accomplished.