Commit Graph

2 Commits

Author SHA1 Message Date
nmlgc e4f1718e93 [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-16 21:36:56 +01:00
nmlgc 2f0ca1ccf1 [Position independence] False positives in item functions
Welcome to this new [brand] of reverse-engineering, where we only fix
things that might be mistaken for addresses, without looking deeper
into what the actual functions do… unless that directly leaps into
the eye.

Part of P0057, funded by [Anonymous] and -Tom-.
2019-11-14 00:48:24 +01:00