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

Hex

@recompile I have updated the code. Syntax is

KEY CODE\n

KEY = 1 : Down / 0 : Up
CODE -> As provided in url above

recompile

I guess back to you.
http://drichardson-shared.s3.amazonaws.com/freej2me-rpi.jar

I get a black screen and a mouse pointer.

Zigurana

This is great!
It's like witnessing the birth of a new emulator (not exactly, but close enough).

Keep up the momentum guys!

Hex

@recompile is there a syntax for that? I am getting an Array out of bounds exception

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
	at org.recompile.freej2me.RetroPie.<init>(RetroPie.java:64)
	at org.recompile.freej2me.RetroPie.main(RetroPie.java:22)

Allanbuzzy

Yes, I'd love to play these mobile games on my RetroPie. And you probably know what my next splash screen might be...
wink

recompile

@hex You need to pass a jar.

java -jar freej2me-rpi.jar file:/home/pi/RetroPie/roms/j2me/ShadoWalker.jar 240 320

Hex

@recompile I have created a sample Java file in the dropbox folder. I have it working with "Broadcaster.java". Can you test it. That might point to the error. Let me know if this is sufficient.

Please download and recompile sdl_interface.cpp too

javac Broadcaster.java && java -classpath . Broadcaster 16 9

16 x 9 Grid size

recompile

@hex Again, just a black screen and a mouse pointer.

Hex

@recompile Shouldnt be happening. Let me post a video. Then you can compare.

recompile

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

Shouldnt be happening.

I know. I can't see anything wrong with your example, and it works for you.

The only difference I can see is that I'm running it on a pi3 and, iirc, you're running it on a pi0. Though I don't see why that would make a difference here.

Do you get any output when you run freej2me-rpi?

Hex

@recompile Here is the video of things that should be happening. Grid changes for every key press.

Are you by any chance running on Wayland?

Hex

@recompile I am running it on Linux. Probably that might be a difference. I am heading out so I will test in on Pi3 in an hour or so. Since I know that it is working, the rest is platform dependent and should work out well.

As you can see from the Java code i am sending over 4 bytes (ARGB) per pixel over stream Scalling is excellent and as expected. There is also a smooth scaling version. Can try that out too.

recompile

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

Are you by any chance running on Wayland?

No, I'm running it on RetroPie 4.2 on my pi3. No X11, Xorg, Mir, or Wayland

I compiled sdl_interface.cpp on there as well, copying it to /usr/bin. I ran freej2me-rpi and your example on that same setup, and got the same result both times -- a black screen and a mouse pointer.

From what I can see, J is sending to C. I can even capture an error trying to write to the stream after I kill C with F4.

Hex

@recompile Yea I saw your comment after I typed mine. Let me check what might be an issue.

Hex

@recompile I have found the error. Apparently SDL2 uses OpenGLES which freaks out if not drawing from main thread. I have fixed it, tested it and updated the new code.

~~Edit : Key events are not read. Let me check~~ I was typing on my ssh machine rather than the keyboard connected to the Pi :|

All in all its working as expected. I tried raw streaming the image, Python, and Java solutions. All are working on Pi3 as of now.

recompile

@Hex Neat! Progress. A few things:

Colors are off. I'm sending ARGB, but can change that to whatever you're expecting.

I'm not sure why you have the space and endl in capture or why the type flag is an ASCII 1 or 0 (0x30, 0x31) instead of just a 1 or 0?

What happened to F4 to quit?

Hex

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

I'm not sure why you have the space and endl in capture or why the type flag is an ASCII 1 or 0 (0x30, 0x31) instead of just a 1 or 0?

Can you elaborate on what part you are referencing.

F4 to quit was removed because debugging the previous thing I will put it back.

I have tested it with RGB to work well. The colours are true with that. Can we switch to RGB?

recompile

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

Can we switch to RGB?

Sounds good to me:
http://drichardson-shared.s3.amazonaws.com/freej2me-rpi.jar

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

what part you are referencing.

*startCapturing It appears that you're sending strings. Why not send a byte for the event type and 4 bytes for the key code? We'd have a fixed length, and could dispense with the delimiters. It'll make the handling of key events much simpler.

Hex

@recompile The problem with F4 is that since C is now rendering on main thread C is stuck waiting for frames. If C receives F4 it wont be able to exit till it receives next frame.

I will set it up such that once F4 is received either J should close C.stdin or send atleast 1 frame for C to exit cleanly. Is that acceptable?

Initially I was just killing the thread to get out of this scenario.

Regarding your request for me to send bytes, as you can see from this https://wiki.libsdl.org/SDLKeycodeLookup , the codes are not of fixed length. Let me see if I can get consistent 4 bytes for key codes

Hex

@recompile I have made necessary changes and updated the code.

F4 now quits as previously
Frame data is now expected RGB
~~You can remove the << endl from both key output lines if you dont want the "\n" delimiter.~~ Removed endl from print. Now STDOUT has the following O/P without "\n" delimiter.
Output on laptop for events is as follows

// Specials
140000050
14000004f
040000050
140000052
04000004f
140000050
040000052
14000004f
040000050
04000004f
// Characters
100000020
000000020
100000076
000000076
100000075
100000079
000000079
000000075
100000076
000000076
100000079
000000079
// F4 pressed now quits
1ffffffff

Let me know if more changes are needed

EDIT : Do you want me to expose the pixel interpolation parameters ?