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

[Hex]

@Allanbuzzy I dont think he is saying that. Symbian deppends on Nokia UI, J2ME depends on Nokia UI. @recompile has added full support for Nokia UI.

[recompile]

@hex Sure. I can pass it to C as an additional parameter. From the command line, I'll accept: jar | jar width height | jar filter | jar width height filter but always pass C width height filter

Defaults are 240 320 nearest, but C doesn't need to know that.
http://drichardson-shared.s3.amazonaws.com/freej2me-rpi.jar

[recompile]

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

So N-Gage is supported? Awesome, that's good.

Let me try that again. The N-Gage could run j2me and Symbian games. This project will only support j2me games. Symbian games will not work. Nokia had their own special api for games, which is fully supported, so j2me games written for the N-Gage will work. Again, Symbian games written for the N-Gage will not work.

[Hex]

@recompile I have updated the C source to add support for interpolation/filter type .

J doenst need to pass default (nearest) if not user specified. I can handle that in C

[recompile]

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

J doenst need to pass default (nearest) if not user specified. I can handle that in C

I know, but it's simpler for me to always pass something than to only pass it sometimes. I figured it would be simpler for you, as you can always expect 3 arguments. I like simple.

[Hex]

@recompile Will you be available for an hour or so for Gamepad testing?

Do I need to support multiple gamepads or a single gamepad would suffice.

[recompile]

@hex One should be enough. I don't know of any two-player simultaneous games for old cellphones.

I'll be around for testing.

[Hex]

@recompile I have added gamepad support. Can you test it.

Analog Joystick data is ignored.

[Allanbuzzy]

I would've liked the idea of N-Gage emulation, but oh well I hope someone writes a Symbian emulator.

[recompile]

@hex I'm not getting anything from either gamepad.

[Hex]

@recompile I got a gamepad from a friend for testing. I think I am missing something in initialization. I will let you know once I start getting it working.

[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