II-17: Initializing wCurKeys and wNewKeys

[kav]

Fixes #75

[evie-calico]

These lds should be on the other side of the "Main" anchor

[evie-calico]

Oh, there isn't an "init" anchor for this chapter. I think the chapter itself needs to be corrected, not just this code.

I can take care of this for you if I have permission to edit your fork.

[kav]

Yeah I put them there so they'd be set as part of updating main but I can add an init section instead after we define them if you'd prefer

[evie-calico]

Yeah, that sounds best. Something like this:

We also need to initialize these when our game starts, so add two more lines:

	; Turn the LCD on
	ld a, LCDCF_ON | LCDCF_BGON | LCDCF_OBJON
	ld [rLCDC], a

	; During the first (blank) frame, initialize display registers
	ld a, %11100100
	ld [rBGP], a
	ld a, %11100100
	ld [rOBP0], a

	ld a, 0
	ld [wFrameCounter], a
	ld [wCurKeys], a
	ld [wNewKeys], a

I think diff syntax would help highlight the new lines but I'm not sure if the leading + signs would be confusing--do we use diffs anywhere else?

[kav]

Diff syntax doesn't show up until adding the brick check two sections later.

+	call CheckAndHandleBrick

I'm inclined to instead introduce variable initialization with a sentence and a comment when initialize the frame counter and then refer to that here. (editing to note this is actually well covered so just needed to add the comment to really make sure we are buttoned)

I think diff syntax would probably be ok here but let me try the other approach first. As a new reader with fresh eyes on all this I think that would make more sense to me.

[ISSOtm]

I can take care of this for you if I have permission to edit your fork.

Since you don't have upstream push access (something maybe we should consider? cc @avivace), an alternative is to suggest the modifications using review comments (they have an exclusive "suggest changes" feature); then it's "only" a two-click operation for the author.

[avivace]

Thank you! The change's contents look good to me; I would just like to tweak a few things before accepting it.

Though, @eievui5 mentioned that the chapter needs something rewritten? If you could look into that, then I wouldn't mind integrating the fix into this PR; but if you can't or don't want to in the next few weeks or so, then we can open a separate issue for it.

I'd suggest we merge this and limit the scope of this PR. Evie also already has "maintain" access to this repository, although direct modifications to a feature branch/PR branch of someone else are discouraged unless:

• the author of the PR is unresponsive / the PR is inactive since a lot of time
• the changes are minimal/editorial

Changes may be suggested with the 'Propose changes' feature of GitHub

[ISSOtm]

Thank you @kav!