gb-asm-tutorial icon indicating copy to clipboard operation
gb-asm-tutorial copied to clipboard

Changing the term "keys" in input routine

Open ghostsoft opened this issue 2 years ago • 3 comments

I wonder if a more console-focused term such as "buttons" could be used instead of "keys" for the following-

  • UpdateKeys
  • wCurKeys
  • wNewKeys

From what I can tell the comments in the code itself uses the word "buttons" and "directions" to refer to the face buttons and d-pad and that "keys" are meant to encompass both of these but I still feel like it's a word not quite suited for the purpose.

ghostsoft avatar Nov 30 '23 09:11 ghostsoft

If it matters: The main reason I used "keys" is because the NES is the first console platform that I learned circa 2000 after having learned the Allegro library, and I carried the habit with me to GBA, my second console platform.

Also libtonc, the GBA counterpart to hardware.inc, uses "keys" all over. Its KI_* and KEY_* constants correspond to hardware.inc's PADB_* and PADF_*.

pinobatch avatar Nov 30 '23 14:11 pinobatch

As a counterexample: pret/pokecrystal uses “Joy” or “Buttons” depending on the context, but never “Keys”. https://github.com/pret/pokecrystal/blob/master/home/joypad.asm

evie-calico avatar Nov 30 '23 14:11 evie-calico

I think "keys" is more meaningful, at least as a teaching tool, as it hints at the low-level nature of reading input on the Game Boy. It's a long way from what most game developers would usually be doing (on any other major platform since the mid-late 90s) i.e. data packets on a serial bus, if not much more high-level 'events'.

A "key" is a momentary switch. Also, as you noted, "key" applies to both groups of inputs -- directions and buttons. They are all keys/switches and identical electr(on)ically.

Anyway, if it were to be changed, I think "buttons" (e.g. UpdateButtons) might give the incorrect impression that it is only concerned with the non-directional inputs. So I'd suggest something more generic, like ReadInput.

To clarifyinfo-dump re. the "low-level nature":

(own research)

Reading input on GB is scanning a key matrix like you might on a microcontroller. This is why reading the input state is complicated.

The two groups of keys -- U,D,L,R and A,B,Sta,Sel -- form two columns, connected to the output pins (bits 4,5) of the rP1 port. The four input pins (rows) of the rP1 port are shared by the two columns. Writing the P1F_GET_{BTN|DPAD} bitmasks to rP1 is setting one or the other column low, exclusively.

quinnyo avatar Jan 21 '24 12:01 quinnyo