📝 Posted:

2023-06-07 23:17 UTC

🚚 Summary of:

P0242, P0243

⌨ Commits:

08352a5...dfa758d, dfa758d...ac33bd2

💰 Funded by:

Yanga

🏷 Tags:

th02

+

rec98

+

gameplay

+

item

+

rng

+

enemy

+

score

+

hud

-

stones

-

OK, let's decompile TH02's HUD code first, gain a solid understanding of how increasing the score works, and then look at the item system of this game. Should be no big deal, no surprises expected, let's go!

…Yeah, right, that's never how things end up in ReC98 land. And so, we get the usual host of newly discovered oddities in addition to the expected insights into the item mechanics. Let's start with the latter:

• Some regular stage enemies appear to randomly drop either or items. In reality, there is very little randomness at play here: These items are picked from a hardcoded, repeating ring of 10 items (𝄆  𝄇), and the only source of randomness is the initial position within this ring, which changes at the beginning of every stage. ZUN further increased the illusion of randomness by only dropping such a semi-random item for every 3^rd defeated enemy that is coded to drop one, and also having enemies that drop fixed, non-random items. I'd say it's a decent way of ensuring both randomness and balance.
  • There's a ¹/₅₁₂ chance for such a semi-random item drop to turn into a item instead – which translates to ¹/₁₅₃₆ enemies due to the fixed drop rate.
  • Edit (2023-06-11): These are the only ways that items can randomly drop in this game. All other drops, including any items, are scripted and deterministic.
  • After using a continue (both after a Game Over, or after manually choosing to do so through the Pause menu for whatever reason), the next (Stage number + 1) semi-random item drops are turned into items instead.

• Items can contribute up to 25 points to the skill value and subsequent rating (あなたの腕前) on the final verdict screen. Doing well at item collection first increases a separate collect_skill value:

  Item	Collection condition	collect_skill change
  	below max power	+1
  	at or above max power	+2
  	value == 51,200	+8
  	value ≥20,000 and <51,200	+4
  	value ≥10,000 and <20,000	+2
  	value <10,000	+1
  	with 5 bombs in stock	+16

  Every 32 collect_skill points will then raise the item_skill by 1, whereas every 16 dropped items will lower it by 1. Before launching into the ending sequence, item_skill is clamped to the [0; 25] range and added to the other skill-relevant metrics we're going to look at in future pushes.

• When losing a life, the game will drop a single and 4 randomly picked or items in a random order around Reimu's position. Contrary to an unsourced Touhou Wiki edit from 2009, each of the 4 does have an equal and independent chance of being either a or item.

• Finally, and perhaps most interestingly, item values! These are determined by the top Y coordinate of an item during the frame it is collected on. The maximum value of 51,200 points applies to the top 48 pixels of the playfield, and drops off as soon as an item falls below that line. For the rest of the playfield, point items then use a formula of (28,000 - (top Y coordinate of item in screen space × 70)):

  

Onto score tracking then, which only took a single commit to raise another big research question. It's widely known that TH02 grants extra lives upon reaching a score of 1, 2, 3, 5, or 8 million points. But what hasn't been documented is the fact that the game does not stop at the end of the hardcoded extend score array. ZUN merely ends it with a sentinel value of 999,999,990 points, but if the score ever increased beyond this value, the game will interpret adjacent memory as signed 32-bit score values and continue giving out extra lives based on whatever thresholds it ends up finding there. Since the following bytes happen to turn into a negative number, the next extra life would be awarded right after gaining another 10 points at exactly 1,000,000,000 points, and the threshold after that would be 11,114,905,600 points. Without an explicit counterstop, the number of score-based extra lives is theoretically unlimited, and would even continue after the signed 32-bit value overflowed into the negative range. Although we certainly have bigger problems once scores ever reach that point…
That said, it seems impossible that any of this could ever happen legitimately. The current high scores of 42,942,800 points on Lunatic and 42,603,800 points on Extra don't even reach ¹/₂₀ of ZUN's sentinel value. Without either a graze or a bullet cancel system, the scoring potential in this game is fairly limited, making it unlikely for high scores to ever increase by that additional order of magnitude to end up anywhere near the 1 billion mark.
But can we really be sure? Is this a landmine because it's impossible to ever reach such high scores, or is it a quirk because these extends could be observed under rare conditions, perhaps as the result of other quirks? And if it's the latter, how many of these adjacent bytes do we need to preserve in cleaned-up versions and ports? We'd pretty much need to know the upper bound of high scores within the original stage and boss scripts to tell. This value should be rather easy to calculate in a game with such a simple scoring system, but doing that only makes sense after we RE'd all scoring-related code and could efficiently run such simulations. It's definitely something we'd need to look at before working on this game's debloated version in the far future, which is when the difference between quirks and landmines will become relevant. Still, all that uncertainty just because ZUN didn't restrict a loop to the size of the extend threshold array…

