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

[Hex]

@recompile I did a bit of digging and got all the keys to be recognized.

The Buttons LR StSl ABXY all generate button events which I can detect and send like keyboard events. We will need to differentiate them from keyboard values.

The Dpad on the other hand generates 2 data points. One tells if it is horizontal or vertical and another tells me if its Left/Top or Right/Bottom or Center (Released).

How do you want me to send over this data?

EDIT : I have updated C source so you can test which events are generated (O/p in string for testing).
run the sdl_interface directly sdl_interface 1 1 nearest
change focus to C while terminal set to keep on top to observe events. To exit Ctrl+C in terminal.

[recompile]

@hex We can use the event type flag to differentiate keyboard and gamepad events. we can, for example, use 2 and 3 instead of 0 and 1 for released/pressed.

We can also abstract the dpad weirdness, if you want, by tracking which direction is pressed, and sending a corresponding released event when the state changes. Alternately, you can send a different event type, say 4, packed with the current dpad state and I can track it on the J side and generate the proper key events.

On the C side, do you already know which events correspond to LR StSl ABXY or can you get them from retroarch or libretro?

[Hex]

I have just one controller but this is my mapping, you can compare it with you event o/p

//A
1
1
//B
2
2
//X
0
0
//Y
3
3
//L
4
4
//R
5
5
// Start
9
9
//Select
8
8
//Up
X : -32768
X : 0
//Down
X : 32767
X : 0
// Left
 : -32768
 : 0
//Right
 : 32767
 : 0

X replaces some wierd character that doesnt display here

[recompile]

@hex Mine is quite different A:1 B:0 X: 3 Y:2 L:4 R:5 St:6 Sl:7

The dpad doesn't make any sense. Pressing Up, Down, Left, Right generates:

: -1
: -32768
: -1
: -32768
: -32768
: -32768
: -32768
: -32768
: -32768
: -32768
: -32768
: -32768

While that output is handy, this version is very broken.

[Hex]

@recompile I have got unique keys for all dpad keys now. I shall update C and let you know ASAP.

[Hex]

@recompile Can you try it now? I have updated the C source

[recompile]

@hex I get nothing from the dpad, but I do get events from the analog sticks.

[Hex]

@recompile I have written some print statements to debug this issue. Can you try it standalone rather than using it with J. I have updated the source.

./sdl_interface 1 1 nearest

All prints are in string while testing.

Check line 179. That is where I dont know how to handle. Currently what I am doing is registering event if position is zero or Max on either sides. I got two controllers for testing , an SNES gamepad and Xbox controller.

The Dpad on xbox controller does not yield max values and hence was getting ignored. What should be done in such case

The Dpad on SNES controller works as expected and provides accurate values.

[recompile]

@hex Let's make this easy.

What we want: simple pressed/released events from the dpad

What we have: a 'changed' event with a value range, giving us the current state of an axis.

We know that when an axis state changes to 0, neither button related to that axis is pressed.

We know that an axis can be in only 1 of three possible states +N | 0 | -N If Up is + and Down is -, then we know Up is pressed if value > 0 and Down is pressed if value < 0 ** That should answer your question about what to do with values outside the three points you were checking, as no points in the range remain unchecked.

We can store the dpad's state in only four bits, using one bit for each direction. i.e. UDLR

On each axis motion event, we make a copy of the old state and update it to reflect the current state. We can then compare the old state to the current state to generate events. (We need to make a copy to preserve the old state of the other axis.)

For example if the old state is 1001 and the new state is 0101 we know we need to generate two events: up released and down pressed. If there's no change in state, we don't generate any events. Even a noisy analog control will look like a normal button on the J side.

** our comparisons could also look like >=1, <=-1, and >-1 & <1 if you want a little buffer around 0

[Hex]

@recompile Good morning. Firstly I am adding rotation support for frames. So rotation param can be sent from J. As I go on exposing features it will be better if J only sends necessary params. Only if user specifies in config should J opt to send optional params.

Let me recap what you are saying so we are on the same page

• Always store prev state (will need to account for multiple analog sticks' axis)
• Convert state in onStateChange into {0,1} per direction and check with prev value in {U,D,L,R} .
• If value differs then fire event.

I can have a threshold that acts like a cuttoff for event detection and have this working :)

Another thing to note is these joysticks are capable of moving in two dimensions so will fire two events if moved diagonally. which should be acceptable.

[recompile]

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

Firstly I am adding rotation support for frames.

That's fine, I'm just not sure why we'd want/need it? Not very many games detect orientation, but those that do base it on the screen resolution and detect those changes by overriding the sizeChanged method on Displayable. (It's the only way to detect orientation changes.) Changing orientation, then, requires changing resolution. Changing resolution means killing sdl_interface and starting it again, so we wouldn't need to rotate there anyway.

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

Another thing to note is these joysticks are capable of moving in two dimensions so will fire two events if moved diagonally.

Yep. If you press up/left you'll generate an "up pressed" and a "left pressed". If the user slides their thumb so they're only moving up, you'll fire a "left released" The games don't know about gamepads, so J will convert those to the relevant key events.

[Hex]

I downloaded a game with landscape resolution and it still displays as portrait but is to be viewed from the left. This is for games made for devices with unconventional screen placements. It is quite easy and handled by SDL.

Regarding the joystick , it might take some time (20 mins). I am looking at how ES handles these things so if the code is usable I will just copy and modify that.

[recompile]

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

I downloaded a game with landscape resolution and it still displays as portrait

I have a few games like that. Rotating the image, however, won't make any difference. From the games perspective, nothing has changed.

The only way to tell the game that the device is on its side is to change the resolution. J2ME doesn't have a concept of 'orientation'. As I explained above, games that want to watch for orientation changes must override the Displayable sizeChanged method and infer orientation based on changes to the display resolution.

If you're running a game in 240x320, and the game expects landscape, the only way to change that is to change the resolution to 320x240.

I appreciate that it's easy to add rotation, but it's not going to add any value. Remember, the game has no idea that the image is being rotated. You can see this for yourself by rotating frames from J 90 degrees. If the game was in portrait, it will still be in portrait, just rotated 90 degrees. Running a landscape game in 240x320 rotated 90 degrees will still look the same, it'll just be on its side.

[Hex]

@recompile I have got all events to be binary now including the joysticks. I will tidy up the code and let you know once it is ready.

I will be testing the rotation too. Now that i have a sample if it works then its in as a feature else i will just discard that code.

[recompile]

@hex Out of curiosity, what is the game you want rotated?

[Hex]

@recompile Asphalt6 (480x800)

Rotation is proving to be much difficult that anticipated. Working on this till I get controller back

Also I lost the Xbox controller. Cant have it back till the little bro finishes playing Minecraft :|

[recompile]

@hex I see what you mean now. Rotation makes sense for those cases.

[Hex]

@recompile Can we change the parameter to not need the file:// part ?

So you could have -f ./Asphalt6.jar
else -u http://.....

[recompile]

@hex Probably, but the only people who will see it are you and I. Everyone else will launch games from ES. Are you just looking to use relative paths, or are you just sick of typing the whole path every time?

[Hex]

@recompile Sick of typing. File:// does not auto complete so while trying different games for testing i have to copy paste or type very carefully. defeats the purpose of running it from terminal.

suggested changes would be much better. Very few will leverage "-u" option anyways so it will make testing easier.