ReC98/th04/main/player/option[bss].asm

; The player's options are supposed to lag behind the player's movement by one
; frame, and therefore have to be tracked separately.

public _PLAYER_OPTION_POS_CUR, _PLAYER_OPTION_POS_PREV
_player_option_pos_cur	Point <?>
_player_option_pos_prev	Point <?>
if GAME eq 4
	_player_option_patnum	dw ?
else
	_player_option_patnum = PAT_OPTION
endif
[Reverse-engineering] [th04/th05] Player option position They are supposed to lag behind the player's movement by one frame, and therefore have to be tracked separately. I would have also included TH02, if it weren't for the weird sprite indirection system (not storing X and Y positions directly in the structure, but taking them from a buffer, with their addresses always changing, WTF?!) that absolutely needs separate attention. Part of P0034, funded by zorg. 2019-09-22 21:55:47 +00:00			`; The player's options are supposed to lag behind the player's movement by one`
			`; frame, and therefore have to be tracked separately.`

			`public _PLAYER_OPTION_POS_CUR, _PLAYER_OPTION_POS_PREV`
			`_player_option_pos_cur Point <?>`
			`_player_option_pos_prev Point <?>`
[Reverse-engineering] [th02/th04/th05] Player option sprite number Part of P0034, funded by zorg. 2019-09-22 21:50:13 +00:00			`if GAME eq 4`
			`_player_option_patnum dw ?`
[Maintenance] Use a single per-game, per-binary file for super_*() patnum IDs Since they're determined by the order of sprites in a .BFT file, they're best auto-generated by an enum as much as possible. Part of P0074, funded by Myles. 2020-02-10 20:59:23 +00:00			`else`
			`_player_option_patnum = PAT_OPTION`
[Reverse-engineering] [th02/th04/th05] Player option sprite number Part of P0034, funded by zorg. 2019-09-22 21:50:13 +00:00			`endif`