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



Yes, but for some reason the mbed online IDE still doesn’t support C++11.
Apart from PlatformIO, which takes some fiddling still,
we don’t yet have an out-of-the-box IDE with C++11 support that works on mac and Linux.

Besides which, I find that many tutorials and programmers have been slow to catch up with C++11, let alone C++14 or C++17.

Yes, you’re using binary literals. Binary literals were only added in C++14.

That’s expected, GCC supports binary literals as a compiler extension.
Because of the extensions, GNU++98 isn’t the same as C++98.

I find that strange if the binary literals are still present.
I would have thought using C++11 over GNU++11 would disable compiler extensions.
Perhaps it just generates a warning instead?

Yes, perhaps so. I’ll adnit to being overly pedantic at times.

Nor do I sadly, I’ll have to look it up sometime.
I suspect it falls under the umbrella of ‘template substitution’.

Ah, that C++ reference.

When you said the C++ reference I assumed you meant cppreference because it was the only C++ reference that had been mentioned up until that point.
That explains why I couldn’t see the example at cppreference.

Sorry, when you were talking about random, I assumed you were still talking about compiling for the Pokitto, which does have a random function.

Aparently random is in GNU C stdlib.h for BSD support.

Hrm, interesting.
Particularly given that most of the different implementations tend to start peaking at around the same time.

But this is a case where there’s a provable difference, in which case using an alternative would be justified if that extra performance was neccessary.

Well then, perhaps you’re more intelligent than me too.

Yes, but as I also said, these tend to be less frequent when people have the knowledge to understand the complexities involved and when they check everything through.

Ah yes, Apple’s bug was hilarious.
I’m amazed it got accepted into the production code without being spotted.
The compiler would surely have given an ‘unreachable code detected’ warning.


You really shouldn’t. Programming is not about the language. A programming language is only a tool to solve a problem – not the solution.

You’d be surprised how little the people at the best places (Google, Microsoft, Facebook, Apple, and some universities), people that went to the world finals of ICPC, know about the language they use everyday.

I say this because I have many close friends at such places, and while you clearly knows much more about C++ than me, I can still confidently say that I know more about C++ (and other languages) than most (maybe all) of these friends.

But knowing these guys and what they do with what they know, I’d be stupid to brag and pedantically correct them over little things like this.

I looked it up and didn’t find anything in particular.
As I was talking about the restrictions rather than the “replaceable” part of the declaration, I still think that signature is about right. The third argument (“gen”) should be a callable that takes one argument and produces one return. That description is not negotiable.

Anyway… thank you for your help overall. I ended up using std::function to replace the Pokitto::Buttons::repeat with indirect calls for leftBtn and rightBtn.
I hope this fix the problem. I played a little and didn’t have trouble so far,

Changing subject, my highscore for those who feel like competing:


I’m sorry for the double post. Unfortunately, I was mistaken and the problem actually persists. I just played a match and faced it.

Since I’m using leftBnt() and rightBtn(), perhaps this reinforces @Pharap 's theory about some issue with the interruptions? The button release is not being properly registered.

edit: something I’d like to add. Every single time I had this problem, it was always with the same button: the right button. I never had this issue with the left button, even though it’s used as much in the game.


Hmm while playing, when moving I still get stuck going in a direction from time to time… I know you tried to fix it but even on the latest it is still doing it for me…

Also talking about scores, highscore saving would be great if you want to add a little something.


Thank you so much for reporting… I also noticed that the problem persists.

As I mentioned in my last reply, at least for me, it always get stuck going to the right, and I have never had this problem for the left button. Is the issue like this to you as well?


If I remember right it did it to me when I when left as well.


As soon as I have time, I’ll take a look at your button handling code

Edit: in your CheckInput function, try buttons::leftBtn() and rightBtn() methods instead of pressed(). They are lower level functions


First, thank you so much for using your time to take a look at this. Actually, I’m already using leftBtn and rightBtn. I only use pressed for buttons A, B and C. I’ll take this opportunity to clarify.

Inside CheckInput, I have the following code.

