iiinova — where your digital self keeps evolving

So if you now spawn vibecoders across the entire community who encroach upon every facet of the project and even bring validation tests (which I always struggled to get funding for), what is there left for me to meaningfully do? Write blog posts? The one thing I always found to be the biggest pain?

130

Shifting life priorities, dwindling commissions, and excruciating delays with the current feature then pushed this resilience close to zero. bsky.app/profile/rec9... (Shoutout to @touhou-memories.com for being literally the only one to connect the dots and figure out a part of that on her own.)

140

The combination of my meticulous approach and ReC98's business model always left me with a low resilience to outside disruption in general. It only worked out amicably for years because things used to be hard, the barrier of entry was rather high, and good devs usually have better things to do.

130

Of course they don't say "look what I vibecoded today". They say "I'm tired of waiting for the old man, look at these screenshots of this long-awaited feature, has all quality markers you want, and you'll get it for free (also, together with 100% RE)". More context here: bsky.app/profile/rec9...

• Some of them might actually be genuine coding wizards, using AI smartly. In any case, these are fellow fans and friends, and they're not dumb. This is about outside disruption, the tools they use don't matter. And once they actually release their work, ReC98 will be the one to look like a grift.

111

• Support has been down all year. Nothing new in April and May despite the store being wide open. The young and energetic community gets increasingly annoyed that the old and tired man can't deliver anymore. Hence, vibecoders *will* set the standard because the community is hungry. I've seen enough.

110

• Lack of knowledge doesn't matter because AI can teach them. Wasn't there some retard who meticulously documented all edge cases in giant blog posts in a silly attempt to secure funding for a quality implementation later? That's all the context their agents need, handed to them on a silver platter.

110

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

So many wrong assumptions here. • Commissions, not donations. Of course I'm going to refund if I don't deliver what people ordered. This is a business, not a charity, but it apparently increasingly gets perceived as one. Bad global economics and more kids in the community certainly don't help.

110

Yup. Even if funding improved again, vibecoders *will* set the standard for QoL features. So this can only go two ways: • Ignore them → community splits along a silly pro- vs. anti-AI divide • Work with them → ReC98 degenerates into playing catch-up Both are undesirable. bsky.app/profile/gens...

ReC98 @rec98.nmlgc.net · 09/07/2026

Next release, then PC-98 text RAM JIS trail word rendering (it's been in my drafts for almost 5 years), and then it's over. All other pending contributions will be refunded.

082

ReC98 @rec98.nmlgc.net · 09/07/2026

ReC98 will end after the next delivery. I don't have it in me to compete with vibecoders, especially when y'all cheer them on for instantly delivering what you've wanted all along. And if you aren't cheering yet, you soon will; they're only getting better and more numerous.

51411

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 · 17/06/2026

That looks more like an old version of GCC though? This project needs at least GCC 15. Preferably 16 due to strange internal compiler errors in 15.2.0 from the next build on. Or, alternatively, Clang ≥18, which you can opt into by re-running Tup with `CC=clang`. Compiles much faster too.

210

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

Tup has two alternatives for systems where FUSE doesn't work: 1) The LD_PRELOAD server (which I also use to build the Flatpak): github.com/flathub/net.... 2) `tup generate`, which writes all build rules into a sequential shell script.

github.com

210

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().

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

Reposted by ReC98

(Yes, I've heard the news and will go right back to work! Just let me finish this really cool thing for Shuusou Gyoku I've been working on for the past few months, and then I'm going to spend an extended amount of time with the main business. OK?)

052

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

052

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

sizeof(C_SSG) is 403,280 bytes on 32-bit systems, and 405,664 bytes on 64-bit systems.

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

• …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

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

• 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

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

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

… that's *not* the score that the game would record in the High Score list. Shuusou Gyoku only ever adds potential negative deltas to the score on a Game Over – not when switching stages, and not when clearing the game. And we obviously don't want to change such scoring details.

100

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

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 · 10/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

Hilarious Shuusou Gyoku pbg quirk dropping later today

040

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

Although not entirely free, and it would come with a one-time setup cost and the drawbacks of abandoning the current strategy. So it's up to the backers to decide. More info: github.com/nmlgc/ssg/is...

github.com

Support compilation with MinGW · Issue #80 · nmlgc/ssg

Might give us a Windows 98 backport that is more stable in the long run than continuously chasing and polyfilling the current Windows SDK bundled with the current Visual Studio. Doesn't actually so...

000

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

What's this? A MinGW fork with GCC 15 that targets Windows 98? Small package, no bullshit? Tested and working fine for trivial programs? github.com/redpanda-cpp... Removing the KernelEx and SSE instruction requirements from Shuusou Gyoku's backport has just become a lot cheaper.

github.com

GitHub - redpanda-cpp/mingw-lite: MinGW-w64 GCC distribution. Fast and flexible build scripts; minimal dependencies; works on NT 4.0 and 98. Inspired by w64devkit.

MinGW-w64 GCC distribution. Fast and flexible build scripts; minimal dependencies; works on NT 4.0 and 98. Inspired by w64devkit. - redpanda-cpp/mingw-lite

131

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

Which is better in almost every way. Such a setting would propagate into the replay header of even pbg's original format, and replays recorded with it would play back fine on release builds too. (Thus, replay sites would have to check for / recategorize this case anyway.)

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 · 21/03/2026

github.com/nmlgc/rec98.... [💰] Confirm T0425 Ember2528 is also back with a smaller €50 subscription towards the better replay format for Shuusou Gyoku, followed by the previous long-term TH03 decompilation and porting roadmap! Thank you very much.

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

github.com/nmlgc/rec98.... [💰] Confirm T0424 Another €25 from iruleatgames towards reverse-engineering TH02 or getting it more position-independent, rounding up Yanga's earlier TH02 contributions to a full push. Thank you!

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

github.com/nmlgc/rec98.... [💰] Confirm T0423 €200 from iruleatgames towards reverse-engineering TH02, or getting it more position-independent! Thank you so much.

000

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

github.com/nmlgc/rec98.... [💰] Confirm T0422 €43.75 from Arandui towards Shuusou Gyoku's long overdue better replay feature, rounding us up to a full 3 pushes. Thank you very much!

000

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.

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