I'm having an issue locking movement to 4 directions.
If you hold left arrow then hold right arrow, it will ignore the right arrow. But if you do it the opposite direction it triggers left even if the variable is set to the other direction. Likewise, if you hold up arrow, then you hold down arrow it ignores down. But doing the opposite does the same problem as left/right. I think its a bug or something with gens emulator? Here is the code.
if ((player1.current_anim == ANIM_STANDSIDES) | (player1.current_anim == ANIM_STANDDOWN) | (player1.current_anim == ANIM_STANDUP)) {player1.lockdir = 1; }
if ((value & BUTTON_UP) && player1.lockdir == 1) player1.lockdir = 2;
if ((value & BUTTON_DOWN) && player1.lockdir == 1) player1.lockdir = 3;
if ((value & BUTTON_LEFT) && player1.lockdir == 1) player1.lockdir = 4;
if ((value & BUTTON_RIGHT) && player1.lockdir == 1) player1.lockdir = 5;
if ((value & BUTTON_UP) && player1.y > 5 && tileproperty == TILEPROP_NOTSOLID && player1.lockdir == 2) { player1.y -= 1; SPR_setPosition(&sprites[player1.zorder], player1.x, player1.y); }
if ((value & BUTTON_DOWN) && player1.y < 176 && tileproperty == TILEPROP_NOTSOLID && player1.lockdir == 3) { player1.y += 1; SPR_setPosition(&sprites[player1.zorder], player1.x, player1.y); }
if ((value & BUTTON_LEFT) && passScreen == 1 && tileproperty == TILEPROP_NOTSOLID && player1.lockdir == 4) { player1.x -= 1; SPR_setPosition(&sprites[player1.zorder], player1.x, player1.y); }
if ((value & BUTTON_RIGHT) && passScreen == 1 && tileproperty == TILEPROP_NOTSOLID && player1.lockdir == 5) { player1.
Locking directions issue
Moderator: Stef
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Re: Locking directions issue
Considering that physically on a dpad you can't press both left and right, I'm not sure what the system will give you.
You could also check for button presses instead of button state. A press being a button up state on the previous frame and a button down state on the current frame.
You could also check for button presses instead of button state. A press being a button up state on the previous frame and a button down state on the current frame.
Re: Locking directions issue
Yeah, i am just making sure if they play on an emulator they can't do that.djcouchycouch wrote:Considering that physically on a dpad you can't press both left and right, I'm not sure what the system will give you.
You could also check for button presses instead of button state. A press being a button up state on the previous frame and a button down state on the current frame.
Re: Locking directions issue
Yeah, emulators explicitly override directions like that, apparently a few games freak out if you press opposite directions. Fusion lets you disable this if you need to test this behavior.
Real hardware in theory will just give you nothing because the D-pad ends up centered and hence pressing nothing. In practice you can end up getting it to press opposing directions if you push too hard, so better to account for it if you can (even if it's "ignore both presses").
Real hardware in theory will just give you nothing because the D-pad ends up centered and hence pressing nothing. In practice you can end up getting it to press opposing directions if you push too hard, so better to account for it if you can (even if it's "ignore both presses").
Sik is pronounced as "seek", not as "sick".
Re: Locking directions issue
Oh i see. I'll take account for that.Sik wrote:Yeah, emulators explicitly override directions like that, apparently a few games freak out if you press opposite directions. Fusion lets you disable this if you need to test this behavior.
Real hardware in theory will just give you nothing because the D-pad ends up centered and hence pressing nothing. In practice you can end up getting it to press opposing directions if you push too hard, so better to account for it if you can (even if it's "ignore both presses").
Thanks.