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

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 ?

recompile

Hey, it's playable now:
http://drichardson-shared.s3.amazonaws.com/freej2me-rpi.jar
http://drichardson-shared.s3.amazonaws.com/sdl_interface

Put sdl_interface in /usr/bin, start games like so:
java -jar freej2me-rpi.jar file:/home/pi/RetroPie/roms/j2me/somegame.jar 240 320

Quit with F4, numbers, arrow keys, enter work as expected. 'q' and 'w' for soft1 and soft2, 'e' and 'r' as redundant * and #

@Hex This is what I was going for with key events:
http://drichardson-shared.s3.amazonaws.com/sdl_interface.cpp

Hex

@recompile How is the speed and performance ?

Shall I try to find a better way to get the keys out? I think I understand what you want. Let me see.
Can you tell me in byte form what is the order of data being sent out?

We also need to come up with a name for the Emulator. Something crazy. I vote for "Anbu"

recompile

@hex It's not as good as on my desktop, but it's perfectly playable.

As for keys, just look at changes I made to sdl_interface.cpp (~ line 113). Each key event results in 5 bytes: 1 for the event type, 4 for the code (big endian). Converting an int to a string in C, then reading that string in J and converting it back to an int seemed ridiculous when we could just send the int.

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

We also need to come up with a name for the Emulator

I plan to release the AWT and JavaFx source and builds under its current name. Why change it for the RetroPie build?

Hex

@recompile I am expecting it to be taken up in Libretro later on once it gains traction. Hence the request. Since it is heavily modified for Raspberry pi having a different name might come in handy later on.

recompile

@hex I wouldn't call it heavily modified. Only a single file is changed between the AWT, JavaFx, and RetroPie builds.

Still, it's not important. If you want different name for the retropie build, have at it.

Hex

@recompile I have changed C source a bit and updated it on dropbox. It is same in functionality so it should work as expected. I have just streamlined a bit.

I didnt think that the change was so small. FreeJ2ME is fine too.

recompile

@hex I guess my next step is to start working on the per-game configuration.

On the C side, I'm guessing you're going to work on joystick support and whatever you need for RetroArch/libretro?