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

[Hex]

@recompile It is awesome. Basically I have to draw frames from java using C/C++. Can you tell me what type of frame data you have so I can start from that.

I shall get to it once PS gets updated. There were some issues with Video Screensaver and PS that caused ES to be unusable if VideoScreensaver was disabled by setting the timeout to zero. Ignorance on my part.

[recompile]

@hex You'll have a byte array with pixel data in ARGB (32bpp) from BufferedImage.getRGB and two int32s, for width and height.

[Hex]

@recompile Sounds good. I will get back to you once I have something working.

[Hex]

@recompile Would the following work by any chance. I have no experience with JNI and it is not ideal for me at present.

You can open a process from java with HxW parameters. Then pipe each frame to it.

My application can read HxW from passed parameters, create SDL surface and draw incoming frames. Once you finish and app needs closing just close the pipe which will cleanly exit my application too.

Alternatively I can create a FIFO and you can pipe to it if that makes it easier.

Also I am interested in knowing if your frame will handle black background and scaling on the buffer or should I handle that in c++. both options are acceptable.

[Hex]

@recompile This is what I have been able to accomplish. Since I am not fluent in Java at present I opted to show the example using python. It will mostly be similar for java.

I dont have a stream of frames so I am sending over a single raw image stream from python to c++/SDL. Then sleeping for 10 secs and exiting.

You will need to make some changes for ARGB mode

unsigned int bytes = 3;  //Make this 4

// For RGB :: Comment next line
SDL_PIXELFORMAT_RGB24,
// For ARGB32 :: Uncomment next line
// SDL_PIXELFORMAT_ARGB8888,

You will need to compile the c++ file. Instructions in MD file.

https://www.dropbox.com/sh/1mr9qcm5qxqow63/AAAzd5tHb-JmysaF79UpB5Wja?dl=0

Let me know if you need any more info or have questions.

[recompile]

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

I am not fluent in Java

Neither am I. I don't even like Java. But look how far we've managed to get anyway.

I like the idea of a named pipe. We'll need to get input from SDL as well, so that may be the easiest way. Though I wonder if sockets would be easier.

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

if your frame will handle black background and scaling on the buffer

It will not because it should not. It would be slower and we'd be sending a lot more data on every frame.

[Hex]

@recompile SDL handles scaling and letterboxing by default so that s not an issue. I shall check if I can get JNI working

I dont think we need a named pipe. Writing to STDIN of the c++ file is sufficient. As soon of you close the pipe SDL cleanly exits. What input are you considering from SDL? Keyboard Events?

[recompile]

@hex

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

s. What input are you considering from SDL? Keyboard Events?

Yes. Joystick and mouse input as well. We won't have access to those without a java ui otherwise for what I can only assume are incredibly stupid reasons.

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

Writing to STDIN of the c++ file is sufficient.

Games are surprisingly noisy. That Prince of Persia game you mentioned, for example, writes to stdout every time you grab a ledge.

[Hex]

Ok I get the controls thing. We cans see what can be done for inter process communications.

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

Games are surprisingly noisy. That Prince of Persia game you mentioned, for example, writes to stdout every time you grab a ledge.

That shouldn't make a difference. So what is happening is from JAVA application (J) you open the C++ application (C) with source W and H as parameters. Then send video frames to C.stdin. Thus you are only sending frames on this channel. You can also read from C.stdout which shall send back only key/Joystick events . Thus the entire communication is controlled.

/* Pipes used for J2ME emu

,---- Frame out ---- >> -------- STDIN -----C
|,--- Event in  ----- << ------ SDTOUT ----'
J --- SDTOUT   -,
|`--- STDERR    |-   Free do do what ever needed
`---- STDIN    -'

*/

[recompile]

I'll give it a shot, I guess. You'll need to send keydown and keyup events.

Ed: We may want to be able to change WxH at will for configuration.

[Hex]

This actually eliminates the need for JNI and is very fast. Just make changes to the c++ code i mentioned above and remove all print statements so stdout is clean for events while video testing. I shall make way for event passing till then.

