[Game]Raquer*Mete - A Hack*Match clone for Pokitto

[HomineLudens]

This problem was encountered and solved in another project.

Maybe we should then implement it as standard way of reading inputs?

[Hanski]

Actually, the only thing that I changed (based on what I read), is that now I’m reading directly from the pins instead of from Pokitto::heldStates .

DigitalIn _leftPin(P1_25);
DigitalIn _rightPin(P1_7);
BtnHolder btnHolderLeft([](){return _leftPin;});
BtnHolder btnHolderRight([](){return _rightPin;});

I played for longer at this time:

Excellent! I have occasionally that the same kind of problem in PokittoGP too. I need to test this at some point.

[Vampirics]

So far I see that problem on all the games. Funny thing is that the same games on the pokitto emulator don’t have the issue at all. Unfortunately it sounds more like a hardware problem than anything else.

Please prove me wrong.

[denismr]

So far I see that problem on all the games. Funny thing is that the same games on the pokitto emulator don’t have the issue at all. Unfortunately it sounds more like a hardware problem than anything else.

Have you tested the latest bin I uploaded? It doesn’t have the problem anymore.

[Vampirics]

Have you tested the latest bin I uploaded? It doesn’t have the problem anymore.

Sorry, just tried your latest build, it seems to work nicely now. We should make sure we use the same way you did it on your game in other games then.

[Pharap]

Unless you disagree with me and think that I was ambiguous and confused you somehow with my original sentence.

If you hadn’t added the example code from cplusplus.com then I think yes,
it would have been confusing because, as I say, the function doesn’t expect a specific function signature/prototype/whatever,
it expects an object that satisfies certain contextual constraints.

Perhaps even "std::rand does not have a suitable signature" might have made enough sense, or "std::rand doesn’t accept any arguments".

In this situation, I’m implicitly assuming the existence of the public operator + , that may not exist for V . In that case, it would generate an error because the constraints are not satisfied.

That’s precisely the point, it’s more than just the type of the function’s arguments and its return type that determines whether the constraints are satisfied.

In that context operator+ could be A operator+(A, A) (or A A::operator+(A)),
or it could be B operator+(A, A) as long as B is implicitly convertible to A
or it could be A operator+(B, B) as long as A was implicitly convertible to B or B was implicitly convertible to A - the possibilities are almost endless.

However, I can argue the prototype of a function is directly related to its capacity of satisfying or not a constraint.

Perhaps, but that’s not saying much - pretty much anything could be related to an object’s capacity to satisfy a constraint.

But anyway, we’re just splitting hairs here, let’s just forget the whole thing, it’s becoming tedious.

---

I’ll be sincere… I took a fast look at that thread but I had the impression that this was the direction it was taking, but I would never be the rude foreigner. Ideally, I should be able to achieve the same result just by using the options in Pokitto::Buttons like rightBtn() . Glad you noticed that.

I’m not quite sure what you mean by this.

Do you mean you thought it was going to be a problem with the library?
And that you ought to be able to make the library use input pins instead of interrupts?

As for the ‘rude foreigner’ thing - I have no idea what that means.
‘Foreigner’ in the sense of ‘new to the forum’?
‘Foreigner’ in the literal sense of ‘someone from a foreign country’?

If you mean it literally, I feel like pointing out that almost everyone who has commented on this thread has a different nationality to everyone else.

But about the game… Did you play it?

Personally I haven’t had chance yet.
I rarely get round to trying out games that get posted.

---

Maybe we should then implement it as standard way of reading inputs?

That’s what I mean by “revisiting that debate”.
That was one of the discussions we had in that thread - debating whether to use input pins or interrupts.

The debate starts around here:

About "Moving" question

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.

where @spinal introduces some code using input pins for reading buttons.

And there’s some related discussion here:

[Suggestion]Future of PokittoLib - v2.0

Is there any reason why we don’t simply deprecate interrupt-based button handling? All games do polling in the end anyway (if( button pressed ) ...) and reading from GPIO takes up just as many cycles as reading a variable in RAM. How about inverting the architecture: reduce the Core into a minimal HAL+Loader, with no public API (games wouldn’t even know it exists). Interface libraries (Mode*.h, Arduboy2.h, Gamebuino.h) would build on that to provide the wanted API without having to worry about…

So far I see that problem on all the games. Funny thing is that the same games on the pokitto emulator don’t have the issue at all. Unfortunately it sounds more like a hardware problem than anything else.

If it doesn’t appear on the emulator, that could also indicate that it’s interrupt-related.

[FManga]

If it doesn’t appear on the emulator, that could also indicate that it’s interrupt-related.

Iirc, it does happen in the emulator.

[Pharap]

Does the emulator emulate interrupts at all?

If so then that might further suggest problems with the interrupts.

If not that would imply that the problem is somewhere in the source code rather than a problem with using interrupts.

[FManga]

