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

recompile

@Hex That's a tall order. You'd need to pick a modifier key, with the rest doing double-duty to hit all 18 buttons.

If I remember correctly, a lot of games that use the nav buttons also use 2,4, 6 and 8 as directional keys and 5 for 'okay'. If you used X for the modifier key, you could try something like start and select for the softkeys, the d-pad for 2, 4, 6, and 8, Y for 5, and A and B for * and #. If you use the d-pad and modifier together for nav, you have just enough buttons between start, select, A, B, and Y for 1, 3, 7, 9 and 0, though it'll be awkward to hit A, and Y when holding the modifier. That's the best I could probably do as far as a sensible default for 10 buttons is concerned.

I have to wonder though, how many controllers have 4 buttons, start, and select but don't also have L & R? You might be making it more difficult than it needs to be. It would be an easy decision to use L or R for the modifier if you don't mind upping the minimum button requirement.

Now that I'm thinking about it, you could drop the requirement to 8 buttons, if you used 3 modifier keys, allowing one to use one of those USB NES controllers. It would be pretty awkward to use though. Math says the absolute minimum is 5 buttons for 18 functions, but that would be absolutely awful (or impossible, in the case of a 2600 joystick) to actually use.

Oh, I forgot about something else odd about J2ME games. Some games used APIs from vendors (Nokia, Siemens, etc.) so you might need to include that in the per-game configuration.

@Hex Yeah, I noticed that when I wrote the fix, but I didn't want to modify the sprites. I thought it was funny that documentary crew at the dig covered his shame in their artwork.

Hex

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

@Hex Yeah, I noticed that when I wrote the fix, but I didn't want to modify the sprites. I thought it was funny that documentary crew at the dig covered his shame in their artwork.

What??

Hex

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

recompile

@Hex Sorry, that was supposed to be @mediamogul. I tried to edit that when I noticed, but aksimet decided that change made my post spam. Frustrating.

mediamogul

@recompile

I thought it was funny that documentary crew at the dig covered his shame in their artwork.

Ha! I missed it. That is funny.

pjft

I don't know a lot about these games, but if lack of keys are a problem, the ZX Spectrum emulator solves that by showing a virtual keyboard when Select is pressed. I imagine that some keys will only be used rarely, so that can be an option!

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