[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
/// Micro-optimized, vertically-wrapped sprite display functions
|
|
|
|
|
|
/// ------------------------------------------------------------
|
|
|
|
|
|
// All of these assume that the caller
|
|
|
|
|
|
// • has set ES to the beginning of a VRAM plane (e.g. 0xA800)
|
|
|
|
|
|
// • and has set the GRCG to RMW mode. Consequently, the GRCG also isn't
|
|
|
|
|
|
// turned off before returning from any of these functions.
|
|
|
|
|
|
|
|
|
|
|
|
// Displays the tiny-format 16×16 sprite with the given [patnum], wrapped
|
|
|
|
|
|
// vertically. (Identical to master.lib's super_roll_put_tiny().)
|
|
|
|
|
|
#define z_super_roll_put_tiny_16x16(left, top, patnum) \
|
|
|
|
|
|
_DX = top; \
|
|
|
|
|
|
_AX = left; \
|
|
|
|
|
|
z_super_roll_put_tiny_16x16_raw(patnum);
|
|
|
|
|
|
void pascal near z_super_roll_put_tiny_16x16_raw(int patnum);
|
2020-02-08 12:05:07 +00:00
|
|
|
|
|
|
|
|
|
|
// Like z_super_roll_put_tiny_16x16(), but adapted for 32×32 sprites.
|
|
|
|
|
|
#define z_super_roll_put_tiny_32x32(left, top, patnum) \
|
|
|
|
|
|
_DX = top; \
|
|
|
|
|
|
_AX = left; \
|
|
|
|
|
|
z_super_roll_put_tiny_32x32_raw(patnum);
|
|
|
|
|
|
void pascal near z_super_roll_put_tiny_32x32_raw(int patnum);
|
[Maintenance] [th04/th05] Improve the z_super_roll_put*() naming convention
So, master.lib has:
• super_put_tiny() for tiny-format 16×n sprites
• super_roll_put_tiny() for vertically wrapped tiny-format 16×16
sprites
• super_put_tiny_small() for tiny-format 8×n sprites
• yet *no* super_roll_put_tiny_small() function
And now we have ZUN adding micro-optimized versions of:
1) vertically-wrapped tiny-format 16×16, clearly based on master.lib's
super_roll_put_tiny(), RE'd in 35f9bd7
2) vertically-wrapped tiny-format 32×32
3) vertically-wrapped non-tiny monochrome 16×16 (TH05 only)
Conclusion: Even though 1) does duplicate a master.lib function, trying
to continue following master.lib's inconsistent naming convention only
leads to more confusion here. master.lib also already designates the _8
suffix to mean "x will be byte-aligned, ⌊x/8⌋*8"…
So let's:
• spell out both coordinates of the sprite size directly in the
function
• keep the z_ prefix to encode ZUN's optimized calling convention
(left/top coordinates in registers, ES already set to the beginning
of a VRAM plane, GRCG already on) for all of these, not just 1).
• and prefix the actual functions with _raw, since C land will want
to handle the coordinate parameter registers in a macro.
Part of P0073, funded by [Anonymous] and -Tom-.
2020-02-06 21:45:59 +00:00
|
|
|
|
/// ------------------------------------------------------------
|