Name the unnamed hram variables and one wram label

[Vortyne]

hFFDC goes completely unused so does it even need to be declared in the union?

[Rangi42]

Delete comments when labels make them obsolete.

Suggested change

	ldh [hSpriteCollisionsTempYStore], a ; store Y coordinate adjusted for direction of movement
	ldh [hSpriteCollisionsTempYStore], a

[Vortyne]

these y coord and x coord stores are used for 2 purposes

• storing y or x coord adjusted for direction of movement
• storing the distance between the two sprites' adjusted y or x values

so I figured these comments would help distinguish, since wSpriteCollisionsTempYCoordOrDistanceBetweenSpriteAdjustedYValue
would be a bit much...hence why I named it hSpriteCollisionsTempYStore initially, due to multiple purposes, all being dealing with Y or X values

[Vortyne]

Maybe I should make them into two?
hSpriteCollisionsTempYCoord::
hSpriteCollisionsDistanceBetweenAdjustedYValues:: db

[Rangi42]

I posted some more label suggestions after reading the file more carefully. Thanks for your patience with all the feedback.

[Rangi42]

Suggested change

	hInteractedWithBookshelf:: db ; set to 0 if you interacted with a bookshelf, $FF if not when attempting to interact with a hidden object
	; when attempting to interact with a hidden object,
	; set to 0 if you interacted with a bookshelf, $FF if not
	hInteractedWithBookshelf:: db

[Rangi42]

Also since hFFDC is gone now, this can merge with the union above it (and I think we don't need the comment after all):

NEXTU
hItemCounter::
hSavedCoordIndex::
hMissableObjectIndex::
hInteractedWithBookshelf::
hGymTrashCanRandNumMask::
	db
ENDU

[Rangi42]

The data for SpriteCollisionBitTable should use a loop:

SpriteCollisionBitTable:
FOR n, 16
	bigdw 1 << n
ENDR

(The bigdw macro will need porting from pokecrystal.)

[Rangi42]

This is used as a 0-15 offset into SpriteCollisionBitTable for the sprite being collision-tested with the "current sprite" (whose corresponding offset is already named hCurrentSpriteOffset).

Suggested change

	hSpriteCollisionsLoopCounter:: db
	hCollidingSpriteOffset:: db

[Rangi42]

First this is initialized to [i#SPRITESTATEDATA1_YPIXELS] with some +/-7 adjustment, and stored in [i#SPRITESTATEDATA1_YADJUSTED]. Then the absolute difference between [i#SPRITESTATEDATA1_YADJUSTED] and [j#SPRITESTATEDATA1_YADJUSTED] is stored in it , and used to calculate hSpriteCollisionsAdjustedDistance. It also has a "7 or 9 depending on sprite i's delta Y". I think it has enough overlapping purposes in the collision code that it can be thought of as a generic "Y-related temp value".

Suggested change

	hSpriteCollisionsTempYCoord:: db
	hCollidingSpriteTempYValue:: db

[Rangi42]

Suggested change

	hSpriteCollisionsTempXCoord:: db
	hCollidingSpriteTempXValue:: db

[Rangi42]

This is used for both the Y and X distance, so:

Suggested change

	hSpriteCollisionsAdjustedDistance:: db
	hCollidingSpriteAdjustedDistance:: db

[Rangi42]

Thanks a lot! Getting closer to 100% :D