ReC98
LightNews LightNews
rec98project.bsky.social
ReC98
@rec98project.bsky.social
110 followers 7 following 170 posts
https://rec98.nmlgc.net

The Touhou PC-98 Restoration Project. Decompiled 100% of TH01 to provably legit C++ code, remaining games in progress. Which mods or ports do *you* want to see?
Posts Replies Media Videos
rec98project.bsky.social
You know, the one in the first image. From ver0.86 rev96β5 on, you'll get the way more accurate glyphs in the second image instead.

(The third image shows an authentic font ROM by NEC for comparison.)
Screenshot of TH05's Music Room, with its text rendered using the infamous horrible abomination that is the secondary set of ASCII glyphs in Neko Project's old auto-generated replacement for the PC-98 ROM font. Screenshot of TH05's Music Room, with its text rendered using new auto-generated replacement for the PC-98 ROM font created by Neko Project 21/W ver0.86 rev96β5 on. Screenshot of TH05's Music Room, with its text rendered using an authentic font ROM by NEC.
October 20, 2025 at 6:51 PM
rec98project.bsky.social
Summary blog post (>2,300 words): rec98.nmlgc.net/blog/2025-10...

Featuring:
• The most wholesome warning I've ever seen in a C compiler, courtesy of GCC
• Unexpectedly slow SDL code on Windows

Funded by Ember2528 and Root.
An exemplary code snippet that demonstrates a case where GCC's `-Wformat-overflow` warning precisely warns about a sprintf() buffer that's too short to contain a format string with certain statically known properties, together with two other cases where GCC can prove that the buffer is sufficiently large and thus doesn't warn. Taken from the ReC98 2025-10-19 blog post. Durations of saving an already retrieved 640×480-pixel buffer using the fast .BMP writer implemented in the P0256 build of Shuusou Gyoku, as opposed to SDL's much slower .BMP writer. The fast writer comes in at way below 0.2 ms, while SDL's writer takes multiple *milliseconds* and even gets slower as the bit depth *decreases*. Taken from the ReC98 2025-10-19 blog post.
October 19, 2025 at 9:55 PM
rec98project.bsky.social
Summary blog post: rec98.nmlgc.net/blog/2025-09-29

Ending this overly indulgent subproject with, among other things:
• Heap fragmentation everywhere
• An asynchronous fade effect
• Silly binary size micro-optimizations

Funded by [Anonymous] and Ember2528.
Table inspecting the different states of the master.lib heap when entering and leaving TH05's Music Room in an early version of the debloated P0323 build, showcasing how heap fragmentation prevents the main menu's background image from being loaded a second time, which caused the game to crash prior to finding a workaround. Taken from the ReC98 2025-09-29 blog post. Not-quite-pseudocode snippet showcasing an easy solution for a screen tearing landmine using the new `vblank_run()` mechanism that will deterministically run its task either now (if currently in VBLANK) or after the next VSync interrupt. Taken from the ReC98 2025-09-29 blog post. Visualization of the DOS heap when trying to launch TH02-TH05's INTvector set program using the spawn-at-top technique I developed in 2023 for the TH01 Anniversary Edition. Thanks to ZUN's fantastic idea of bundling these small utility tools and TSRs into a single binary that's larger than each individual TSR, DOS fails to load ZUN.COM, as the total binary is much larger than the resident size of the interrupt vectors. Taken from the ReC98 2025-09-29 blog post. Table of the various PMD versions bundled with TH02-TH05, listing their release date and resident sizes in conventional DOS RAM. The caption reads: "The PMD versions that ZUN shipped with each game. The byte size refers to the in-memory TSR size without any music, voice, or effect data added on top." Taken from the ReC98 2025-09-29 blog post.
September 30, 2025 at 6:43 PM
rec98project.bsky.social
Summary blog post: rec98.nmlgc.net/blog/2025-09...

This time with:
• More research into earlier Bluesky posts
• Special content for Peaceful Romancer enjoyers
• The 4th bug caused by C's integer promotion rules within 11 months

Funded by [Anonymous], Ember2528, Yanga, and Blue Bolt.
Screenshot of a video of the first 8 beats of TH05's All Cast sequence as shown in the original game, showcasing how the first picture crossfades onto the screen way behind the second beat of Peaceful Romancer indicated in the code. Taken from the ReC98 2025-09-16 blog post. Screenshot of a video of the transition from the second to the third screen of Yuuka's TH05 All Cast sequence, demonstrating how the picture and text cues have to catch up with the BGM beat targets during such a transition. The caption reads: "As pointed out by the uneven placement of the Reimu and Rika cues. These are Yuuka's second and third screens; the fact that each character gets its own sequence of pictures is common knowledge by now, right?" Taken from the ReC98 2025-09-16 blog post. The scorefile deobfuscation algorithm used in TH03, TH04, and TH05, compressed to a single line of C++20: // [key1] and [key2] are `uint8_t` as well. decoded_byte[i] = (key1 + (std::rotr<uint8_t>(encoded_byte[i + 1], 3) ^ key2) + encoded_byte[i]); Look at that nice `std::rotr()`! Have fun expressing the same in C while remaining as succinct. Taken from the ReC98 2025-09-16 blog post. Screenshot of TH03's High Score viewer, rendering a `YUME.NEM` file that consists entirely of 00 bytes. The caption reads: "Since `YUME.NEM` stores names, scores, and stage numbers as raw sprite IDs, we get sprite #0 from `REGI2.BFT` for all of them. AAAAAAAA AAAAAAAAAA A". Taken from the ReC98 2025-09-16 blog post.
September 17, 2025 at 12:07 AM
rec98project.bsky.social
Link: rec98.nmlgc.net/blog/2025-09...

… OK, it does have two bits of very silly Touhou content in the end. That'll have to do until the next one.

Funded by [Anonymous], Ember2528, and Congrio.
TH03's `ENEMY01.PI`, showing off the unnecessary line doubling of TH03's in-game sprites loaded from .PI files. The caption reads: "Since PI's location codes are designed around vertical repetition, line doubling has a negligible impact on compressed file sizes. Such an image still decodes into twice as many bytes as needed, though…" Taken from the ReC98 2025-09-10 blog post. Screenshot of TH05's title screen crossfading effect, as rendered by the original game on Neko Project 21/W with a clock speed of 2.4576 × 27 = 66.3552 MHz. Showcases an unusual landmine where an incomplete VRAM-page-to-VRAM-page copy results in partially masked and partially unmasked colors, in addition to a screen tearing line. Taken from the ReC98 2025-09-10 blog post.
September 11, 2025 at 2:51 AM
rec98project.bsky.social
By the way, your TH06 review contains what's still the best piece of journalism I've read about ReC98 so far. Thank you so much for that.
August 27, 2025 at 11:35 AM
rec98project.bsky.social
This one was fixed in the 2014 English patch.
August 21, 2025 at 12:07 AM
rec98project.bsky.social
The same screen appears correctly in Reimu B's Good Ending, which reveals this as a typo in a picture crossfading command.

The ",4" is supposed to be the second parameter, specifying how many frames to wait between each crossfading step.
August 21, 2025 at 12:07 AM