It does. Otherwise you’d have no inputs and games would halt in an endless loop waiting for timer updates.

[Pharap]

In which case, if using digital input pins solves the problem in both the emulator and on hardware then I think it would be safe to say the problem lies with using interrupts.

(That would only be half the puzzle solved though, someone would have to dig further to find out why the interrupts have that problem.)

[denismr]

Do you mean you thought it was going to be a problem with the library?
And that you ought to be able to make the library use input pins instead of interrupts?

I meant that I had the impression that the supposed solution to the problem discussed in that thread (whatever the solution is) made its way to the library. But it seems to be faulty, since we have this “button stuck” issue when we use functions that belong to the library, like rightBtn(). No matter how it works internally, ideally using rightBtn() should not lead to this kind of problem. That’s all.

I read the pins directly because I believed I could bypass the problem (that can be related to interrupts or anything else that can be going on in the library, it doesn’t really matter).
I’m aware that since I just read the pin once in each frame, I lose the information about changes between two readings. This does not cause any playability problem with this game.

Just one question… For games with lower FPS, if someone presses and releases the button within a same frame, before two calls for update, the lib should still register the pressed() and released() and both should return true in their next reading, even within that frame, since it’s using interrupts. Is this right? Or is the “released” delayed until the next frame? Or still, does it delay the pressed one frame and the released two frames? If it’s the first possibility, although it registers the pressed/released events, how the library defines whether the button is being held? Does it say that the button is still being pressed for the remaining of the frame and “releases” it in the next? Or does the release event set the button as released anywhere within the frame? If it’s the latter, it shouldn’t make any difference whether function like rightBtn() just returned the state of the pin instead of a state variable set by an interrupt handler, right? (I’m not supposing it is the latter. There are reasons for it not to be)

As for the ‘rude foreigner’ thing - I have no idea what that means.
‘Foreigner’ in the sense of ‘new to the forum’?

Sorry. I meant foreigner from the forum. I shouldn’t just get here from nowhere and start calling out people and point fingers. I like the Pokitto and had a good experience with the library so far. Still, it seems there is an issue with the input handling that’s currently in the library since using its functions lead to unexpected behavior.

[FManga]

Or does the release event set the button as released anywhere within the frame? If it’s the latter, it shouldn’t make any difference whether function like rightBtn() just returned the state of the pin instead of a state variable set by an interrupt handler, right?

This. That’s the point I was trying to make in the thread Pharap linked above.

[jonne]

@Pharap @FManga @denismr @HomineLudens , and everybody else

Using interrupts make the buttons react faster (less latency) but leads to the “stuck button problem” in certain cases.

Using polling has more latency, but solves the “stuck button” problem.

@denismr has something in his way of reading the inputs that makes this problem 10x worse than normal

I will make the pokittolib polling by default. We will lose a bit of reaction speed but since this is such a hot issue, I guess it must be done

EDIT: also, in embedded hardware (such as Pokitto) its never a question of “its a hardware/software” issue. It’s always a bit of both and things like 1) noisiness of button components 2) battery charge and logic edge (lo-> high) step “sharpness” all affect the end result. This explains some of the differences.

[sbmrgd]

Maybe a bit off topic but I actually played the game. Really nice but difficult!
Too bad that the highscore isn’t saved…
My current highscore is something like 5000 or so…

[Vampirics]

Yup saving of the score would really add a lot to the game for me. And if you want to pimp the look a little I can always help if needed. (Just PM me if you are interested)

Gameplay is just fantastic.

[jonne]

Wow @denismr, this game is hard

[Vampirics]

Don’t forget you can swap the 2 first tiles in from of you with the other button, it took me a couple games to notice it. And then it gets a bit easier to rack up points.

[jonne]

Ah… I thought you guys were superhuman

[denismr]

Thanks for playing. I’m glad you liked it. I tried to be faithful to the original.

I agree that the game is really hard for beginners, but it actually gets too easy once you get really good at it, since I’m not increasing the difficulty over time. I think that a good balance for both beginners and advanced players would be the game starting at an even slower pace and increasing the speed up to something that’s much faster than the current one. The number of bombs also seems too high. This needs some fine tuning.

The way it is now, I can actually play indefinitely.

@sbmrgd @Vampirics I’ll include persistent highscore as soon as I can.
@Vampirics I’m very open to pimping the look. Do you have any immediate suggestion?

@jonne
In addition to the @Vampirics 's hint, notice that if you are not carrying any piece, you can rearrange the last three pieces in a column. But doing so can be a bit expensive (in terms of time).

[Vampirics]

@denismr

highscore as soon as I can.
@Vampirics I’m very open to pimping the look. Do you have any immediate suggestion?

I don’t know, something like this?

I tried to not go too far from your initial design.
It’s almost something you could drop in lol. And I limited myself to the colours you were using.

Here is the png for the title screen and game HUD without the text and game pieces.