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.`

[Maintenance] [th04/th05] Assemble 16-bit .ASM files case-sensitively Otherwise, TASM would simply convert all EXTRN declarations in those files to uppercase. Then, the linker would expect them in uppercase, forcing both the case-sensitive big 32-bit .ASM files and the entire C land to declare them as uppercase as well. For functions with __pascal convention which are always uppercased anyway, this makes no difference. It does matter for regular __cdecl variables, though, and the C declaration of [score_delta] in e6294c2 already showed that we'd then be forced to use macros if we wanted to pretend that these names still had lowercase characters. Doing this for every variable referenced in both C land and 16-bit ASM land gets annoying quickly. So, no need to force this inconsistency if we can get rid of it by slightly uglifying ASM land. Part of P0089, funded by [Anonymous] and Blue Bolt. 2020-04-28 16:10:07 +00:00			`public _player_option_pos_cur, _player_option_pos_prev`
[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			`_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`