Damn guys… That’s quite an intense discussion in a game release thread…
3 Likes
I’m sorry… This parallel discussion became way off topic don’t even matter anymore.
The given names don’t affect the problem at hand. Let’s be practical.
I’m not used to the PokittoLib’s code at all. I’ll wait and see if @jonne can reproduce the bug and if he can give some pointers to go forward. Also, @Pharap seemed to be onto something with his interrupt queue overflow theory.
This problem was encountered and solved in another project.
Please look at this (old) thread, perhaps it is of help
1 Like
Well said. I concur.
1 Like
Thank you so much. I took a look at it.
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:
Didn’t encounter the bug so far 
Thanks.
raquer.bin (69.0 KB)
Edit: it seems official… Played again, set new highscore (17910), no bugs.
3 Likes
Maybe I’ll shunt it off to a side thread later if people think it’s too distracting.
Remember, when people argue/debate about something it just goes to show that they care. :P
In that case I’ll throw away the majority of the long comment I just wrote.
However there’s one bit that I will post because I think it will clarify something:
Based on your original sentence:
However, if I were going to use it, simple passing std::rand is not an option since it does not have the signature expected by std::random_shuffle.
I think "it does not satisfy the constraints expected by std::random_shuffle" is probably closer.
What I originally meant by “it doesn’t match ‘by signature’ as such” was that it’s the usage that’s important, not the actual signature, because it’s the usage that defines the constraints.
(Should I assume you know enough about C++'s template system to know what I mean?)
Aha, that’s the code I was thinking of. I didn’t have time to track it down earlier.
Here is where I originally stated my ‘interrupt queue’ theory:
So if the solution is using pins rather than interrupts,
does that imply that interrupts might in fact be the problem?
(If so, I’m annoyed I wiped that fork without backing it up first.)
I’m fairly certain that the result of this thread was the code that is currently in the library,
which implies that it didn’t quite fix the problem.
At the time we debated reading pins vs using interrupts,
so now I’m wondering if it might be worth revisiting that debate.
I see what you mean and can agree with you that’s your version of the sentence is precise.
However, I fail to see how my original sentence was ambiguous or unclear.
std::srand has a signature/prototype/whatever that fails to satisfy the constraints of the std::random_shuffle when you try to use the former in the latter (passing the former as the third argument of the latter). That’s the idea.
Terminology is made up, u know? The people behind a technology get to choose. Of course, they try to be consistent… in their inner circle.
In my line of research, I see the same things with many different names everywhere, and things that are completely different (and sometimes opposite) sharing a same name, depending on which inner circle of the literature you are reading.
And the same is reality with programming languages. I just illustrated this with the word signature in the C# context.
It’s vain to discuss terminology, if the communication is effective. Unless you disagree with me and think that I was ambiguous and confused you somehow with my original sentence. If that’s the case, I’m sorry.
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.
But about the game… Did you play it? 
Edit
I realize now that what bothers you is not the terminology per se, but maybe the procedure… Because template tries to use something (class/typename) the way you code it to use that, and fails if it cannot. Like this:
template<typename V> V sum(V a, V b) {
return a + b;
}
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.
However, I can argue the prototype of a function is directly related to its capacity of satisfying or not a constraint.
Maybe we should then implement it as standard way of reading inputs?
2 Likes
Excellent! I have occasionally that the same kind of problem in PokittoGP too. I need to test this at some point.
1 Like
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.
Have you tested the latest bin I uploaded? It doesn’t have the problem anymore.
1 Like
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.
1 Like
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".
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.
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’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.
Personally I haven’t had chance yet.
I rarely get round to trying out games that get posted.
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:
where @spinal introduces some code using input pins for reading buttons.
And there’s some related discussion here:
If it doesn’t appear on the emulator, that could also indicate that it’s interrupt-related.
Iirc, it does happen in the emulator. 
1 Like
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.
It does. Otherwise you’d have no inputs and games would halt in an endless loop waiting for timer updates.
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.)
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)
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.
This. That’s the point I was trying to make in the thread Pharap linked above.
1 Like
@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.
3 Likes