Detecting one button input each time

[zydeoN]

Is there a way of saying:
If(square is pressed and the others buttons are not being pressed) then...
?

Help

[Art]

Yeah, the value of pad.button will be unique if only square is pressed.
Look at the value of pad.buttons.

[zydeoN]

but the problem is that if i only put:
if(square pressed) {...}

and if im pressing square and say triangle the code inside the brackets of the if statement is processed anyway and im pressing triangle too...

[jojojoris]

dont use & but do it this way.

Code: Select all

if(pad.buttons == PSP_CTRL_BUTTON_SQUARE){
    //do something
}

I think this should be it or something like this.

[zydeoN]

It doesnt work jojoris
EDIT: Solved. I just had to do:
if(pad.Buttons & PSP_CTRL_RTRIGGER && !(pad.Buttons & PSP_CTRL_SQUARE)) {...}

and this would only be processed if the user didnt press square..

[Torch]

Is there a way of saying:
If(square is pressed and the others buttons are not being pressed) then...
?

Help

This logic is very different from your solution of if Only Square is NOT pressed.

[zydeoN]

I will just had to add this !(pad.Buttons & ...) to all the buttons.
Btw, why isnt this working:

int pad_ = 0x100000;
if(pad.Buttons & pad_) {...}

The inside of the brackets isnt being processed. I know this uses a bit mask, but they say Buttons is unsigned int. So the problem here could be the type of pad_. What could it be ?

EDIT: just had to use u32 instead of int.

[jojojoris]

actuallt u32 is the same as unsigned int

Code: Select all

u32 i = 0;
unsigned int = 0;

both the same.

[J.F.]

I will just had to add this !(pad.Buttons & ...) to all the buttons.
Btw, why isnt this working:

int pad_ = 0x100000;
if(pad.Buttons & pad_) {...}

The inside of the brackets isnt being processed. I know this uses a bit mask, but they say Buttons is unsigned int. So the problem here could be the type of pad_. What could it be ?

EDIT: just had to use u32 instead of int.

Anything above 0x8000 is kernel only. You won't ever see 0x100000 at user level. That's why there's a kernel PRX floating around to let user mode homebrew check the HOME button.

[jsharrad]

huh? isn't u32 pad_ = 0x100000 just the same as doing u32 pad_ = 1048576 ?

Unless you were thinking of memory addresses ... &0x100000

[Torch]

I will just had to add this !(pad.Buttons & ...) to all the buttons.
Btw, why isnt this working:

int pad_ = 0x100000;
if(pad.Buttons & pad_) {...}

The inside of the brackets isnt being processed. I know this uses a bit mask, but they say Buttons is unsigned int. So the problem here could be the type of pad_. What could it be ?

EDIT: just had to use u32 instead of int.

Anything above 0x8000 is kernel only. You won't ever see 0x100000 at user level. That's why there's a kernel PRX floating around to let user mode homebrew check the HOME button.

I don't understand what you're trying to say here. I doubt the mask values of the buttons are related to any of the memory addresses (and whether or not those buttons are readable under user or kernel mode; Those buttons must be permanently masked by software in the syscall version of the functions, thats all). Anything above 0x7FFFFFFF is kernel (the upper 2GiB of the 4GiB of memory addresses the CPU can access).

Unless I've completely missed a point somewhere =.=*

[SilverSpring]

He is saying the button masks above 0x8000 (ie. the volume up/down, note, screen, etc. buttons) can only be read in kernel mode. Only the the normal keypad buttons (of which are masked to values under 0x8000) are readable when under user mode. It has nothing to do with memory addresses.

[Torch]

He is saying the button masks above 0x8000 (ie. the volume up/down, note, screen, etc. buttons) can only be read in kernel mode. Only the the normal keypad buttons (of which are masked to values under 0x8000) are readable when under user mode. It has nothing to do with memory addresses.

Ok that way... They just got lucky they could split it up like that since the PSP has a limited number of buttons :/

[J.F.]

He is saying the button masks above 0x8000 (ie. the volume up/down, note, screen, etc. buttons) can only be read in kernel mode. Only the the normal keypad buttons (of which are masked to values under 0x8000) are readable when under user mode. It has nothing to do with memory addresses.

What he said. Sorry if that confused people. I meant the values that represent individual buttons in the .Buttons field. Those are defined in the pspctrl.h file. 0x0001 to 0x8000 are "normal" buttons like X, O, LTRIGGER, START, etc. Anything from 0x10000 on up are the "extra" buttons on the PSP like HOME, VOLUME_UP, NOTE, etc.

Every once in a while, you'll see someone complain that their loop waiting on the NOTE button doesn't work, and they're confused since old homebrew had no trouble with that. The old homebrew ran in kernel mode, so NOTE was visible. New homebrew is usually user mode, and so it cannot see that button and the loop waits forever.

[Torch]

moonlight should have added it to kubridge in the very beginning, it would have been really useful.