if (btnHolderRight() && robot_at != 6) {

Its the only place where I increment robot_at and make the player go to the right. btnHolderRight is an instance of BtnHolder, a callable struct. We see that btnHolderRight() must return true in order to the player go to the right. It’s a requirement.

When we call bntHolderRight, we are calling the following code:

bool operator()() {
  if (isDown()) {
    frames ++;
    return frames == 1 || frames == 6 || (frames >= 9 && frames & 1);
  } else {
    frames = 0;
    return false;

This expression

frames == 1 || frames == 6 || (frames >= 9 && frames & 1)

doesn’t really matter. What matters here is that isDown() must return true so that btnHolderRight has any chance of returning true, and only then the player moves to the right.

What is isDown?
isDown is declared here:

std::function<const uint8_t(void)> isDown;

It’s basically a function pointer that points to Pokitto::Buttons::rightBtn, as follows:

BtnHolder btnHolderRight(pokitto.buttons.rightBtn);

This means that if the robot keeps moving to the right while I’m not holding the right button down, then rightBtn must be returning a value != 0 while I’m not pressing the right button down.

Edit: Just one observation… isDown should be declared as

std::function<uint8_t(void)> isDown;

since the return type (uint8_t) isn’t a pointer or a reference. I didn’t have any reason to put that const there and I don’t know why I did. I’ll remove it for the sake of simplicity.

Edit 2: in some of the previous posts I said that I was previously using Buttons::held when I was actually using Buttons:repeat. Edited those posts to reflect reality. Sorry about that.


Ok… I think that now I may have fixed the problem… by not using the utility functions from Pokitto::Buttons :confused:

I commented out the use of leftBtn and rightBtn and I’m getting whatever is in Pokitto::heldStates directly.
I played a full match (got 6000+ points) with no sight of the bug.
I hope this will end the problem.

// BtnHolder btnHolderLeft(pokitto.buttons.leftBtn);
BtnHolder btnHolderLeft([](){return Pokitto::heldStates[BTN_LEFT];});
// BtnHolder btnHolderRight(pokitto.buttons.rightBtn);
BtnHolder btnHolderRight([](){return Pokitto::heldStates[BTN_RIGHT];});

Version 1.03: raquer.bin (68.9 KB)


Thanks for share. I’ve also experience btn stuck problem in other Pokitto project, but never dig it out.


The problem still exists :frowning:
It took me two matches to fall into the bug again. But I did :frowning:

Ok… So how we say in Brazil, “the hole is further down”. The data in Pokitto::heldStates is wrong sometimes, and that’s lower level than Pokitto::Buttons and used by it.

@Vampirics mentioned that, if he/she recalls correctly, he/she has the problem with the left button as well. Meanwhile, I only have the problem with the right button. Can this be a hardware problem?


I’ll try to recreate the problem on my Pokitto


Let’s help you to make your post shorter by letting you know something. I am a ‘he’ . At least you didn’t call me ‘it’ LOL


Indeed, programming is generally about problem solving, but languages have many features and some features provide better solutions than others, so it pays to be aware of the possibilities.

If languages were completely unimportant then people wouldn’t be as passionate about which languages they prefer.

I don’t think I would be to be honest.

Programming for a company is a very different environment to coding as a hobby/for enjoyment.
Companies are fundamentaly results-driven, so deadlines are rife and the destination tends to matter more than the journey.

(I’d never heard of the ICPC, I had to look that up.)

I hope you’re not trying to imply that’s what I’m doing.

In this case the restrictions are defined by the substitution stage.
The function only fails to instantiate if the arguments passed to it can’t be subtituted into one of the expressions in the body of the template function.

When digging through the standard I discovered that there is actually a technical definition of ‘signature’ defined in the standard, and for non-template functions it doesn’t include the return type.

(I also discovered various other technical distinctions that I wasn’t aware of, like the difference between ‘parameter’ and ‘argument’.)

Just to let you know, the Pokitto library already counts the number of frames that the button is held for.

You can retrieve that with uint8_t Pokitto::Buttons::timeHeld(uint8_t button).

I have a feeling we encountered this problem once before, a long time ago.

At any rate, I think this makes the possibility of the interrupt queue overflowing more likely.
I don’t know if the queue drops new input or overwrites old input, but either would be a reasonable explanation.


Well … not everyone is like this. And one doesn’t need to know everything about a programming language to develop preference.

I don’t believe that a majority of people that goes to ICPC or work at these companies don’t enjoy
the journey of programming. They simply care more about the problem they are trying to solve than the intricacies of the tool they are going to use to materialize their solution. In many aspects, Computer Science is older than computers and programming languages.

Ok… you actually triggered old memories of mine. Yeah… I remembered learning about signature when learning what information the compiler needed to refer to a function uniquely. The signature in C++ only takes into account the type of the parameters due to function overloading. I also remember that in C, the signature is only defined by the number of parameters, since there is no function overloading. Edit 4: actually… I was thinking it through, and it didn’t make sense… I think that in C, the signature only includes the name of the function, since there is no overload… Anyway, it’s something like that.
Edit 5: these definitions of signature seem to be very tied to C/C++… People seem to diverge on the meaning of signature and it seems that for C# it’s equivalent to function prototype. That’s an example why it’s oftentimes not productive to argue over terminology. Terminology changes a lot depending on author, specific context, etc. The semantics are what matters <3

Fair enough. “Signature” is not be the best word to describe the restrictions I wanted to describe. Perhaps I should only say “type”? Like… std::function<bool(int)> is a type that’s different than std::function<bool(double)>… and std::function<bool(TMPL_TYPE)> may accept both.

Do you know a single, short word to describe the restrictions?

Edit: replaced the word “define” with “refer to”, since it reflects better what I wanted to say.

Edit 2: there is no problem in calling parameters just arguments. The C++ standard may specify a distinction for the sake of clarity, but in Compilers (as an area of study), parameters are often called “formal arguments” and arguments are called “actual arguments”.

Edit 3: just found a better word to specify the restriction… Expected prototype.
According to wikipedia:


Damn guys… That’s quite an intense discussion in a game release thread…


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


Well said. I concur.


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 :slight_smile:


raquer.bin (69.0 KB)

Edit: it seems official… Played again, set new highscore (17910), no bugs.