TH02 marks a pivotal point in how the PC-98 Touhou games handle the current score. It's the last game to use a 32-bit variable before the later games would regrettably start using arrays of binary-coded decimals. More importantly though, TH02 is also the first game to introduce the delayed score counting animation, where the displayed score intentionally lags behind and gradually counts towards the real one over multiple frames. This could be implemented in one of two ways:

1. Keep the displayed score as a separate variable inside the presentation layer, and let it gradually count up to the real score value passed in from the logic layer
2. Burden the game logic with this presentation detail, and split the score into two variables: One for the displayed score, and another for the delta between that score and the actual one. Newly gained points are first added to the delta variable, and then gradually subtracted from there and added to the real score before being displayed.

And by now, we can all tell which option ZUN picked for the rest of the PC-98 games, even if you don't remember 📝 me mentioning this system last year. 📝 Once again, TH02 immortalized ZUN's initial attempt at the concept, which lacks the abstraction boundaries you'd want for managing this one piece of state across two variables, and messes up the abstractions it does have. In addition to the regular score transfer/render function, the codebase therefore has

• a function that transfers the current delta to the score immediately, but does not re-render the HUD, and
• a function that adds the delta to the score and re-renders the HUD, but does not reset the delta.

And – you guessed it – I wouldn't have mentioned any of this if it didn't result in one bug and one quirk in TH02. The bug resulting from 1) is pretty minor: The function is called when losing a life, and simply stops any active score-counting animation at the value rendered on the frame where the player got hit. This one is only a rendering issue – no points are lost, and you just need to gain 10 more for the rendered value to jump back up to its actual value. You'll probably never notice this one because you're likely busy collecting the single spawned around Reimu when losing a life, which always awards at least 10 points.

The quirk resulting from 2) is more intriguing though. Without a separate reset of the score delta, the function effectively awards the current delta value as a one-time point bonus, since the same delta will still be regularly transferred to the score on further game frames.
This function is called at the start of every dialog sequence. However, TH02 stops running the regular game loop between the post-boss dialog and the next stage where the delta is reset, so we can only observe this quirk for the pre-boss sequences and the dialog before Mima's form change. Unfortunately, it's not all too exploitable in either case: Each of the pre-boss dialog sequences is preceded by an ungrazeable pellet pattern and followed by multiple seconds of flying over an empty playfield with zero scoring opportunities. By the time the sequence starts, the game will have long transferred any big score delta from max-valued point items. It's slightly better with Mima since you can at least shoot her and use a bomb to keep the delta at a nonzero value, but without a health bar, there is little indication of when the dialog starts, and it'd be long after Mima gave out her last bonus items in any case.
But two of the bosses – that is, Rika, and the Five Magic Stones – are scrolled onto the playfield as part of the stage script, and can also be hit with player shots and bombs for a few seconds before their dialog starts. While I'll only get to cover shot types and bomb damage within the next few TH02 pushes, there is an obvious initial strategy for maximizing the effect of this quirk: Spreading out the A-Type / Wide / High Mobility shot to land as many hits as possible on all Five Magic Stones, while firing off a bomb.

Wow, a grand total of 1,750 extra points! Totally worth wasting a bomb for… yeah, probably not. But at the very least, it's something that a TAS score run would want to keep in mind. And all that just because ZUN "forgot" a single score_delta = 0; assignment at the end of one function…

And that brings TH02 over the 30% RE mark! Next up: 100% position independence for TH04. If anyone wants to grab the that have now been freed up in the cap: Any small Touhou-related task would be perfect to round out that upcoming TH04 PI delivery.