About "Moving" question

@79859899 : you have to post the complete code / give me a link to the code. I need to see your main game loop.

Using buttons inside a game loop is not simple. You have to understand how the button functions work.

@Pharap : Pokitto::Buttons::upBtn() etc. is instantaneous. What is happening here is @79859899 is expecting a buffered behaviour.

In other words, the plane moves, but in one update cycle of the screen the plane comes back to its original position.

1 Like

I agree.
Seeing the whole code would be a lot more helpful than just small snippits.

Are you sure? That’s not the impression I was getting.

I thought the problem was that sometimes the buttons were being pressed but it wasn’t being registered, hence:

Thank you, Jonne and Pharap
This is my total sourse:
https://os.mbed.com/teams/Pokitto-Community-Team/code/Pokitto_Game_Lost/

1 Like

I am not able to reproduce the issue / maybe I do not understand what you mean

@79859899 I have improved the button handling just a little bit.

Pokitto_Game_Lost_LPC11U68.bin (51.9 KB)

Right-click on PokittoLib folder in compiler, update PokittoLib and see if this removes any problem

I know it’s possible under certain circumstances to be holding one of the dpad directions and for it to not be registered as 1 in Pokitto::heldStates.
It’s not particularly common but it happens.

It’s hard to tell exactly what the circumstances are though, it happens occaisionally when pressing lots of dpad directions in quick succession.

When it happens, say for example left is held down but the corresponding entry in heldStates is 0, you’d still be able to get up and down to register by pressing on up and down without letting go of left, but left won’t register as 1 until you let go and press it again.

Originally I thought it was the dpad being unable to hold a button down under certain circumstances, but upon looking at the button code I’m beginning to suspect the issue could be that the Pokitto can only handle a certain number of interrupts at a time, and having too many at once causes some interrupts to be dropped from the queue.
(I tried marking heldStates as volatile as a precaution, but the button situation still happened.)

I have added code in mbed to clear opposite direction flag when other direction is pressed.

IMHO it helped. Try the binary above.

I will update the github also later today

Hi jonne:
I ran your compiled game, but the problem still happened.
sorry, I cant upload the video to youtube, because im in China.

this is the video that I reproduced:VID_20180418_162730.zip (3.1 MB)

1 Like

The new bin actually seems to make it easier to get the dpad into the state where the button is held but not registered.

Rather than just trying to explain, I’ll provide a video that hopefully makes it clear…

Seems I was ninja’d by @79859899, whose video demonstrates exactly what I’m talking about.

I’ll post mine anyway:

ButtonStick.zip (1.5 MB)

Sorry it’s not brilliant, but my camera is old and I had to balance it between my knees because I don’t have a tripod and it won’t stand up on its own.

(It’s a .webm in a .zip, let me know if that format isn’t suitable and I’ll convert to something else.)
(This is also the internet debut of my hands.)

Yep. I will take a look later today. It can be fixed, i just need to add a second layer of button state polling

1 Like

Please try this code…
https://os.mbed.com/users/spinal/code/HelloWorld_buttontest/

I had to check the buttons differently in sensitive because of this very reason, sometimes the button presses didn’t register. I couldn’t tell of it was old button presses not stopping in time, or new buttons not starting in time, either way this other method works 100% of the time.

3 Likes

Using this example I couldn’t get the bug to reoccur,
and it certainly wasn’t through lack of trying.

I think it would be worth having a bit-packed uint32_t states[3] instead of several bool states[3], (or maybe uint_fast8_t stats[3]), but I definately think the polling approach looks like it works better.

In fact, this makes me even more confident that the reason the bug happens in the original is because of the use of interrupts - be it due to interrupts getting dropped from the queue or interrupts being disabled temporarily by other code and thus not registered.

1 Like

the problem didn’t happen when running your code.
wishing update api:+1:

2 Likes

I’ve attempted to alter the Pokitto library to use DigitalIn instead of InterruptIn.

https://github.com/Pharap/PokittoLib/tree/digital-in-buttons

If enough people say this approach works better, I’ll make a PR.

Isn’t it so that if you are not using interrupts, the correctness of the button reading is more dependent on the framerate, e.g. how often you call Pokitto::Update()? On second thought, if the framerate is 15 or even 10 fps, is it likely that there could happen a button press and release under 100 ms, which you could then miss (?). But maybe it is a problem if there are fps hiccups, and sometimes it takes a long time before Update is called for a frame.

Possibly, but which games currently run at such low framerates?

I find that usually input only has to be considered once at the start of a game loop.
If it needs to be used several times throughout a game with a slow framerate then depending on the game it should be easy enough to poll occaisionally.

Even if the framerate is made artificially slow then the button update could be made to occur more often than drawing by manually calling the button polling function.

If it causes an issue for any already published games then we won’t use it, but the interrupt approach is currently causing issues for games running at more reasonable framerates.

Ideally we’ll fix the issue in PokittoLib V2 by giving the user a choice somehow.

1 Like

This is why I was using interrupts.

And I have a strong suspicion as to what is happening. @Pharap , @spinal, @79859899 this may be of interest to you also

Remember when I said I had been able to improve the sound output speed? The reason for that was that the ticker interrupt that was part of the mbed core library was made for extreme flexibility (infinite amount of concurrent timers) - not for speed. When I eliminated the mbed ticker interrupt, and replaced with my own, sound interrupt speed went up 2-3 x.

Now, I need to investigate this, but I am almost certain this is the case. The ARM Cortex M0+ should be able to handle the button interrupts no problem at all, and I am surprised that we have this issue (button edge changes not detected).

But then I got a thought. These interrupt handlers are also part of the mbed core. What is probably happening is that all pin interrupt handlers are routed to the same handler provided by mbed core. This means that instead of going to the nested interrupt handler, the interrupts are not nested. They are now all pointing to the same handler! Then, with many button presses, the handler gets overworked (still handling previous interrupt), and we get the end result here.

I have had a very busy few days. Now, in a few hours, I will finally get to investigate if this theory is correct. I will replace the button interrupt handlers with 100% custom code and see what happens.

3 Likes

But why use interrupts instead of just manually checking the pins?

I made a test while ago: use an Infrared receiver connected to Pokitto Header and plot my TV remote protocol. My choice went to use mbed interrupts… but without luck. Now I suspect it was not my fault.

Lets see that code.

The mbed interrupt handling is for the most part very good, but they are not optimized for speed. They are optimized for hardware abstraction.

It is the same thing in Arduino. If you need to make time-critical code, you need to go to port manipulation.

1 Like