gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

C/C++ > HAM button problem

#100093 - cppdungeon - Sat Aug 26, 2006 2:22 am

the program is supposed to let the user choose from 3 options, but when you press "down" it skips from 1-3. is there a way to fix this? (im using HAM)

Code:
#include <mygba.h>
#include <iostream>
#define A 1
#define B 2
#define SELECT 4
#define START 5
#define RIGHT 16
#define LEFT 32
#define UP 64
#define DOWN 128
#define R 256
#define L 512

volatile unsigned int *buttons = (volatile unsigned int *)0x04000130;

MULTIBOOT

int main(void)
{
   ham_Init();
   ham_InitText(0);

   bool button [10];
   int sp;
   sp=0;



   //bg select block
   while(TRUE)
   {
   ////////////////////////////////
   button[0] = !((*buttons)& A);
   button[1] = !((*buttons)& B);
   button[2] = !((*buttons)& SELECT);
   button[3] = !((*buttons)& START);
   button[4] = !((*buttons)& RIGHT);
   button[5] = !((*buttons)& LEFT);
   button[6] = !((*buttons)& UP);
   button[7] = !((*buttons)& DOWN);
   button[8] = !((*buttons)& R);
   button[9] = !((*buttons)& L);
   ////////////////////////////////
       ham_DrawText(0,0, "Choose Mode");
       if(button[7] && sp!=-2){
           sp--;
       }
       if(button[6] && sp!=0){
           sp++;
       }

       if(sp==0){
       ham_DrawText(0, 1, "choice one  ");
   }
       if(sp==-1){
       ham_DrawText(0,1,  "choice two  ");
   }
       if(sp==-2){
       ham_DrawText(0,1, "choice three");
   }

   }

   return 0;
}


/* END OF FILE */
[/code]
_________________
"in Soviet Russia, car pimps you!"

#100139 - gmiller - Sat Aug 26, 2006 3:00 pm

It would appear that you do not have any delay in the code so it is constantly running. When you press a button if the code is running fast enough you could see it down multiple times. If you buffer the last state of the key you could work without delay (compare last state to current state, if different use the new key value). other wise you might want to wait for VBLANK to slow things down. I would buffer the keys anyway and I would not use boolean values because a single long would do (of course a short would do as well but the native operation of the ARM is 32 bit). I avoid 'int' because that size is not defined by the standard as a particular number of bits. I use long because it is 32 bit in the standard and short/char. The implementation of 'int' is up to the compiler writer not the hardware or the standard.

#100151 - tepples - Sat Aug 26, 2006 4:00 pm

gmiller wrote:
I avoid 'int' because that size is not defined by the standard as a particular number of bits. I use long because it is 32 bit in the standard and short/char. The implementation of 'int' is up to the compiler writer not the hardware or the standard.

It's also up to whoever specifies the platform's application binary interface (ABI). In this case ARM Ltd. has specified that 'int' shall be 32 bits. What happens when you port to a machine where 'long' is 64 bits? My suggestion is to use 'int' for loop counters and 'u32' for data structures.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#100161 - gmiller - Sat Aug 26, 2006 4:52 pm

I believe that the standard say that short is 16, long is 32 and long long is 64. But int on the same CPU can be 16, 32, 64 based on the compiler writer. This was a problem when switching between SPARC, RS6000, Alpha, Intel CPU's for me so I switched to using types with defined lengths.

#100169 - tepples - Sat Aug 26, 2006 5:45 pm

gmiller wrote:
I believe that the standard say that short is 16, long is 32 and long long is 64.

Actually the standard states that short >= 16, long >= 32, and long long >= 64. It does not state the size of int, except that short <= int <= long <= long long.

Quote:
But int on the same CPU can be 16, 32, 64 based on the compiler writer.

Still, on any target system better than an 8-bit micro, any competent compiler developer will make 'int' the fastest integer type that the compiler supports. So use 'int' for loop counters smaller than 32000 unless you have a good reason not to.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#100183 - keldon - Sat Aug 26, 2006 6:56 pm

tepples wrote:
Actually the standard states that short >= 16, long >= 32, and long long >= 64. It does not state the size of int, except that short <= int <= long <= long long.


So does that mean that 8-bit processors need to break the standard? I'm sure the gameboy compilers have int as 16bit and short as 8 bits (but I can't be too sure). And when compiling for the 286 I'm sure I remember it being something similar.

#100199 - tepples - Sat Aug 26, 2006 8:15 pm

C was originally developed on and for 16-bit processors. C compilers for 8-bit processors tend to make 'char' the fastest variable type (see cc65 coding hints).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#100207 - keldon - Sat Aug 26, 2006 8:34 pm

Oh yeah!!!