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

[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.

[recompile]

@hex I just use a shell script:

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

I have nine or so named like test.sh, test2.sh, nokia.sh, etc. for whatever I'm looking to check at the moment. It saves a lot of time and typing.

Also, pressing up on the command line will scroll through previous commands. Very handy.

I like simple.

[Hex]

Can it be please modified to take shell paths like /home/hex/a.jar or ./a.jar or a.jar

Syntax wise I am thinking this

java -jar freej2me.jar file/url W H [-r 90] [-i interpolation]

[recompile]

@hex Yes, but it adds a lot of unnecessary complexity, can be very fragile, and still ambiguous. Is the path intended to be relative to the current working directory or the location of the jar file?

I like simple. I see this as adding complexity without adding any value.

Simplicity is actually the reason why it takes a url instead of a 'normal' path. It was simpler to implement and required less code.

To your specific problem: It looks like you just want to reference a file in the current directory. Here's how you do that:

java -jar freej2me.jar file:./a.jar

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

Syntax wise I am thinking this

That's fine. How do you want to receive it on the C side? Just W H R I?

[Hex]

@recompile Got xbox controller back. Updated C sources. Check it out and let me know if it works as expected or creates any unexpected errors.

[Hex]

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

That's fine. How do you want to receive it on the C side? Just W H R I?

W H I [R]

R is optional

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

Is the path intended to be relative to the current working directory or the location of the jar file?

Always relative to working directory

~/ > ls
--> jsdl/    games/    music/    videos/     roms/

~/ > java -jar jsdl/freej2me.jar games/Asphalt.jar W H 

[recompile]

@Hex A couple things:

Most importantly, it doesn't compile on my pi3.

sdl_interface.cpp: In function ‘void removeJoystick(SDL_JoystickID)’:
sdl_interface.cpp:60:10: error: ‘axisIt’ does not name a type
    auto axisIt = mPrevAxisValues.find(joyId);
         ^
sdl_interface.cpp:61:14: error: ‘axisIt’ was not declared in this scope
    delete[] axisIt->second;
             ^
sdl_interface.cpp:65:10: error: ‘joyIt’ does not name a type
    auto joyIt = mJoysticks.find(joyId);
         ^
sdl_interface.cpp:66:8: error: ‘joyIt’ was not declared in this scope
    if(joyIt != mJoysticks.end())
       ^

Still important, it's over-complicated. You've made things more difficult for yourself.

Why are you storing the previous axis value and not the previous normalized value? It makes things much more complicated than they need to be. By storing the normalized value, you won't need 'deadzone' at all. Try something like this:

// Normalize
normValue = 0; 
if(event.jaxis.value > 0)
{
   normValue = 1;
}
else if (event.jaxis.value < 0)
{
     normValue = -1;
}

Next, you can compare your normalized values to the ones previously stored. How you store them is up to you, but it will affect how you compare them later.

Keeping things similar to how you're doing things already, let's assume you'll store them like this after the compare:

mPrevAxisValues[event.jaxis.which][event.jaxis.axis] = normValue; 

Comparing the old value to the new value to send pressed and released events:

// Remember that the UD axis is 0, LR is 1 
// axisShift will let us pack UDLR neatly in to the event key value
// resulting i: UP - 8, Down - 4, Left - 2, Right - 1
axisShift = event.jaxis.axis * 2;

oldValue = mPrevAxisValues[event.jaxis.which][event.jaxis.axis];
if(oldValue != normValue)
{
    // DPad Button Released
    if(oldValue ==   1) { sendKey(4, 2<<axisShift); } // Up, Left
    if(oldValue ==  -1) { sendKey(4, 1<<axisShift); } // Down, Right
    // DPad Button Pressed
    if(normValue ==  1) { sendKey(5, 2<<axisShift); } // Up, Left
    if(normValue == -1) { sendKey(5, 1<<axisShift); } // Down, Right
}

My example uses a simplified Send Key:

void sendKey(int eventType, int key)
{
 unsigned char bytes [5];
 bytes[0] = (char) eventType;
 bytes[1] = (char) (key >> 24);
 bytes[2] = (char) (key >> 16);
 bytes[3] = (char) (key >> 8);
 bytes[4] = (char) (key);
 fwrite(&bytes, sizeof(char), 5, stdout);
}

Smaller is not always better. I tend to put readability over compactness. I've never regretted those decisions, but I have lots of regrets related to those times when I put compactness over readability.

[Hex]

@recompile You can use this flag while compiling -std=c++11. My gcc supports is automatically. On pi you might need to add that flag.

I copied code from ES. Even if i changed it later the output would remain same hence i did not optimize then (2am)

void sendKey(int key, bool pressed, bool joystick)
{
	unsigned char bytes [5];
	bytes[0] = (char) 2 * joystick + pressed;

Is quite self explanatory

Byte shifting is not easily visualisable for me.

I shall make the changes but I will keep the send key. I am thinking of changing the following line

bytes[0] = (char) 2 * joystick + pressed;
to
bytes[0] = (char) (joystick << 16) + pressed;

so we have
00,01,10,11

Should that be ok?

[Hex]

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

Why are you storing the previous axis value and not the previous normalized value? It makes things much more complicated than they need to be. By storing the normalized value, you won't need 'deadzone' at all. Try something like this:

deadzone will always be needed as it is a cutoff threshold. If we dont have a cutoff even slight movement of analog stick will spew unnecessary events.

[Hex]

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

// DPad Button Released
if(oldValue ==   1) { sendKey(4, 2<<axisShift); } // Up, Left
if(oldValue ==  -1) { sendKey(4, 1<<axisShift); } // Down, Right
// DPad Button Pressed
if(normValue ==  1) { sendKey(5, 2<<axisShift); } // Up, Left
if(normValue == -1) { sendKey(5, 1<<axisShift); } // Down, Right

I dont understand why you are ending 4 and 5

[Hex]

@recompile I have updated the source. Can you update it.

To compile :
g++ -std=c++11 -lSDL2 -lpthread -o sdl_interface sdl_interface.cpp

[recompile]

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

deadzone will always be needed as it is a cutoff threshold. If we dont have a cutoff even slight movement of analog stick will spew unnecessary events.

Take a second look at what I've sent. By comparing the normalized values, and sending events only on change, we won't send needless events on, for example, a change of -29087 to -18542 (which is what you're deadzone is trying to avoid) as we'll instead be comparing -1 to -1 and seeing no change.

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

I dont understand why you are ending 4 and 5

We had used 1 and 0 as the event type for key pressed/released, 3 and 2 for gamepad button pressed/released. 5 and 4 for dpad pressed/released seemed to follow.

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

I shall make the changes but I will keep the send key. I am thinking of changing the following line
bytes[0] = (char) 2 * joystick + pressed;
to
bytes[0] = (char) (joystick << 16) + pressed;
so we have
00,01,10,11

That doesn't make any sense to me as (char) (joystick << 16) + pressed is identical to (char) pressed . It also won't result in the values you suggest. you'll get on 0 or 1.

[Hex]

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

// Normalize
normValue = 0;
if(event.jaxis.value > 0)
{
normValue = 1;
}
else if (event.jaxis.value < 0)
{
normValue = -1;
}

This is flawed. At rest my event.jaxis.value is 0. Which is okay. When analog stick is moved slightly event.jaxis.value will not be 0 and trigger an event as it transitions from 0 to 1 or -1 (normalized). We dont want that. It should be a lot of movement before event gets registered. else you will end up with over sensitive response. Get it?

---

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

We had used 1 and 0 as the event type for key pressed/released, 3 and 2 for gamepad button pressed/released. 5 and 4 for dpad pressed/released seemed to follow.

What i wanted here was to have a separate joystick(gamepad) or keyboard and pressed or released. Dpad is a pard of game controller. So in byte form we can either have
00, 01, 02, 03 for combination of 2 bools or
00, 01, 10, 11 either of them is fine.

---

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

That doesn't make any sense to me as (char) (joystick << 16) + pressed is identical to (char) pressed

From above if I have two{a,b} bools {0,1} and I want to get {00, 01, 02, 03} I am doing
2 * a + b

What should i do with bit shifting if I want {00,01,10,11} ? probably 4 rather than 16 :|
(a << 4) + b

Edit : Here is the hexadecimal o/p

00000000: 0140 0000 4f  .@..O   // keyboard Press
00000005: 0040 0000 4f  .@..O   // Kb release
0000000a: 1100 0000 c7  .....   // Joystick press
0000000f: 1000 0000 c8  .....   // Js release

[Hex]

@recompile I tried your code without deadzone. Xbox controller Dpad works as expected. Analog sticks dont work at all. Is this what you were after?

SNES Dpad doesnt work with your code. as there is no reset event sent it always remains triggered after first press

I was trying to get the analog sticks to work too like buttons hence the confusion.

[recompile]

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

This is flawed. At rest my event.jaxis.value is 0. Which is okay. When analog stick is moved very little event.jaxis.value will not be 0 and trigger an event. We dont want that. It should be a lot of movement before event gets registered. else you will end up with over sensitive response. Get it?

I do, but that's not what your 'deadzone' code does. I followed your lead there, as that was what you seemed to want. As you're worried about values close to 0, I explained how to deal with that earlier. That explanation is adapted here:

// Normalize
normValue = 0;
if(event.jaxis.value > 500)
{
normValue = 1;
}
else if (event.jaxis.value < -500)
{
normValue = -1;
}

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

What should i do with bit shifting if I want {00,01,10,11} ? probably 8 rather than 16 :|
(a << 8) + b

Bit shifting is just bit shifting. Say I have the number 8:

   8 = [0000 1000] = 8
8<<1 = [0001 0000] = 16
8<<2 = [0010 0000] = 32
8>>1 = [0000 0100] = 4
8>>2 = [0000 0010] = 2

1 byte is 8 bits, So if you have a 1 and shift left by 16, you'll end up with 0, as the one bit that makes up your 1 gets dropped off the end. The same is true if you try to shift left by 8, you'll drop that 1 right off the end.

If you want to pack bools together in to a byte, you just need to shift them left to the position you want. let's pack bools a,b,c, and d in to a byte in that order.

mybyte = (a<<3) | (b<<2) | (c<<1) | d;

(The | operator is bitwise-or Let me know if you don't understand why I've used it.)

To answer your question What should i do with bit shifting if I want {00,01,10,11} ? :

bytes[0] = (char) ((joystick << 1) | pressed);

A left-shift is just like multiplying by two (see the earlier example). So that is actually equivalent to your old code (from memory, but I think this is what you had):

bytes[0] = (char) (joystick * 2 + pressed);

The only reason I can see to change that would have been to clarify your intent, but a comment would have done that just as well.

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

What i wanted here was to have a separate joystick(gamepad) or keyboard and pressed or released.

If you want to use event types 2 and 3 for buttons as well as dpad, I guess that's fine, you just have to make sure you're using unique values. We've got 32 bits to work with, so you could just shift all the dpad values in to the next byte, leaving the lower 8-bits for buttons. You really only need two bits, my example used four for clarity. We've got bits to spare, so it doesn't cost anything to add a bit of readability.

[Hex]

@recompile So it was not 16 or 8 but 4 that got me what i needed. I read up on bit shifting after that and your solution in pretty neat.

I have updated the source.

---

Currently this is what it does:

• first nibble (4bits) is Joystick(1) or keyboard(0)
• second nibble is pressed(1) or released(0)
• Hat events start from 99 (offset of 100)
• Joystick analog start from 199 (200 offset)

// Since norm can have 3 values (3*) and axis is {0-5}
key = 200 + 3 * event.jaxis.axis + normValue;

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

normValue = 0;
if(event.jaxis.value > 500)
{

Here 500 is your deadzone value. I have taken the deadzone value form ES. Our codes are identical

if(abs(event.jaxis.value) <= DEADZONE)
	normValue = 0;
else
	if(event.jaxis.value > 0)
		normValue = 1;
	else
		normValue = -1;

---

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

If you want to use event types 2 and 3 for buttons as well as dpad, I guess that's fine, you just have to make sure you're using unique values.

I have shifted to a new notation described above rather than 2,3.

I have tested it multiple times with both controllers. It does produce unique events.

Just so you know, L&R trigger (not shoulder) buttons create 4 types of events. combinations of Released, half click and full click. You might have to check how to handle those or skip them all together.

[Hex]

@recompile Can you update the source. I Uploaded the rotation testing file by mistake earlier.

[recompile]

@hex Unfortunate. I gave up and fixed hat, etc. myself. I tried to change as little as possible. Well, you can merge, I guess.

http://drichardson-shared.s3.amazonaws.com/sdl_interface.cpp