About Raccu

A human workshop, not a download service

Raccu is currently carried mostly by one person over many unpaid hours, alongside private life, family, and regular work. That reality shapes the project. Releases, documentation, support, testing, and research can only move as far as time and focus allow.

This is why Raccu values prepared support requests, reproducible reports, clean logs, careful reading, and respectful communication. Every clear report saves time that can go back into restoration work instead of repeating avoidable troubleshooting.

Why Raccu exists

Too much knowledge around legacy games disappears into old forum posts, broken links, private notes, abandoned tools, closed chats, and undocumented release packages. Raccu is meant to preserve more than final downloads. It is meant to keep restoration methods, technical decisions, project context, credits, and research trails readable over time.

Raccu should maintain the pieces that make a release understandable: the current files, documentation, validation notes, tool context, credits, support context, and the reasoning behind restoration decisions. A release without context becomes hard to trust, hard to support, and easy to misattribute.

That includes attribution. Raccu should credit original works clearly, but also researchers, tool authors, testers, contributors, and earlier technical work where it shaped the path forward. Preservation without attribution eventually turns into another kind of loss.

Restoration, not replacement

The Next-Gen Restoration Project (NGRP) by Raccu is built around restoration rather than reinvention. A good restoration should not feel like a different game with a louder art direction. It should feel natural, familiar, and faithful to the original visual identity under modern display conditions.

That is why the result may look normal during play. The work often becomes obvious only when the restored runtime presentation is compared in practice with the unmodified state. That natural feeling is not a weakness of the work; it is the point of restoration.

Beyond one-click upscaling

Raccu does not treat restoration as a single upscale pass. The work involves decisions about texture reconstruction, font and UI readability, material behavior, generated normal maps, mask handling, emulator behavior, patch order, runtime testing, and whether a change still respects the original direction.

Some of the most important work is quiet: stable glyph assets, readable UI, material-aware texture treatment, normals that add believable structure without changing the character of the monsters, and validation passes that catch problems only visible in runtime.

Clean source principle

Raccu’s clean-source principle is simple: releases must not become a shortcut around the original games. Raccu does not provide ROMs, game dumps, firmware, keys, BIOS files, extracted original archives, or unmodified original game assets.

The work is designed for legally owned, self-dumped sources because restoration should preserve and document, not replace or redistribute. This keeps Raccu focused on its own tools, restoration decisions, validation work, and maintained release context.

Raccu-created work

Raccu also creates its own work. Tools, source code, documentation, manifests, compatibility data, generated normal maps, generated font and glyph assets, reconstructed UI assets, restoration-derived replacement assets, validation records, packaging structures, and Raccu/NGRP branding are part of the project’s own technical and creative output.

This matters because Raccu is not only assembling files. It is building methods, tools, records, and restoration components that take time, judgement, testing, and authorship. Font-asset reconstruction and normal-map generation are examples of that work: analysis, generation, correction, runtime review, and many small decisions that shape the final result.

Original games, trademarks, characters, worlds, music, logos, and original game assets remain the property of their respective owners. Raccu does not claim ownership of them and is not affiliated with, endorsed by, or sponsored by those owners.

Restoration Gallery and runtime validation

Raccu documents restoration results with its own runtime validation captures. The gallery is part of the project record: releases, documentation, validation notes, and visual results should stay together at the official Raccu source.

These captures show how Raccu-created restoration components behave in real runtime conditions. They help document the project’s visual standard: faithful to the original direction, readable on modern displays, and natural in motion rather than redesigned for a different style.

A good restoration should often feel familiar first and reveal its work through comparison, detail, stability, and clarity. That is why visual documentation belongs to Raccu’s restoration process, not only to external showcases or community posts.

One maintained source

Raccu is meant to be the maintained source for its own releases, documentation, credits, validation notes, and project context. That keeps versions understandable, prevents outdated packages from becoming the visible baseline, and makes it possible to correct or remove material responsibly when a concrete issue is raised.

This also protects the community. Users should not have to guess which mirror, repost, repack, or old upload is current. The official Raccu source is where releases, documentation, credits, and support context belong together.