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

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.

Hex

@recompile Would it be possible to run Swing in headless mode, capture the screen and use SDL to output it?

recompile

@hex Not to my knowledge. Again, we lack Java SDL bindings. If you can get it to work, great, but I have no confidence.

Hex

@recompile I am guessing you have tried this https://sourceforge.net/projects/sdljava/

markwkidd

10 years ago, the Lightweight Java Gaming Library was in my opinion, a great library. It provided access to OpenGL among a few other things. It's still actively but I am completely ignorant of the current state of Java or LWJGL these days. I thought maybe it could help though :)

https://github.com/LWJGL

Edit: My aging mind was mixing up SDL with OpenGL. Sorry, not relevant!

markwkidd

edit: nevermind

recompile

I guess I'm not done...

ShadoWalker

Doom RPG

So I converted everything to AWT, as I had a lot of work that would have gone wasted otherwise. I figured that someone might want a new J2ME "emulator" either to tinker with the source or just to play their old games. Out of curiosity, I wondered if the JavaFx bit would be as slow as I thought.

While the JavaFx version plays fine on the desktop, it's absolutely awful on my pi 3. It's okay for turn-based games like Doom RPG and Orcs and Elves, but games like ShadoWalker are just too slow to be fun.

Give it a try if you want.

FreeJ2ME - JavaFx

You'll need the JavaFx binaries (see Hex's post above) and Oracle's JDK. Run as root from the command line, e.g.:
java -jar freej2me_javafx.jar file:/home/pi/RetroPie/roms/j2me/ShadoWalker.jar 240 320

Q and E for soft 1 and 2, numbers, arrow keys, wasd (depending on the game). Mouse for touch screen (for games like Doom II RPG). M to quit. Experiment with display sizes if a game isn't working correctly (128x128, 176x208, 240x320 are common, 360x640 for some later games, notably Doom II RPG)

Yes, the controls are stupid and there isn't any controller support. This was just a test, after all. It's not like it runs fast enough to be fun anyway. I offer it here for novelty only.

Maybe it'll work okay on the pi 4, should it ever appear.

Hex

@recompile Excellent work. I will give it a try. How is that old phones were better at doing this. Since this is technically not an emulator, more like an interface I was under the impression that performance would be least of the worries. Is it the graphics conversion that makes it slow?

pjft

Out of curiosity, when you're running it and run topin a separate SSH session, what's the bottleneck? CPU? Memory? Something else?

recompile

@hex said in Would you like to play Nokia (J2ME) games on Retropie?:

Is it the graphics conversion that makes it slow?

That seems to be a large part of it.

It wasn't much of a test, but this is what I did. Using a watch, I measured how far I could walk forward in ShadoWalker in 5 seconds on my desktop. I did the same on my pi3 both with and without drawing the display. (I added a feature that skips the pixel-by-pixel copy in javafx if a flag is set, which I can turn on and off with a keypress) Without drawing, I move a bit further than I do with drawing though not nearly as far as on my desktop.

Doing the same experiment, but only drawing 25% of the pixels, I move farther than full drawing, but not quite as far as not drawing at all.

Changing repaint/flushgraphics to a faster (but incorrect) version that doesn't make a subimage doesn't seem to make any difference. That manual pixel-by-pixel copy for JavaFx really is significantly slower than other image copying.

Now, removing the excessive once-per-frame gc call I had (which I added to remove irritating pauses in Orcs and Elves) made a big difference. I gained about as much distance while drawing as between without and with drawing before. Without drawing, I was able to go the same distance as with drawing on my desktop!

There's some clear room for improvement, and a clear path to victory. This could actually be doable with some smarter memory management and something faster than JavaFx.

This is what I'm thinking: If you can make a small demo with JNI and SDL that draws a scaled image on screen (you'll want to pass a byte array), I'll turn that in to a usable J2ME "emulator". I've never used SDL or JNI, and the bulk of the code is likely to be in C. This part might be right up your alley.

The JNI part doesn't look like it'll be difficult:
https://www3.ntu.edu.sg/home/ehchua/programming/java/JavaNativeInterface.html

As a bonus, by ditching JavaFx, we'll make it much easier for others to get this running.

Hex

@recompile It is awesome. Basically I have to draw frames from java using C/C++. Can you tell me what type of frame data you have so I can start from that.

I shall get to it once PS gets updated. There were some issues with Video Screensaver and PS that caused ES to be unusable if VideoScreensaver was disabled by setting the timeout to zero. Ignorance on my part.

recompile

@hex You'll have a byte array with pixel data in ARGB (32bpp) from BufferedImage.getRGB and two int32s, for width and height.

Hex

@recompile Sounds good. I will get back to you once I have something working.

Hex

@recompile Would the following work by any chance. I have no experience with JNI and it is not ideal for me at present.

You can open a process from java with HxW parameters. Then pipe each frame to it.

My application can read HxW from passed parameters, create SDL surface and draw incoming frames. Once you finish and app needs closing just close the pipe which will cleanly exit my application too.

Alternatively I can create a FIFO and you can pipe to it if that makes it easier.

Also I am interested in knowing if your frame will handle black background and scaling on the buffer or should I handle that in c++. both options are acceptable.