Arcade with Joystick

We used the MicroBlocks "Key & Mouse" library to emulate arrow keys in a Snap! Pacman game. (A HyperDuino shield is being used with the Metro to make the physical connections.) In the 15-second video, the joystick is connected to a MetroM0 Express controller. The microcontroller translates movement of the joystick into the keypresses (arrow keys) that move the sprite in the Snap! game:

Here's a link to a description of the MicroBlocks code:

@bromagosa As you can see from the video, it works but the movement is "bursty"; that is, there's a bit of stutter, especially in the second half of the video. Since control is very smooth and playable using the arrow keys on the computer keyboard, we think that this may be in the key emulation in MicroBlocks. However, we thought we would check with you to see if you have any thoughts?

In case it is useful, here is a link to the MicroBlocks joystick code:

Also, here's a link to the Pacman game, so that you can judge the smoothness of the controls using arrow keys on the computer keyboard:

(Thanks to @loucheman for the remix!)

Maybe in the microblock program (or in the snap program ?), you can wait after receiving a keypress and durign this waiting time, you will discard any inputs until this waiting time is over

What @loucheman said is right. I think you're missing some delay. Actual keyboards do not send keystrokes constantly when you press a key, they send them in intervals. These are customizable by the OS, but a repeat rate of around 100ms seems to be rather standard.

That is:


Let me know whether that helped :slight_smile:

Thanks for this recommendation. We tried adding a wait, but a 100 ms wait degraded the performance substantially. We tried other values ranging from 10 ms to 200 ms, with no improvement.

The issue is that there's a delay, not that there is no delay. They're not trying to replicate the when key pressed block (which, by the way, only has a delay after the first time you press the key, no delay after that).

To get a sense of how much of the latency and stuttering is due to system constraints, we implemented the joystick control with MicroBlocks Snap!Bridge library:

This version was much smoother and easier to use than the version using the MicroBlocks "Key & Mouse" library (in the form that we implemented it).

So (somewhat encouragingly), it is possible to create a playable joystick control for a Snap! game using MicroBlocks. We just haven't figured out the conditions needed to optimize an implementation with the MicroBlocks "Key & Mouse" library.

Thanks to everyone for all of the helpful suggestions that have enabled us to get to this point.

I have no hardware compatible with the MB HID API, but there is a remix of the project with event driven keyboard handling.
Pacman -  remix^2 Loucheman Glenbull script pic (1)^2%20Loucheman%20Glenbull&noRun&editMode

I may try wireless BLE HID with the ESP32 board, if time permits.

Not really. There are two kinds of delays with keyboard keystrokes: keyboard repeat delay and keyboard repeat rate. The first is what you're referring to, the second is what I was referring to. If there was no delay while you're holding a key down, at a standard keyboard polling rate of 1,000Hz, you'd see a thousand letters appear in your screen if you held your key down for just one second. Obviously, that's not the case :slight_smile:

Let me investigate. I think I know what's going on. Will come back to you later...

Okay. I've added a couple new blocks to the MicroBlocks keyboard library:

hold key ()


release all keys

The issue with the [ press key ( ) ] block is that it simulates pressing and releasing a key, when what you really want is to hold it pressed.

With these new primitives you can simulate holding a key down while the joystick is in a particular position, then releasing all keys when it goes back to the center.

These changes are now in our repository, but I don't know when John plans to release the new pilot. How comfortable are you with flashing a custom VM?

We'll check with John to see when he might be able to work this into his queue. If it will be a long time before he can get to it, we could give this a shot if there are some directions.

Once we have an estimated timeline from John, we'll check back with you.

Thanks so much for this solution. The MicroBlocks key library has much lower overhead than Snap!Bridge, so if timing issue can be resolved, we anticipate that this will be widely used. (Thanks!)