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

[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

[Hex]

@recompile Hat does not need much. Is that not working with your Controller ?

case SDL_JOYHATMOTION:
	key = 100 + event.jhat.value;
	sendKey(key, event.jhat.value, true);
	break;

//Last bit of value is pressed or released. That works well.

[recompile]

@hex No, that's why I changed it. I also wanted pressed/released events, rather than just the state so hat would look identical to joy.

[Hex]

@recompile

• Can you please test my code and point me what you are expecting and what is happening.
• Can you tell me which keys are not working as expected and on which controller?
• Do you want button, hat and axis events to be identifiable differently?

Any other comments. I am all ears.

[recompile]

This works on my pi3 with my controllers:

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

Your buttons are very likely to be different, which is where config will come it. If you can steal them RetroArch or wherever, we could just send key events instead of joypadbuttons/hat|joy events

I'm out for a few hours... :(

[Hex]

@recompile I am capturing exactly the same data as ES is. Can you test your controller in ES. Force reconfigure input and test if all events are detected as expected.

// ES Code for Hat 
case SDL_JOYHATMOTION:
	window->input(getInputConfigByDevice(ev.jhat.which), Input(ev.jhat.which, TYPE_HAT, ev.jhat.hat, ev.jhat.value, false));
	// Input(int dev, InputType t, int i, int val, bool conf) 
	return true;

// My code for hat
case SDL_JOYHATMOTION:
	key = event.jhat.value;
	sendKey(key << 16, event.jhat.value, true);
	break;

[Hex]

@recompile Your code crashes when moving from joystick to keyboard. Let me run some more tests till you are out. Can you tell me which controller you are using so i can debug.

[Hex]

@recompile Please have a look at the key output generated using my source : https://pastebin.com/K07QU1wu and your source : https://pastebin.com/SC75ebY5

Can you do the same for your controller.

[recompile]

@Hex I think we just wasted a lot of time.

Your goal was to make this a libretro core, right? If that's the case, we're doing things backwards. A libretro frontend with launch C, which will be the libretro core. C will launch J. Libretro will supply C with a 'RetroPad' abstraction for the controller, and other API's.

[Hex]

No actually. My first goal was to get it working and stable. Those modifications will need a fork any ways.

Gambatte, the emu for Gameboy has an application and libreteo core in separate repos. Similarly libretro core for j2me could be done at a later stage when the implementation is stable and consistent.

This project is a great experience for me. Learnt lots. SDL is screwing me with rotation :(

Did you see my files? What do you think?

Edit: is it possible emulate j2me without Java?

[recompile]

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

Edit: is it possible emulate j2me without Java?

Yes and no. Midlets are Java apps, after all, and Java apps run on a Java Virtual Machine. You could write your own JVM, but it's not exactly a weekend project. I say yes and no as writing your own JVM to run j2me games doesn't seem to qualify as running them "without Java", but others might disagree.

I get the sentiment. I don't like Java either.

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

No actually. My first goal was to get it working and stable. Those modifications will need a fork any ways.
[...] libretro core for j2me could be done at a later stage when the implementation is stable and consistent.

You want to maintain two branches just for retropie? We may be at cross purposes.

My primary goal is to play j2me games, on my pi3, on my couch. To that end, we've been successful. The next big thing, for me, is to launch them from ES.

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

Gambatte, the emu for Gameboy has an application and libreteo core in separate repos.

That I understand. It's convenient having different builds for different purposes. When I build, I get the AWT, JavaFx, and RetroPie versions. I can run the AWT and JavaFx builds just about everywhere I want, except my pi3.

What I don't want is to maintain 2 different builds just for RetroPie. Granted, while each build only differs by one smallish (5k-7k) file, I don't even like having both an AWT and JavaFX build as they now serve the same purpose.

I'll add the command line switches you want to the current build, but I'm probably going to step back from this part a bit. Not completely gone, I just won't be putting as much time in to it. You likely won't need much from me for this part anyway as there won't be much, if anything, to change.

[Hex]

@recompile I am in no way prioritizing libretro. We both have same goal. Integrate into Es and retropie.

I just didnt know if ES will officially accept it or not without libretro and hence i suggested it. It is no way important if retropie is ok without libretro support.

We are pretty much headed in the same direction.

Edit : Can you tell me which controller you are using. Your program is crashing with segmentation faults (illegal memory access). I would like to get your controller working with a single source for C so it is easier to maintain. Did you see the paste bin files. What do you think of the syntax? If that works for you and i add your controller support then we are done. I would really like to keep this pace and get this project out of the garage.

Feel free to pass all parameters passed after game Jar to C. That way i can add support as needed without needing changes to J

[recompile]

@hex It's a Logitech f310

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

I just didnt know if ES will officially accept it or not without libretro

I don't know what this means.

[Hex]

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

I don't know what this means.

nevermind. We are not going ahead with libretro

---

We still have to get audio working, key config page and m3g i believe.

Would you be fine with me hosting the project on GitHub after we are done with audio and key config?