Things to Note:

• Frame should always be completely passed else Sync will be lost.
• C is handling scaling and letterboxing

Also do you have a communication standard in mind for Events or am I free to select?

Edit based on your edit: Well J can start C once resolution is know. Is there a way for J to know resolution once a jar is loaded?

[recompile]

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

do you have a communication standard in mind for Events or am I free to select?

Feel free to use whatever you'd like. It could be as simple as a byte for the event type and a byte for event data for keyboard/joystick, maybe a pair of shorts for mouse events. I like simple.

[recompile]

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

Is there a way for J to know resolution once a jar is loaded?

Sadly, no. Most games get the display size from the phone, and either adapt to it or fail. A few games have a preferred display size in the manifest, but it's not reliable. This is why I was passing the display resolution in as a parameter.

I had planned to add a configuration editor that would start and ask for things like display size, control configuration, etc. that starts if a configuration for a game can't be found on load, or that can be manually started to modify a games configuration.

This is what I'm thinking. I could pass a byte along with the frame that signals that what follows is either a frame or a change in resolution. Something like [0, ...frame data...] or [1, shortW, shortH]

[Hex]

@recompile is is ok for me to check for incomming events between frames? I dont know if incoming frames can be guaranteed. So will something like this work for you in "C"? Else I will need to make it multi threaded so that polling and drawing can be done independently.

//wait for incomming frame, blocking call
while true {
    read_frame()
    //Render frame
    show_frame()

    // Check if input event occurred
    if SDL_PollEvent()
        send_event()
}
    

[Hex]

@recompile Regarding the resolution problem, I would like to suggest this :

If config found

• Read config
• Read resolution from config
• Start C based on resolution

If config not found

• Get screen resolution
• Start C based on resolution
• Send frames for config.
• Get map of all required info
• Write config file
• End C by closing C.stdin pipe
• GOTO : if config found

Will this work ?

I would like to keep communications to a minimum. Killing and restarting is not much of a big deal.

[recompile]

@hex That'll work. If freely killing and restarting 'C' isn't going to be a problem then the problem is solved.

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

@recompile is is ok for me to check for incomming events between frames? I dont know if incoming frames can be guaranteed.

There's no guarantee at all. Some games will just sit and not repaint while waiting for an event. Other games will draw frames as fast as they can, even if nothing changes.

[Hex]

@recompile Ok so we will need a multi threaded solution. Currently C can wait forever for new frames to come whilst showing last received frame. I shall get back to you as soon as I have it working.

I also had a question about how audio will be handled. Will Java take care of it?

SDL Controls are working nicely. I can send J ascii codes for the buttons clicked followed by a delimiter if necessary. Some special key codes are >256 (eg Shift, Tab Ctrl, Alt)

Do you need joystick and mouse ? Considering no mobile phone had that.

[pjft]

I just want to say that even though this thread has no other active participants, it's highly enjoyable, educational and even exiting to watch this unfold.

Thank you for pursuing this and for doing this in the forums! Looking forward to seeing what comes out of this.

Best.

[Hex]

@pjft The timing of this was awesome. I just finished PS by your help and @recompile ended up getting is working. I am of the opinion that pair programming is freaking awesome. It is way faster than if a single person were to do it. I will mostly archive these conversations in a README file once this is nearing an alpha release.

[recompile]

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

I also had a question about how audio will be handled. Will Java take care of it?

I don't know. I haven't even tried to properly implement audio yet. I would assume that it can be done on the java side.

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

Do you need joystick and mouse ? Considering no mobile phone had that.

Believe it or not, some games used a touchscreen. Doom II RPG isn't playable without it. Of course, it's the only game I know that requires it, so it's not exactly a priority.

As for joystick, I expect most people will want to play with their controller.

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

Some special key codes are >256

Not really a big deal to send a short instead of a byte. As long as it's consistent, it doesn't really matter. An int for type and an int for code if you want to really go wild.

I'm out for a few hours. I have to go earn a living.