Cracking the 30-Year-Old Super Mario 64 Courtyard Plaque Mystery with Claude

The plaque in the courtyard of Super Mario 64 is one of the most famous unsolved mysteries in video game archaeology. A 32×32 pixel low-resolution texture that players have argued about for thirty years, from "L is real 2401" to all sorts of conspiracy theories. Now someone has used Claude Opus 5.5 to read it.

Why Traditional Methods Can't Read It

The core of the problem is this: the pixels simply don't exist. No super-resolution tool can help, because the plaque texture is only 32×32, and the text detail was already compressed away in the 1996 production pipeline.

It's like trying to recover text from an extremely blurry photo — from an information theory standpoint, if the information isn't in the pixels, no amount of upscaling can conjure it back. The player community tried all kinds of image enhancement algorithms, but the results were guesses, not restorations.

The Reddit author took a different approach: instead of "enhancing" the image, they set out to "reverse-engineer" the production process.

Rebuilding the 1996 Production Pipeline with a Forward Model

The author had Claude write a forward model that simulates the complete workflow a Nintendo artist would have followed back then to create this texture: font → canvas → scaling → blur → stone material.

Once this pipeline is modeled, the problem flips — it's no longer "guess the text from a blurry image," but "generate blurry images from text and see which one comes closest to the original."

Specifically: they searched over fonts, font sizes, letter spacing, and candidate words on a GPU, exhaustively enumerating all possible combinations to find the parameters that reproduce the original texture.

This is essentially an inverse rendering problem, turning image recognition into an exhaustively searchable problem.

Inverse Rendering is a classic problem in computer graphics: given a 2D image, infer the scene parameters that produced it — including geometry, materials, lighting, and camera. It runs in the opposite direction from conventional "rendering": rendering generates an image from known parameters, while inverse rendering infers parameters from an image. This problem is typically ill-posed, because many different parameter combinations can produce visually nearly identical images. What the author did in this project is a simplified version of inverse rendering: the scene is restricted to "text textures," the parameter space is limited to fonts, font sizes, letter spacing, and candidate words, and the forward process (rendering pipeline) is fixed as a deterministic flow from font to blurry texture. Because the parameter space is drastically narrowed, the original problem shifts from "unsolvable" to "exhaustively searchable" — and this is precisely the key precondition that made the method succeed.

Dictionary Search and Simulation Validation

The second line of text was identified using a more clever method: K-best dynamic programming (DP), searching a dictionary of 17,700 words for the most likely combination.

But searching alone isn't enough — the key is knowing whether the result is reliable. The author built a simulation testing framework: plant known text on fake plaques, then use the same method to crack them and measure how often the method gets "fooled."

This held-out test approach is the most valuable part of the whole endeavor. The author states explicitly in the original post: "Being strict about held-out tests matters more than anything."

Pitfalls Along the Way

The author also candidly documented two mistakes: one was a word-spacing bug that caused overlapping words to double-count ink; the other was an early over-assertion about the capital letter S, which the joint tests actually didn't support.

These details show that even in AI-assisted research, rigorous human review of methods and conclusions remains irreplaceable.

K-best Dynamic Programming (K-best DP) is a variant of dynamic programming. Standard dynamic programming keeps only the optimal solution, while K-best DP retains the top K optimal candidate paths at each step, ultimately outputting K globally optimal solutions. In this project, the author needed to find the most likely word sequence forming the second line of the original plaque from a dictionary of 17,700 words. Since each word's position, size, and overlap pattern on the plaque has multiple possibilities, the search space is enormous. K-best DP allows the author to output not just one "best guess" but multiple candidate solutions, which can then be manually reviewed or further filtered using simulation tests. This method is widely used in speech recognition and machine translation (such as beam search in CTC decoding); it essentially finds the several highest-probability paths in the decoding space, balancing computational efficiency with solution diversity.

Held-out Test is a core technique in machine learning and statistics for evaluating method reliability. The basic idea is: set aside a portion of data, exclude it from model training or parameter search, and use it solely for final validation. In this project, the author couldn't directly verify "whether the cracked result is correct" — because nobody knows the true answer. So instead, they used simulation validation: artificially generating fake plaques with known content, running the same cracking process to identify them, then measuring the accuracy rate. If the method frequently fails on fake plaques with known answers, then its conclusions about the real plaque are also suspect. The key to this approach is that the test data must be completely isolated from the search process; otherwise information leakage occurs, leading to overestimation of the method's capability. The author's emphasis on "being strict about held-out tests" is precisely because this is the only way to objectively measure the method's credibility.

The Final Answer: Eternal Star / We hope so

The cracked result is: "Eternal Star / We hope so," using Adobe's 1990 Palatino Bold Italic font.

This result is quite intriguing — it echoes the game's "Eternal Star" theme while carrying a certain gentle tone of well-wishing, very much in keeping with Nintendo's design style of that era.

The author also produced a complete 40-page LaTeX report and an open-source package; both the code and report are at github.com/supermochi64/sm64-plaque-decode.

The Significance Goes Beyond a Single Plaque

The value of this entire project lies in demonstrating a new paradigm for AI-assisted research: using large models to write forward models, search engines, simulation validation frameworks, and academic reports, while humans focus on methodology and the rigor of supervised testing.

For game archaeology, reverse engineering, or indeed any problem where "information is missing but the process is knowable," this approach of "rebuilding the pipeline rather than enhancing the output" is worth learning from.

Of course, the limitations should also be acknowledged: the conclusions still rest on assumptions about the 1996 production pipeline, and if Nintendo used a completely different workflow back then, the results could be off. The author partially addressed this concern with simulation tests, but this is ultimately not a historical archive.

Regardless, a thirty-year mystery finally has an answer that can withstand scrutiny.

One-line Summary

Using Claude to build a forward model that reverse-engineers the 1996 texture pipeline, cracking the 30-year Super Mario 64 plaque mystery.

Paragraph Summary

A 32×32 pixel plaque texture in the Super Mario 64 courtyard became a famous unsolved mystery in game archaeology, because the text information was compressed away during production, making it unreadable by traditional super-resolution methods. The author used Claude Opus 5.5 to build a forward model simulating Nintendo's complete production workflow from font to blurry texture, flipping "guess text from image" into "generate images from text and match," exhaustively searching over fonts, sizes, spacing, and candidate words on a GPU. The second line was searched using K-best dynamic programming over a 17,700-word dictionary, with method reliability validated through a simulation testing framework. The final cracked result is "Eternal Star / We hope so," in Adobe's 1990 Palatino Bold Italic, with code and a 40-page report open-sourced.