Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some buttons not mapped correctly #3

Open
jeffythedragonslayer opened this issue May 25, 2022 · 4 comments
Open

Some buttons not mapped correctly #3

jeffythedragonslayer opened this issue May 25, 2022 · 4 comments

Comments

@jeffythedragonslayer
Copy link

jeffythedragonslayer commented May 25, 2022

I think some of the KEY_ constants are not mapped correctly. I added a .proc to wait until all controller buttons are unpressed in this repo:

https://github.com/jeffythedragonslayer/lorom-template-with-waitpadup

Here is the control flow when holding down, and then releasing each of the buttons.

START		loops at wait_button_start, then fallsthrough the rest
SELECT(back)	loops at wait_button_select, then fallsthrough the rest
A		loops at wait_button_b, then fallsthrough
B		fallsthrough everything
X		loops at wait_button_y, then fallsthrough the rest
Y		fallsthrough everything
LEFT		loops at wait_button_up, then fallsthrough the rest
RIGHT		loops at wait_button_right, then fallsthrough the rest
UP		loops at up, then fallsthrough the rest
DOWN		loops at wait_button_down, then fallsthrough the rest
RBUMP		fallsthrough everything
LBUMP		fallsthrough everything

Tested on Mesen-SX with an XOTICPC GX7 gamepad. Also, I suggest renaming these constants to BUTTON_

@jeffythedragonslayer
Copy link
Author

The XOTICPC GX7 gamepad has A swapped with B and X swapped with Y compared to a snes controller.

@pinobatch
Copy link
Owner

Your underlying bug at wait_pad_allup in revision 7898970 is that you are using the high byte address (cur_keys, defined as JOY1CUR + 1, which is $4219) with constants intended for the low byte (JOY1CUR, which is $4218). To give other users of this template a place I can point should they make the same mistake, I will add a new set of high byte constant definitions to snes.inc.

pinobatch added a commit that referenced this issue May 26, 2022
In #3, a user of the template reported confusion between reading
the controller's entire report as a 16-bit unit and reading only
the high byte as an 8-bit unit.  To make this confusion less
likely going forward, add a set of labels and constants for
reading the high byte for convenience in porting NES code.
@jeffythedragonslayer
Copy link
Author

jeffythedragonslayer commented May 27, 2022

Test results on an 8bitdo: (from before you committed d8770ad)

UP		loops at wait_button_up, then fallsthrough the rest
LEFT		loops at wait_button_left, then fallsthrough the rest
RIGHT		loops at wait_button_right, then fallsthrough the rest
SELECT		loops at wait_button_select, then fallsthrough the rest
START		loops at wait_button_start, then fallsthrough the rest
DOWN		loops at wait_button_down, then fallsthrough the rest
LBUMP		fallsthrough everything
RBUMP		fallsthrough everything
A		fallsthrough everything
B		loops at wait_button_b, then fallsthrough everything
X		fallsthrough everything
Y		loops at wait_button_y, then fallshtrough the rest

@pinobatch
Copy link
Owner

That's more like it. All 8 bits in the high byte (which correspond to the buttons of the NES controller) are causing the expected. Is there a remaining problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants