iiinova — where your digital self keeps evolving

ReC98 @rec98.nmlgc.net · 06/10/2026

On October 5, 2019, I launched the ReC98 crowdfunding website. Today, 7 years later, there really is no more incredible journey to be had. So here's is my final feature and retirement announcement. No matter how this is received, I have already won. 😮‍💨 rec98.nmlgc.net/blog/2026-10...

Screenshot of the output of the new Shuusou Gyoku command-line replay simulation tool, showing the end result of an full Extra Stage 4M10B Homing Shot replay, together with the surprisingly short amount of 179.3 ms it took to run through all 26212 frames of this replay. This translates to a validation frame rate of 179.3 ms. The caption reads: "As usual, the performance corresponds to the 32-bit Windows build running on my aging Intel Core i5-8400T. No one else gave me performance numbers."

Screenshot of a table that visualizes the growth in complexity of the ReC98 blog posts from 2020 to 2026, comparing total and average text bytes and asset count. Taken from the ReC98 2026-10-05 blog post. The caption reads: "Excluding the three policy-bugfix posts and the order advice post. Complexity is calculated as the geometric mean of the average text bytes increase and the average asset count increase since 2020, i.e., √((Average text bytes / 4,234) × (Average asset count / 0.9))."

261

ReC98 @rec98.nmlgc.net · 05/10/2026

You could use this code to procedurally generate optimal Shuusou Gyoku runs from your favorite programming language via old-school machine learning or something. In reality, nobody cares, and you'll all just be here for one thing. >18,700 words coming to you in a few hours.

1. Point items with negative values?
2. Defining the scope of "game logic"
• The unexpectedly big scope of RNG
3. Researching locale bloat in MSVC's sprintf()
4. Safely bypassing MSVC's C++ exception handling
5. Completing the separation of game logic
• Implementation details
• Changing debug invincibility
6. The birth of a shared ReC98 source port engine
7. A replay validation CLI
• Validation performance
8. Future work
9. Retirement announcement
• Epilogue

030

ReC98 @rec98.nmlgc.net · 30/06/2026

Many thanks to this month's subscribers! RL consumed lots of time this month. Regaining focus has been tough with the final steps being as difficult as ever. Wondering how ReC98 can possibly survive after all the forks (many of them vibe-coded) I've seen in this month alone.

Active ReC98 subscriptions for June 2026:

• €125 from [Anonymous] towards anything (including tooling)
• €50 from Ember2528 towards better replays for Shuusou Gyoku, followed by a long-term plan to first decompile TH03, adding replays, porting it to modern systems, and then implementing netplay (although we're also going for a more short-term option of having netplay on PC-98)
• €35 from [Anonymous] towards TH03 RE
• €10 from Root towards porting SDL to Windows 98 to get Shuusou Gyoku running there again

030

ReC98 @rec98.nmlgc.net · 16/06/2026

Of course, this also means instant detection of desyncs. (Though only via a Game Over occurring before the game processed all inputs, since that's all data we have in the old format. The new one will record more events that could pinpoint the cause of a desync more closely.)

Output of the upcoming Shuusou Gyoku command-line replay simulation tool, showing a desyncing replay that ends 77.1% into the recorded replay data with a Game Over, after just 24.6 ms of simulation time.

000

ReC98 @rec98.nmlgc.net · 16/06/2026

140-175 ms for simulating the full 7 minutes of Shuusou Gyoku's Extra Stage on the command line. On an 8-year-old Core i5. Single-threaded. With MSVC's horrid codegen and several untapped optimization opportunities. And that's the heaviest case. Regular stages are much faster.

Output of the upcoming Shuusou Gyoku command-line replay simulation tool, showing the end result of two Extra Stage and one Lunatic Stage 4 replay, together with the surprisingly short amount of time it took to gather these results – 141.3 ms for a Wide Shot Extra Stage run, 173.3 ms for a Homing Missile Extra Stage run, and 44.8 ms for a Laser run of Stage 4 on Lunatic difficulty, translating to validation frame rates of 191894, 151244 and 242082 FPS, respectively.

230

ReC98 @rec98.nmlgc.net · 14/06/2026

Finally, Shuusou Gyoku's game logic, isolated in a reusable, freestanding DLL. No global state. No Win32 API dependencies besides GetProcessHeap(), HeapAlloc(), and HeapFree(). No instructions newer than i586. Still simulates blazingly fast. (Have fun guessing how fast exactly!)

Screenshot of the Windows 11 Properties dialog displaying the new Shuusou Gyoku game logic DLL, with a size of 73,216 bytes.

Screenshot of Dependency Walker running on Windows 98 displaying the new Shuusou Gyoku game logic DLL and showing off its minimal imports of GetProcessHeap(), HeapAlloc(), and HeapFree().

120

ReC98 @rec98.nmlgc.net · 31/05/2026

Many thanks to this month's subscribers! The splitting process has escalated to not only cover Shuusou Gyoku's logic, but also my SDL-based engine, laying the groundwork for future modern-system builds. Only missing the CLI now, and of course the blog post. Mid-June, maybe?

Active ReC98 subscriptions for May 2026:

• €125 from [Anonymous] towards anything (including tooling)
• €50 from Ember2528 towards better replays for Shuusou Gyoku, followed by a long-term plan to first decompile TH03, adding replays, porting it to modern systems, and then implementing netplay (although we're also going for a more short-term option of having netplay on PC-98)
• €35 from [Anonymous] towards TH03 RE
• €10 from Root towards porting SDL to Windows 98 to get Shuusou Gyoku running there again

010

ReC98 @rec98.nmlgc.net · 30/05/2026

• …fake script code) • The text popups shown for boss defeat and Evade bonuses or when collecting a bomb or extra life, where each letter flies off at a different angle • The sprintf() implementation that decides the number of letters (and thus, RNG steps) in these popups (!)

First Shuusou Gyoku comparison screenshot of the randomness in Stage 6's fake script code, shown all throughout VIVIT-captured-'s third phase. Taken during that phase's entrance animation.

Second Shuusou Gyoku comparison screenshot of the randomness in Stage 6's fake script code, shown all throughout VIVIT-captured-'s third phase. Taken during that phase's entrance animation.

020

ReC98 @rec98.nmlgc.net · 30/05/2026

• The falling stars in the last phase of the Gates fight, and in Stage 6 • Boss explosions • The background animations in Stage 6 (wavy clock, wireframe cubes, and …

First Shuusou Gyoku comparison screenshot of the randomness in Stage 6's wavy clock background and falling stars. Taken at the start of VIVIT-captured-'s first phase, on the specific frame before her first pattern.

Second Shuusou Gyoku comparison screenshot of the randomness in Stage 6's wavy clock background and falling stars. Taken at the start of VIVIT-captured-'s first phase, on the specific frame before her first pattern.

First Shuusou Gyoku comparison screenshot of the randomness in boss explosions and Stage 6's wireframe cubes. Taken during the entrance animation of VIVIT-captured-'s second phase.

Second Shuusou Gyoku comparison screenshot of the randomness in boss explosions and Stage 6's wireframe cubes. Taken during the entrance animation of VIVIT-captured-'s second phase.

120

ReC98 @rec98.nmlgc.net · 30/05/2026

• The falling rocks in Stage 4 • The stars shown when collecting point items during an Evade combo, or when using the Wide Shot bomb

First Shuusou Gyoku comparison screenshot of the randomness in 1) the falling rocks in Stage 4, and 2) the stars shown when collecting point items during an Evade combo. Taken, obviously, at the start of Stage 4's second wave of enemies, and also demonstrating the random spawn position of some of the enemies in this wave.

Second Shuusou Gyoku comparison screenshot of the randomness in 1) the falling rocks in Stage 4, and 2) the stars shown when collecting point items during an Evade combo. Taken, obviously, at the start of Stage 4's second wave of enemies, and also demonstrating the random spawn position of some of the enemies in this wave.

First Shuusou Gyoku comparison screenshot of the randomness in the stars shown when using the Wide Shot bomb. Taken near the start of Stage 3.

Second Shuusou Gyoku comparison screenshot of the randomness in the stars shown when using the Wide Shot bomb. Taken near the start of Stage 3.

100

ReC98 @rec98.nmlgc.net · 30/05/2026

Full list of seemingly decorative aspects in Shuusou Gyoku that are actually game logic and must always be simulated because they draw from and advance the single global RNG: • The hearts shown when losing a life • The sparks shown when grazing bullets or hitting an enemy

First Shuusou Gyoku comparison screenshot of the randomness in 1) the hearts shown when losing a life, and 2) the sparks shown when grazing bullets. Taken at the start of Stage 5.

Second Shuusou Gyoku comparison screenshot of the randomness in 1) the hearts shown when losing a life, and 2) the sparks shown when grazing bullets. Taken at the start of Stage 5.

1113

ReC98 @rec98.nmlgc.net · 11/05/2026

Thus, negative item values will continue to just "absorb" points from subsequently collected positive-value items like they did in the original game, and not immediately decrease the score. Some zoomed-in images variants for comparison: (fixed → original → ≥P0295 && ≤P0326)

000

ReC98 @rec98.nmlgc.net · 11/05/2026

Fortunately, the system sprite sheet does contain a 5×1-pixel line in #DCDCFE that I can repurpose as a - sign to fix the popups from the next build onwards. The total score, on the other hand… I *could* make it display like this, with negative deltas always added on top, but…

100

ReC98 @rec98.nmlgc.net · 11/05/2026

Even I only noticed because pbg's code formatted the nominally unsigned item point value as signed, which raised a compiler warning. So I changed it to unsigned… which caused an obvious 32-bit integer overflow in any build since P0295. Whoops. Just a rendering issue, though.

100

ReC98 @rec98.nmlgc.net · 11/05/2026

Point items in Shuusou Gyoku will award negative points if you collect them below the bottom edge of the playfield during the respawn animation. And nobody noticed because 1) the game's 5×7-digit font doesn't have a - sign, and 2) the total score can't decrease, only increase.

182

ReC98 @rec98.nmlgc.net · 30/04/2026

Many thanks to this month's subscribers! Very slow month, but I still managed to move enough code to push the headless Shuusou Gyoku subproject to over 100 commits. Very close to solving the hardest issues while juggling Windows 9x and FFI use cases. 4 pushes for sure, though.

Active ReC98 subscriptions for April 2026:

