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

meleu

@Hex said in Would you like to play J2ME games on Retropie?:

@meleu Yea it would be better that way. Let me know what you find out.

He said:

"I wrote the code to read ZIPs/JARs, read info from manifests and load .class files to memory.

Theoretically I could start to interpret Java bytecodes, but other priorities had come, and I thought that maybe it's better to use the SableVM than maintain my own JVM. Anyway, it didn't evolved."

Hex

@meleu Sable reached its End of Development in 2007. I might have a look there too. I tried playing some game and lot of them need only these keys

Yes & No
Dpad keys + Enter (AKA yes key)
1,3,7,9

So this seems doable. Yes no can be start and select, Dpad = Dpad and 1379 XYAB. So all in all its very much plausible. Now i need to find a good java dev to help me with setting up the build env. Know anyone who can help?

recompile

@Hex It looks like ME was using maven 2, which is end-of-life. Eclipse can create and Ant build file for you, if you or contributors want to use something other than Eclipse for builds.

I'd start by downloading the Java SE SDK and setting up the project in Eclipse. Once you can successfully build, install Ant and create a build file.

The read-me-developer.txt on the version on GitHub should fill-in any gaps.

I can try to get something working later in the week if you're having trouble, but it doesn't look like it'll be too difficult.

Hex

@recompile if you can get it running then I would get on it ASAP. Let me know how it goes. I am currently focusing on PS and hence unable to divert much time in things i dont know about. Can you set it up and let me know how it goes. Thanks.

recompile

That wasn't too bad. I installed the JavaSE JDK (I haven't used Java in ~10 years) and Apache Ant.

You'll need to add a couple environment variables: JAVA_HOME and ANT_HOME

After that, I ripped out as much as I could from the source, and wrote a build.xml file for Ant to use to build the project. (For simplicity, it creates just one jar file.)

I had to hunt down a missing 3rd party library (picking the newest version that would work) and added it in. A few minor tweeks, and it builds... with a few warnings.

The resulting jar works. It loads and plays games. Inexplicably, it plays a few games that the last official release was unable to play. (Though Doom RPG, Orcs and Elves, and Doom 2 RPG run at hyperspeed. Wolfenstein RPG seems to run normally.)

Anyhow, you can download what I've done here:

[http://drichardson-shared.s3.amazonaws.com/microemu_src_ant_2017-7-10.zip](link url)

From the command line, navigate to the directory and type 'ant' It will pick up the build.xml file and build the project. The resulting Jar will be in the "build" directory.

Happily, you can start a game from the command line as well:
java -jar microemu.jar game.jar

Right now, it uses Swing and AWT which won't work without X11. Rumor has it that JavaFX on ARM doesn't share that requirement, and would be suitable for porting MicroEmulator to RetroPie.

Hex

@recompile This is excellent. I will get to it asap. I plan on trying to incorporate Java SDL for video out is possible.

Did you notice that one core was always maxed out while running the emulator?

recompile

@Hex Just tried it out, but it didn't happen for me. What game were you running?

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.

alt text

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.