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

[guicrith]

Do you need oracle java or could you use Midpath?
I have a mac and can test iOS and Android for you.

[recompile]

@guicrith MIDPath isn't an alternative to a JRE. It's written in Java, after all, and so requires a JRE to run. If you just don't like Oracle, you could use OpenJDK but it's significantly slower.

I wish I'd had known about MIDPath before. It would have saved quite a bit of effort. If anyone is looking to make a J2ME "emulator" themselves, that would be a really good place to start.

I'll try to get the source of mine out sometime tomorrow, though I don't know if I'll do much with it going forward. There seems to be enough interest to keep it going in the care of the community, so it's not like development will end here. There's still a lot of big things to do, so it should make a nice project for quite a few people.

I'll see about making a write-up to go over the basic ideas and a few of the stranger things, but it should be easy enough to follow after an hour or so.

[guicrith]

I dont have any feelings toward oracle, are you using phoneME as the runtime(JRE)?
I am just wondering how it would run on android and ios if you are using the oracle JRE binarys since they dont exist for those platforms.

[morrisav10]

This would be amazing when complete, I used to love Zombie Infection on my old Sony Ericsson!

In fact, the library for this would be massive.

[recompile]

@guicrith You can use whatever JRE you prefer. Like any Java application, it uses whatever is available on the system.

If you're looking to port it to iOS and Android, you could try wrapping it in an Oracle MAF app.

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

I used to love Zombie Infection on my old Sony Ericsson!

As luck would have it, Zombie Infection works just fine. The version I have runs in 320x240. You can change the display size per-game from the configuration menu (ESC from the keyboard, L+R+Start from the controller)

[Hex]

@recompile Will you be making an updated version for Linux too (non-libretro)?

[recompile]

Here it is:

https://sourceforge.net/projects/freej2me/
Alt:
http://drichardson-shared.s3.amazonaws.com/freej2me/freej2me_2017-09-23.zip

The AWT build will run on Windows and most desktop Linux distributions. It should run on MacOS, though I haven't tried it. With any luck, a Mac user will let us know.

To build, you'll want to install Apache Ant Just run ant from the directory that contains the build.xml file. Builds are provided in the builds directory, if you don't want to build it yourself.

For the libretro core, you'll need libretro.h and freej2me_libretro.c Run build.sh to produce freej2me_libretro.so A pre-compiled binary for the pi3 is supplied.

With that, I leave it in the capable hands of the community.

[Hex]

@recompile Which one of the compiled jar files is the one we have been testing with SDL?

[recompile]

@hex You'll need to compile that one yourself. Just add an entry to build.xml and run ant.

[Hex]

@recompile Thanks

[guicrith]

This is very cool, the terminal I/O part will be very useful to run linux games on android if I ever try to set that up again.

I will try to get this on android soon using openjre8 and linux, it wont help most users but should work on any rooted android phones.

[Hex]

@recompile I noticed you got the languages to work. Can you guide me how I can fix this? (From ShadowWalker)

Linux OpenJDK8

Using MicroEmu

Using FreeJ2ME

[recompile]

You'll need to properly implement javax.microedition.lcdui.Font.stringWidth, javax.microedition.lcdui.Font.subStringWidth and possibly fix anchors for text in org.recompile.mobile.PlatformGraphics.drawString, which implements javax.microedition.lcdui.Graphics.drawString

[guicrith]

Do you care if I start a github page for the android project, bugreports and so others can contribute.

You would retain full credit for the project and could transfer things to your own github page at any time.

[Hex]

@guicrith I am making one with credits to @recompile

https://github.com/hex007/freej2me

[recompile]

@guicrith It's okay with me. Remember, you have rights and responsibilities under the GPL. While I appreciate the gesture, you don't need to ask me. It's free software, after all.

Make sure you check license.txt before you distribute the ObjectWeb ASM component.

Besides, the more variety the better, right? A lot of code should be portable between branches, so it's likely that your branch will be able to benefit others as others benefit from your own. The GPL keeps things free as in freedom for everyone.

[Hex]

@recompile It is a really nice project we accomplished. Most of the work was done by you. I am really glad we reached so much from the time we almost abandoned it due to awt not working on Rasperry pi and JavaFX problems with externally manipulating frame data. Kudos mate.

EDIT: Let me know if you are on github and I shall provide you write access right away. If you want the repo under your account even that can be done.

[recompile]

@hex I'm not on github, which is why I put it on sourceforge. I've found that github can be difficult for casual users to use. (unintentional alliteration)

I looked at your repo though. It looks like I left some junk on there. You can safely remove the config and package directory.

[Hex]

@recompile I was able to find out and fix the vertical misalignment. You had size medium in Font.java as zero.

---

Now I am stuck with the horizontal part. This method in particular:

public int stringWidth(String str)
	{
		return str.length() * getPointSize() / 2;
	}

I know that the /2 is a hack (removed for the above image). The problem is that the font is not monospaced so plain multiplication is not going to work. So I need a way to get rendered text size. Some searches suggested FontMetrics.stringWidth. I tried to get that from Graphics2D but I am getting NULLPointers.

Any ideas?

[recompile]

@hex You're on the right track. You can see a working example of FontMetrics.stringWidth in PlatformGraphics.

My solution was going to be to add a PlatformFont class, similar to what I did with Image and Graphics. (The idea being that those can be swapped out, leaving everything in the javax hierarchy the same.) That that's not strictly necessary as you should be able to just just use a PlatformImage and its graphics context and reap the same benefits.