GP32 Gp_getbutton Help


pea

developer
Joined
Oct 3, 2004
Messages
1,089
Age
45
Location
New Zealand
Website
www.projectitis.com
Hi guys,

I am having an issue off 'double pressing' on the GP32 using the following source (it works perfectly ok in geepee32). This code handles the main menu for a game:

Code:
	option = -1;
	while (option<0){
  // Draw menu with 'choice' selected
  draw_menu( choice );
	
  button = gp_getButton();
  while(!button){ button = gp_getButton(); }
  while(gp_getButton()){}
  if (button & BUTTON_DOWN){
  	choice++;
  }else if (button & BUTTON_UP){
  	choice--;
  }else if (button & BUTTON_A){
  	option=choice;
  }
  choice = min( max( choice, 0 ), 4 );
	}
	return option;

What this does is:
LOOP
wait for button down
wait for button back up
handle button press
/LOOP

In geepee32 I get this (as I am supposed to):
Press button, nothing happens
Release button, menu moves down one item

In GP32 I get this:
Press button, menu moves down one item
Release button, menu moves down one more item

So I can only ever jump two menu items at a time! Is it my new BLU+ doing funny stuff, or is it my code that is not working properly?

It seems like for every press of the D-Pad, I get a sequence like this:
0 - no press
0
0
0
1 - press here
0
1
1
1
1
1
1
0 - release here
0
0
0
0

Strange aye???
 
Putting a wait loop in there fixed it:

Code:
  while(!button){ button = gp_getButton(); }
  for (i=0; i<10000; i++){ button=button; }
  while(gp_getButton()){}

But its not ideal...
 
Don't you need to bitwise-and the gp_getbutton() with BUTTONA or BUTTONDOWN or something? Otherwise getbutton returns all of the buttons in one value, I think.
 
Yip, I know that, and I do that :) But if no buttons are pressed at all, the value should be 0 I believe. Hence:

Code:
button=0;
while(!button){ button = gp_getButton(); }

would wait until ANY button is pressed.
 
I just store buttons in different states since last button poll like:

* released since last poll
* still pressed
* pressed after last poll
 
Yup! You need some debounce code ..

Here's mine (for GPSDK ;) )

Code:
int MyKeyGet(void)
{
static int last=0,lastbut1=0;
  int curr,send=0;

  curr=GpKeyGet();
  if((last^curr)==0) // needs to be the same on two consecutive tests
  {
   if((curr^lastbut1)!=0) // needs to be different from the last reported state
   {
    send=(lastbut1^curr)&curr; // only send the button that changed
    lastbut1=curr;
   }
  }
  else
   last=curr;
  return send;
}
When buttons are released or no buttons are pressed it sends zero

This waits for a keypress and saves it in 'key'...
Code:
while((key=MyKeyGet())==0) /*nothing*/;
And I also ..
Code:
#define WAITKEY while(MyKeyGet()==0) /*nothing*/;


This should cure it B)
 
Ah, thanks! Now all the nuances come out. 'De-bounce' - I like it :)
Does it only 'bounce' for one read cycle? (i.e. 1,0,1,1,1,1,1,1) and never multiple? (e.g. 1,0,0,1,1,1,1,1) - if so, my loop to count to 10000 is a little overkill :)
 
That's really strange, why does that bounce happen? o_O

In my experiments, I _NEVER_ had problems with bouncing... but then again, I don't know if Mr.Mirko's SDK has anything different in the button polling routine.
 
pea posted on Feb 4 2005 at 03:23 AM said:
Is it Mirko SDK specific, or BLU+ specific?
Are you asking me?
I've only used Mr.Mirko's SDK so far, and I have a FLU.

Of course, the only stuff I've done that had input was my GUI test that has the mouse cursor, and no, when I check the buttons, I don't have it just sit in a while(button==0) loop. :p
 
Last edited by a moderator:
Drag posted on Feb 4 2005 at 03:46 AM said:
That's really strange, why does that bounce happen? o_O

In my experiments, I _NEVER_ had problems with bouncing... but then again, I don't know if Mr.Mirko's SDK has anything different in the button polling routine.
It's because the electrical contacts bounce and rattle. .. unless you go for high-end mercury-wetted contacts :lol:

And if you're using repeating keys (like moving a cursor by pixels) you won't notice it.
If you are selecting items in a menu (press-release-press-release) it may skip.


pea said:
Is it Mirko SDK specific, or BLU+ specific?
Is what specific?
The bounce is a hardware problem :D
 
Last edited by a moderator:
So apparently if you lower the rate that you poll the buttons, you will help reduce the bounce? I'm under the impression that this bounce happens on other systems as well, and not just the gp32.
 
Back
Top