• €125 from [Anonymous] towards anything (including tooling)
• €50 from Ember2528 towards better replays for Shuusou Gyoku, followed by a long-term plan to first decompile TH03, adding replays, porting it to modern systems, and then implementing netplay (although we're also going for a more short-term option of having netplay on PC-98)
• €35 from [Anonymous] towards TH03 RE
• €10 from Root towards porting SDL2 to Windows 98 to get Shuusou Gyoku running there again

000

ReC98 @rec98.nmlgc.net · 22/04/2026

Debug builds of Shuusou Gyoku had a menu option that turns off collision detection. Past tense because this forks gameplay, desyncs replays recorded with the opposite value, and is therefore very bad. I'll replace it with the alternative approach of just setting lives to 255.

Screenshot of Shuusou Gyoku's Config → Difficulty menu in a build compiled with the PBG_DEBUG macro, showing pbg's four debug options, with the collision-detection-deactivating `Hit [O F F]` option highlighted. The help window describes it as 「[DebugMode] 当たり判定」.

162

ReC98 @rec98.nmlgc.net · 31/03/2026

Many thanks to this month's subscribers! Untangling Shuusou Gyoku's game logic into a library isn't the worst thing in the world, but still nontrivial. Will definitely end up closer to 2 pushes than to 1. Probably doing a bit of TH02 RE after that, given its recent funding.

Active ReC98 subscriptions for March 2026:

• €125 from [Anonymous] towards anything (including tooling)
• €50 from Ember2528 towards better replays for Shuusou Gyoku, followed by a long-term plan to first decompile TH03, adding replays, porting it to modern systems, and then implementing netplay (although we're also going for a more short-term option of having netplay on PC-98)
• €35 from [Anonymous] towards TH03 RE
• €10 from Root towards porting SDL2 to Windows 98 to get Shuusou Gyoku running there again

031

ReC98 @rec98.nmlgc.net · 17/03/2026

Summary blog post: rec98.nmlgc.net/blog/2026-03... This time with: • All the formulas • All the hitboxes • Kotohime starring in two of the videos • The most complicated glitch explanation so far • Yet another Bluesky rant Funded by Ember2528, [Anonymous], and LeyDud.

Screenshot of the barrage of formulas involved in deriving values from TH03's round speed variable, taken from the ReC98 2026-03-16 blog post. It reads: "This variable is then used to derive a whole variety of speeds and limits:

• Speed of pellets and fireballs while they transfer to the other playfield: (4.375 + ⌊round_speed/3⌋)
• Speed of the single pellet fired when killing an enemy with an explosion whose chain has a hit count of ≥3 and ≤(14 - (⌊round_speed/2.0⌋ × 2)), after it transferred to the other player's field: (1.5 + (⌊3 × round_speed⌋/16))
• Additional fireball speed added on top of the randomized base speed between 1.25 and 3.25: ⌊round_speed/2⌋
• Required charge_exatt within a chain to fire an Extra Attack after destroying a fireball with an explosion: (7 - ⌊round_speed/2.0⌋)
• Required charge_exatt within a chain to fire an Extra Attack after destroying a fireball with a regular player shot or Charge Shot, or an enemy with an explosion: (6 - ⌊round_speed/2.0⌋)
• Required charge_fireball within a chain to fire a fireball after destroying an enemy, fireball, or pellet with an explosion (12 - ⌊round_speed/1.0⌋)
• Two other things in character-specific Extra Attack code I haven't RE'd so far

Yup – the difficulty setting in the Option menu merely controls where all of these values start out at. After 6,144 frames of gameplay, or 1:49 minutes, even an Easy round will have accelerated to Lunatic levels."

Visualization of TH03's data segment starting from the "Extra Attack charge per chain" arrays for the two players, showing how indexing these arrays out of bounds can access and manipulate score digits (causing the score reduction glitch) or the number of Story Mode extend gained (causing the extend glitch). The caption reads: "With ☯️ being the number of Story Mode extends gained. These score digits do not include the one's digit, which represents the number of continues used and is stored separately. The 16 bytes below hold more gameplay-relevant data relating to Yumemi's Charge Shot and Gauge Attack, but researching that was out of scope for this delivery." Taken from the ReC98 2026-03-16 blog post.

Screenshot of a table displaying the possible addresses of TH03's fourth code segment (which decides the specific variant of the score reduction and life extend glitches) in various PC-98 Touhou packages from out there in the wild, depending on the sound card model and resulting PMD driver.
The caption reads: "* The Touhou98 Experience v3.00 release is also built around this .HDI.
† Created by copying the TH03 files onto that one old widely circulating TH04 .HDI that needed a later DOS version due to 📝 the no-EMS crash bug. Representative of other 5-game .HDI setups that might be floating around the Internet or that people have built for themselves, or real-hardware setups.
†† The bold columns indicate the default setting the package came with."

Taken from the ReC98 2026-03-16 blog post.

ffprobe output of a TH03 formation video to Bluesky, demonstrating how the platform applies the two worst imaginable video processing steps for PC-98 footage (re-encoding as H.264 with YUV420P chroma subsampling, and enforcing 30 FPS by dropping or duplicating frames) to videos you upload there. Taken from the ReC98 2026-03-16 blog post.

181

ReC98 @rec98.nmlgc.net · 17/03/2026

🚚 TH03's enemy, fireball, explosion, chaining, and combo systems have been fully decompiled and researched! Hardest piece of game logic in all of PC-98 Touhou, by far. 1% of overall code, 6% of TH03 itself. 🐞 1 bug 💣 5 landmines 🎺 8 quirks 🪨 61 pieces of bloat

Screenshot of a video that visualizes TH03's frame data of a fireball-originating explosion against a pellet, demonstrating how these explosions are rendered 8 pixels lower than the position that collision detection uses for their hitbox. Taken from the ReC98 2026-03-16 blog post. The caption reads: "Thanks to the anonymous backer for providing the Anything budget for these multi-row tabs at the end of the 6th push!"

Screenshot of a video showcasing what happens when exceeding TH03's 40-enemy cap when constructing a formation sequence that starts with a 12-enemy formation followed by the 16-enemy "Four Lines of Four" formation. Demonstrates how closely timed bombs can reserve a majority of TH03's enemy slots for explosions, which prevents successive formations with high enemy counts from being spawned for one of the players, which in turn causes them to skip a lot of formations in its internal 256-formation cycle (29 in this example). Taken from the ReC98 2026-03-16 blog post.

Screenshot of a video showcasing how removing the enemy damage cap of TH03's explosions can change the timing and placement of explosions. Demonstrated by chaining formation #4 (Racetrack) and colorizing the resulting explosions based on the amount of damage they've dealt to enemies. The caption reads: "I chose black for explosions that currently can't deal damage to enemies. The other 6 colors (dark green, light green, dark red, light red, dark blue, and light blue to represent 0 to 5 dealt hits in this order) are TH03's regular in-game VRAM colors from #5 to #10." Taken from the ReC98 2026-03-16 blog post.

Screenshot of a video of a TH03 explosion destroying a fireball and spawning two red fireballs in response, recorded from 1:04 minutes into the Kotohime vs. Marisa demo on Kotohime's playfield. The caption reads: "Note how the "primary" new fireball described above is spawned from the center of its explosion, while the "additional" new fireball is spawned from the center of the explosion that caused the old fireball to explode." Taken from the ReC98 2026-03-16 blog post.

1105

ReC98 @rec98.nmlgc.net · 16/03/2026

TH03 is about to get thoroughly analyzed and documented down to its core. ≥13,100 words. Heaviest blog post by HTML size so far. 2.36× more PC-98 Touhou reverse-engineering than the previously biggest RE post. Out in a few hours.

The table of contents of the upcoming 2026-03-16 post on the ReC98 blog. It reads:

1. An important note about durations in TH03
2. TH03's chaining system
3. Difficulty-specific tuning
• round_speed
• enemy_speed
• Angle tuning
4. TH03's combo system
• Boss Attacks and Panics
5. TH03's enemy formation scripts
• Gameplay details
• Function reference
6. TH03's enemies themselves
7. TH03's explosions
8. TH03's fireballs
• Destroying fireballs with regular player shots or Charge Shots
9. TH03's score reduction and extend glitches
• The fix (← new builds here!)
10. Completing the Fediverse migration
• Polls
• Bluesky rant, part 2

0114

ReC98 @rec98.nmlgc.net · 08/03/2026

Almost done writing! Still need to spend some more coding time on the blog UX though, so that you can seamlessly switch between two layers of tabs and the 30 hitbox videos underneath. (Word count already above 10,000, by the way.)

Work-in-progress screenshot of the TH03 explosion hitbox figure from the upcoming ReC98 blog post, displaying the hitbox of an explosion that originated from a 48×48-pixel enemy against a 64×64-pixel enemy. With 5 different kinds of explosions (from 16×16/32×32/48×48/64×64 enemies or fireballs) that can hit 6 different types of gameplay entities (16×16/32×32/48×48/64×64 enemies, pellets, or fireballs), there are a total of 5 × 6 = 30 hitboxes that the blog post has to visualize, which necessitates two layers of tabs and some coding effort to make it work nicely.

010

ReC98 @rec98.nmlgc.net · 28/02/2026

Many thanks to this month's subscribers! Life priorities have shifted and I'll likely be even slower in the foreseeable future. Then again, what else is left in PC-98 Touhou that's as complex as TH03's enemies, fireballs, and explosions? Blog post should be out next week.

Active ReC98 subscriptions for February 2026:

• €125 from [Anonymous] towards anything (including tooling)
• €35 from [Anonymous] towards TH03 RE
• €10 from Root towards porting the SDL 3 build of Shuusou Gyoku back to Windows 98

010

ReC98 @rec98.nmlgc.net · 27/02/2026

Bluesky confirmed for having the worst video processing pipeline in the entire social media landscape. Reducing *frame rates* is disgusting at a level that even Twitter wouldn't step down to.