Overview

This page contains the policies and standards passed down from various scribes throughout the history of ROMhacking.net in one place for the modern age. ROMhacking.net may be abbreviated as 'RHDN' throughout this document.

Index

• Abandoned
• Community
• Copyright Claims, Licensing, and Noncompliant Items
  • Copyright Claims and Licensing
  • Noncompliant Items
  • Special Notes
• Credits
  • Special Notes
• Documents
• File Submissions
  • File Types
  • Image Resolutions
• Fonts
• Games
  • Primary Title
  • Alternate Titles
  • Release Date
  • Title Screen
  • Publisher
  • Genre
  • Game Description
• General Submission Form Rules
  • Overview
  • General Guidelines
• Hacks
  • Categories
  • Non-Permitted Items
• Homebrew
  • Categories
  • Non-Permitted Items
• Links
• News
• ROM/ISO Information
  • How to use
  • Checksums
  • Identifying names
• Restricted Consoles, Platforms, and Games
• Reviews
  • Non-Permitted Items
• Screenshot Resolutions
  • Atari 2600
  • Dreamcast
  • Famicom Disk System
  • Game Boy/Game Boy Color
  • Game Boy Advance
  • GameCube
  • Game Gear
  • Megadrive/Genesis/SegaCD
  • Jaguar
  • Master System
  • MSX
  • MSX2, MSX2+, MSX TurboR
  • NeoGeo CD
  • NeoGeo Pocket
  • Nintendo 64
  • Nintendo DS
  • Nintendo Entertainment System / Famicom
  • Nintendo Wii
  • PC
  • Playstation
  • Playstation 2
  • Playstation Portable
  • Sega Saturn
  • Sega 32x
  • Sega CD
  • Sega SG-1000
  • Super Nintendo
  • Turbografix-16
  • Virtual Boy
  • Wii
  • Wonderswan
  • x68000
  • XBox
• Screenshots
  • Nintendo Entertainment System
  • Nintendo Game Boy
  • Super Nintendo Entertainment System
  • Sega Genesis/Mega Drive, Sega CD, 32X
  • Sony Playstation
  • Nintendo 64
  • Nintendo Game Boy Advance
• Translations
  • Categories
  • Non-Permitted Items
• Utilities
  • Non-Permitted Items

The Abandoned section is intended for unfinished ROM hacking related projects (ROM Hacks, Translations, Utilities, Documents .etc) that were publicly abandoned by the author. The unfinished work is then subsequently released with the hope that someone else will pick up and continue the project.

• Please ensure there are no ROMs in your archive file. We cannot host ROMs. Submissions containing ROMs or other copyrighted material will be rejected.
• You are strongly encouraged to include notes on your organizational structure, files, and tools.

Community Database profiles are created upon submission of new items which they are the author of, or from reference in a credit list for an item they are not the author of.

• Profiles may be for a release entity/group, or an individual. Typically entity/group profiles are used for Author/Publisher/Released By fields, while individual profiles are used for credits.
• Only profiles for individuals may be referenced in Credit Lists.

Copyright Claims and Licensing

RHDN files are believed to be public domain, freeware, or contain license for distribution. If you have found, or are the owner of, a file that you believe RHDN does not have right or license to distribute, you may use the [ EDIT ] link to edit the entry. You may remove the file using the ‘No File’ checkbox within the form. Notation should be added in the entry’s description field notifying the public of the removal, and detailed reason for removal or dispute. RHDN is a publicly maintained site and this will ensure the file in question is not added back at a later date by someone else. Additionally, removal submissions with inadequate information cannot be processed by submission reviewers. All other entry related material is RHDN public content and not subject to removal.

Noncompliant Items

RHDN is publicly maintained and you should be able to correct most issues or errors yourself. However, there may be items found on RHDN that do meet the guidelines and should be flagged as non-compliant for potential removal. Note that this does not include file removals due to distribution license disputes. Such cases should be-handled via the Removal Request policy above. You should only flag items as noncompliant when the correction involves removing the item from the site for one of the maintenance reasons presented in the guidelines below. When an item is flagged as noncompliant, it will be subject to removal upon staff approval.

• Entries that do not meet applicable section submission guidelines should be flagged as noncompliant to be removed. Specific guidelines violated should be cited.
• Duplicate Game or Community items should be flagged as noncompliant only after correcting and assuring any associated material (Documents, Utilities, Hacks, or Translations) no longer links to it. If there are items linked to it, those items should be edited to properly point to the the best and most complete of the two.
• Duplicate Documents, Utilities, Hacks, or Translations should be flagged as noncompliant. If two different versions of the item are found, the oldest should be flagged as noncompliant. If the versions are the same, the best and most complete entry should be kept and the other flagged as noncompliant. It may be desirable to edit the intended ‘good’ entry first with any pertinent information that may be lost when the duplicate is removed.

Special Notes

• Please be sure to include a detailed reason for the item’s noncompliance. Specific policy violated should be cited. This will both serve as explanation for staff as well as public record of why an item was removed from the site.
• License or file distribution problems are a non-maintenance item and explicitly covered in our policies. Such items should not be flagged for noncompliance .

• Only direct credits for actual work should be considered for inclusion. Beta Testers and Special Thanks like credits should be omitted. This also applies to Utility Authors unless the utility was specifically designed for the project.
• Anonymous’ credits should be omitted. Anonymity defeats the purpose of the credit lists and our site’s associations for community recognition.
• Every contributor should be listed, including the single ‘members’ of label-groups like Aeon Genesis.
• If a single person is credited to multiple tasks, in general (to avoid clutter), only the most important category should be picked, with additional tasks being listed in the ‘Specific Information’ field. However, if the tasks are major, such as doing both full translation and hacking work, they may be listed multiple times. Use your discretion.
• If the project is based on someone else’s work, the ‘Original XXXX’ options in the ‘Contribution’ field are to be used to credit the inherited work.
• In the event the project was released by individuals rather than a group, those individuals can and should also appear in the credit list.
• If you need to add more than the default 10 items the form allows, you may change the size of the list in the ‘Options’ section at the bottom of the form. Select ‘Preview’ to reflect the change.
• Names written in non-English characters should be transliterated into English.

Special Notes

• People listed in the ‘Name’ drop-down list come from our Community Database. If the person you need is not there, you may use the ‘Name Write-In’ field. After approval, such write-ins will be added to our Community Database for future drop down use.
• If adding a credit list to an existing project that already contains multiple authors, please go back and edit the project entry so the Released By/Author field shows *only* the group or primary person/s the project was released by.
• If adding a credit list to an existing project, please make sure any informal credits that may have been listed in the description are removed from the main entry. There is no need to list credits twice.

• A version is required. If the version is unknown, use ‘1.0′.
• Please choose ‘N/A’ for the game field if a game is not applicable to your document.
• Official documentation or SDKs should be labeled with the author placeholder ‘OEM’ (Original Equipment Manufacturer).
• Only one category can be selected at this time. Please choose the best fitting one.
• Non English Documents are not accepted.
• Documents containing only game specific RAM or savestate hacking are out of scope.

We are aware that some documents may span multiple categories, or apply to multiple games. At this time our system only allows you to select one. We are looking for ways to upgrade our database system and search engine to facilitate more complex relationships. Until that time you must select the single best fitting option. We do provide a ‘Multiple’ option for games as a workaround.

First and foremost, you must submit a patch, ROM submissions aren’t acceptable at all. You should store your patch, a readme, and any other necessary files in a compressed archive, Zip is the most common, RAR and 7Zip are also acceptable. RHDN’s submission form cannot retrieve files from your computer, you must upload them somewhere. URLs to files must be a direct link, meaning when that URL is entered into a browser, a download should start. URLs to sites such as Rapidshare/Megaupload are not acceptable and these submissions will be rejected outright.

Upload a .txt copy of your readme separately from the file to use in the “Readme” field.

Maximum acceptable filesize for RHDN files is 30megs. Submissions with larger files (while still able to be submitted), will need to have the file/s hosted off-site.

Here is a list of free webhosts you can use for your files and screenshots:

• The Scratchpad (Right here on ROMhacking.net!)
• Ze Bucket
• Photobucket (Images Only)
• TinyPic (Image Only)
• imgur.com (Image Only)

File Types

The following file types are currently accepted by the upload form:

• Multi-Platform Compression:
  • ZIP
  • RAR
  • 7Z
  • TAR.GZ
  • BZ2
• Windows:
  • EXE
• Mac OSX:
  • DMG
• Document Formats:
  • DOC
  • RTF
  • TXT
  • HTML
  • PDF
• Readme Formats:
  • TXT
• Image Formats:
  • GIF
  • PNG
  • JPG
  • JPEG

Image Resolutions

Clean, native console resolution screenshots are required. Please see our Screenshots policy for more details.

Only original fonts are being accepted at this time. Fonts ripped from games are no longer being accepted!

Files must be compressed archives containing the following:

• A BMP file of the font (can be made with Tile Molester, Feidian, Tile Layer Pro, and others).
• A table file or character map. If the font contains ASCII characters only, this may be omitted.
• Any other format or files you wish to provide in addition to the above.

Preview Image should be one of the following: (Note: Image must be in compressed format such as PNG)

• In game screenshot with plenty of text.
• A test sentence or two on transparent or solid background demonstrating font.
• A copy of the full font. (Discouraged in favor of the above better options)

Ideally, preview images should be in PNG format.

• The Primary Title should be the earliest official English title. If no official English title exists, it should be the original release title, no matter the language origin (i.e. Seiken Densetsu 3). (See full policy)
• Multiple Alternate Titles are allowed separated via semicolon. (See full policy)
• The release date should be for the earliest date if the game was released in more than one country. In most console game releases, this is the Japanese release date. (See full policy)
• The title screen image should reflect the version of the game the primary title refers to.
• The publisher should reflect the primary title’s version of the game at the time of publication (typically what appears on the title screen). Use Informal company names. Suffixes like Co/Corp/Ltd should be omitted.
• Genres disputes shall be decided by referring to GameFAQs as an authoritative source. If the sub-genre exists on RHDN, it should be chosen. If it does not, the first available genre up the chain should be chosen. If none of the available genres exist on RHDN, ‘Other’ should be chosen or raise the issue with staff to add a genre.
• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!

We have specific policy on primary and alternate titles, title screens, and release dates. We urge you to read over (our full policy) on these matters.

Primary Title

The Primary Title should be the earliest official English title. If no official English title exists, it should be the original release title, no matter the language origin (i.e. Seiken Densetsu 3).

• Titles should match the cover/box art as closely as possible (i.e. Titles such as “The 7th Saga” should be written as is. Roman numerals should be written as shown and not substituted. Special characters such as in “Pokémon” should be written as is.).
• Each word should begin with a capital letter. Words such as “the”, “of”, “from”, “and”, “or”. and “to” are not written with a capital letter unless it’s the first word in the title or subtitle.
• Main title with subtitles should be written in the form of “Title: Subtitle” (i.e. Castlevania III: Dracula’s Curse).
• Main title with subtitles and chapter or special edition should be written in the form of “Title: Subtitle - Chapter/Edition” (i.e. Street Fighter III: 3rd Strike - Fight for the Future

Alternate Titles

The Alternate Titles field should typically be one of the following:

• If the Primary Title is English, and game title was not originally English, this is the title in the original language. (i.e. if the original title is Mega Man 3, this would be Rockman 3)
• If the game does not have an official English title, and thus the Primary Title is not in English, this is a fan-translated English title. (i.e. Rudra no Hihou as the primary, and Treasure of the Rudras as alternate)
• Multiple Alternate Titles can be added, separated via semicolon, to add the following:
  • Official foreign titles of the game.
  • Official abbreviations of the title.
  • Romanization of Official Title - Latin character only. No accented characters.

Release Date

• If the game was released in more than one country, the earliest date should be used. In most console game releases, this is the Japanese release date.
• The date should be written in the following format: DD Month YYYY (An example of this format is: 02 December 2006)
• The release date should be from GameFAQs if a better source is not known. You may enter a month and a year such as ‘April 2007′ or just a year as ‘2007′ if only a partial release date is known.”
• For unreleased games, a special case date of ‘1 January 1970′ should be used. This will show up as ‘Unreleased’ across the site.

Title Screen

• The title screen image should reflect the version of the game the primary title refers to.

Publisher

• The Publisher should reflect the Primary Title’s release of game.
• The Publisher should reflect the company name at the time of publication (typically what appears on the title screen. Consult GameFAQs if unsure.)
• Use Informal company names. Suffixes like Co/Corp/Ltd should be omitted.

Genre

• Genres disputes shall be decided by referring to GameFAQs as an authoritative source.
• If the sub-genre exists on RHDN, it should be chosen. If it does not, the first available genre up the chain should be chosen.
• If none of the available genres exist on RHDN, ‘Other’ should be chosen. Alternatively, the issue may be raised with staff to add a new genre to the list.

Game Description

• Describe the game with absolute points in mind.
• Should not a be written as a game review.
• Summarize the story of the game, but do not include potential spoilers.
• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!

Overview

This form may look pretty intimidating at first, but it’s really quite simple. This is the required information necessary for our database to generate a page and catalog your submitted material! This is what needs to happen in order for the power to truly be in your hands. Your submission will feed directly into our database (after staff approval of course). Romhacking.net prides itself on having an archive of the highest quality ROM hacking material on the internet. The quality of your submission, and information presented, will directly impact the image of this site. Please make a serious effort. Fill the form out completely.

Please take a moment to read the following guidelines and ensure that your submission meets our requirements and is of the highest quality before submitting. If you have any questions, please ask on the message board FIRST! That’s it. Get to it and let’s make this the best ROMhacking community site on the net!

General Guidelines

• Click the ‘?’ icon for help and/or clarification on any field in the form you’re not sure about.
• BBCode is allowed and encouraged for all description and review fields. Use it to make nice looking bulleted lists, bold text, italic text, and more!
• Double check that the game title and author name are not already in the database (or under an alternate name) before writing them in manually!
• Please write up an adequate length description. That’s what all our visitors are going to see. Proof read your work and check for spelling errors!
• Screenshots are highly encouraged. A picture is worth 1000 words and they will encourage visitors to try out your submitted material!
• Screenshots should be clean and in native resolution of their respective platform. (Screenshot Policy)
• All file and image fields are URL based. That means you must input the URL to a file or image stored on another site or personal webspace. Upon approval, the files will be copied to our servers. You can upload your files for submission purposes to The Scratchpad (Right here on ROMhacking.net!) if you do not have your own personal webspace.
• Non English descriptions are not accepted in any section.
• Descriptions should be informative in nature and not contain personal advertising such as donation or funding links.
• For current generation platforms (including Nintendo Switch, Playstation 5, Playstation 4, Xbox Series X or S, and Xbox One), no hacks or translations are permitted at this time.
• Submissions for games still commercially available on the intended platform are not permitted.

While we try to minimize subjectivity, we realize there is some subjectivity involved in interpreting if a submission meets the guidelines. Understand that submission reviewers may not be familiar with your nature of the submitted project and can only make a determination based on the information presented. Be sure to include adequate information in the description of all submissions. If you feel your submission may have been rejected in error, please use the contact staff form to reach the general staff. Be sure to cite specific reasoning and reference policy where appropriate. Should staff agree, your submission will be reconsidered for inclusion. Staff may also elect community-based judgement, or public discussion of a wider reaching issue if appropriate. Public discussions regarding specific submission rejections should only be started by staff.

• Descriptions should contain the purpose of the hack, what is changed from the original, and why someone would want or need to use it. Assume no familiarity.
• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!
• Including a readme file is highly recommended, but not required. The readme field is plain text format files able to be viewed properly in an internet browser. Other formats should be included in your archive file only.
• You must include one screenshot, but have the option to include three additional ones and a title shot. Ideally all complete hacks will fill in all five screenshot fields. (Screenshot Policy)
• You are required to provide identifying information regarding the ROM or ISO your patch is for in the ‘ROM/ISO Information’ field. One identifying item per line. Items may include ROM database filenames (such as No-Intro filenames), file hashes (SHA-1, SHA-256, CRC32, MD5) and more. (Please see the full explanation)
• All hack images are expected to be safe for work/school viewing.
• Hacks by “unknown” or “anonymous” authors are not currently accepted. This option led to too many hacks with inadequate information.
• PC hacks are generally out of scope as there are many entire sites devoted to PC game modding. However, an exception may be made for something unique to our community such as obscure Japanese PC game translations.

Categories

RHDN accepts hacks that fall into four categories. If your hack falls into more than one category, choose the one you think best represents the purpose of your hack.

• Complete: A Complete hack has its own identity and an established premise of change applied throughout the entire game (levels, graphics, text, etc.). It should not appear as a minor variation of the original game, nor contain partially implemented ideas. For instance, a complete graphics and level hack would consist of most or all graphics and levels changed. (Example)
• Improvement: These hacks tweak or improve on some aspect of the original game, while leaving the majority of the original content intact. An example would be a hack that adds a new powerup to a platformer, or a new magic spell in an RPG. Improvement hacks are often ones intended to be used as a base for other hacks. (Example)
• Bugfix: A subcategory of Improvement for easy filtering; these are Improvement hacks that only fix bugs in the original game. This covers code, data and/or graphical fixes. (Example)
• Addendum: A hack that fixes bugs, improves upon, or revamps another author’s released hack. The resulting patch is intended to be a non-translation hack. Patches should contain addendum work only unless it is not possible due to the technical requirements of the patch (such as patches targeting a different ROM). The original work the hack is an addendum to should be linked in the description (The original hack must be on the site also!). Significant improvements that cause the hack to take on a new identity are exempt and may be submitted under the Complete category. (Example)

Non-Permitted Items

The following types of hacks are NOT accepted:

• Demos/Alphas/Betas: Any incomplete version of a hack, usually given out well before the final version is ready, for feedback or other purposes is not accepted. You may post such hacks on the forum.
• Texture Packs: Commonly made for Nintendo 64 games, and consisting of new textures which will be loaded in place of the originals. Actual texture hacks are acceptable ( as long as they are complete ), however these packs are not.
• Emulator Specific Hacks: Any hacks that are known to only run properly on a single emulator such as ZSNES or Nesticle only hacks.
• Forbidden Content: Although ROMhacking.net has no content restrictions of its own, our service provider forbids “sexually explicit, hateful, vulgar, racially, ethnically or otherwise objectionable materials”. Therefore these types of hacks are not permitted.
• Commercial: Commercial hacks are not permitted.
• Cheat Hacks: While hacks that rebalance difficulty or modify game mechanics may be considered Improvement hacks, those with a primary purpose of cheating, or those that only apply simple cheats (infinite lives, invincibility, game genie or pro action relay codes) are considered out of scope for RHDN.
• Incomplete Sprite Hacks: Sprite changes or character swap hacks that lack required functionality (such as animations, text, or game-play changes) to support their inclusion into the game are considered non-improvements and incomplete. One example is swapping Mario for a Marshmallow without other accompanying gameplay and text changes to support it. Another example is only changing coins to unrelated candy canes with no clear game fitting purpose. Purposeful sprite changes for visibility, color changing, de-censoring, graphical skins, improved animation, related character swaps etc. are acceptable as long as there are no broken animation frames or graphics.
• Font Hacks: Font hacks outside of readability related improvements (such as cryptic fonts) are not accepted.
• Disablers: Hacks that deprive a player of basic gameplay elements or contain incomplete or game breaking changes are not permitted. Some examples include invisible player sprites, corrupt graphics, nonsensical text, broken sound, removing basic player movements, or disabling all attack possibilities.
• Commotional Hacks: Hacks featuring political candidates or parties, ‘joke’ hacks negatively targeting specific people or groups, inside/personal joke hacks, community trolling, or other non video game franchise related commotional items are not accepted.
• Randomizer Hacks: Randomizer-generated files by themselves are not considered hacks. They will not be accepted unless additional work was done, in which the additional work itself would qualify it for submission. Inclusion of randomized content into a broader hack is OK, but running the latest randomizer for Game X and submitting the result is not.
• Homebrew Hacks: Hacks of Homebrew are not currently accepted.
• Code Hacks: Hacks that only implement known or published Pro Action Replay (PAR), GameShark, Game Genie or other code device codes are not permitted. Most emulators and flash carts support entering codes directly. Hacks may include implemented codes if other more complex changes are accompanied.

• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!
• Including a readme file is highly recommended, but not required. The readme field is plain text format files able to be viewed properly in an internet browser. Other formats should be included in your archive file only.
• You must include one screenshot, but have the option to include three additional ones and a title shot. Ideally all full games will fill in all five screenshot fields. (Screenshot Policy)
• You are highly encouraged to include source code with your homebrew programs and choose an appropriate software license for it. Typical licenses include those provided by Creative Commons and GNU. A copy of the license should ideally be included in the file archive. If you are unsure of the license, you may use “Custom” or “None whichever may be more appropriate.

Categories

RHDN accepts homebrew that falls into three categories. If your homebrew falls into more than one category, choose the one you think best represents the purpose of your program.

• Full Games: These programs are complete games.
• Tech Demos: These are finished programs that aim to demonstrate some technical achievement with a given platform. Such programs may be designed as proof-of-concepts, showing off various hardware abilities, or other technical marvels.
• Hardware Tests: These are finished programs that aim to test a single specific hardware feature, or group of related hardware features. Such programs may be designed to test emulator accuracy, educate users, or demonstrate usage of particular hardware functions. “Hello World” type programs would also qualify here.

Non-Permitted Items

The following types of homebrew are NOT accepted:

• Commercial Material: Any software which is for commercial sale is prohibited!
• Copyrighted Assets: Any software which may contain assets the author does not have rights to use (such as ripped game graphics or music) is prohibited!
• Game Demos/Alphas/Betas: Any incomplete version of a game, usually given out well before the final version is ready, for feedback or other purposes is not accepted. You may post such projects on the forum.
• Emulators: Programs that emulate other consoles are out of scope.
• Emulator Scripts: Programs or scripts designed to run on emulators to enhance existing games are out of scope.
• Freeware PC Games: This is out of scope for RHDN. There are many sites dedicated to freeware PC games and programs.

The following guidelines apply to adding links in the Links section.

• Please ensure the link is ROM hacking related and fits in one of the available categories.
• The links should be used only for resource sites that are not personal or project pages. Such pages are in the Community Database.

If you are submitting news relating to a document, utility, or patch release (or anything carried on this site), please go to Submit Files, create an entry, and add the file to our site. For updates, you can simply edit the existing entry page! After your submission is approved, you should submit the news article with a link to the entry page in the ‘RHDN Project Page’ field. News articles without a corresponding project page (where applicable) may be delayed or rejected. This process ensures all news and entry pages will be properly linked and be able to be cross referenced by our visitors.

Check the status of your submission.

News referencing other ROM hacking sites are allowed if non-overlapping and non-competing with RHDN (such as most personal, project, and game specific sites). Advertisements are not allowed.

• For translation or hack projects, include at least a sentence or two about what the game is and what platform it is for. Not everyone may know about the game in question.
• A bit of history about the project should be included. When did it start and who was involved? This is valuable information to aid users in assessing and appreciating the material.
• One image (up to 640×480) or two images (up to 320×240 each) are accepted.
• Although an account is not required for news submission, if you are logged in, your news submission will be linked to your account profile.
• News should be written in third person as is standard across most major wiki based sites as well as academic and professional writing.
• News images are expected to be safe for work/school viewing.

This field is here to give users more information on the specific ROM or ISO that the patch requires.

Many hacks and translations need to be patched to a very specific game in order to function. For instance, many hacks of Final Fantasy III are intended for the original release of the game, whereas some require the 1.1 version of the ROM. Wouldn’t it be great to be able to tell, at a glance, which specific ROM works with which patch, without having to carefully check the hack’s description or scour its readme? Why, you bet it would!

How to use

The easiest and preferred method is to simply use RHDN’s Online ROM Hasher, and copy and paste the generated information. All of the hard stuff is figured out automatically and already provided in RHDN’s preferred formats. Alternativly, you can download ROM Hasher if you prefer a local utility.

For ROMs, at least one identifying name and one hash is required. For ISOs, you may add common filenames, PSX SLUS game ids, or other identifying information.

Each bit of information should go on a single line. Each line should also have an identifier to show where the information was obtained (CRC32, No-Intro, Pocketheaven, PS serial number, etc). Preferably, names taken from ROM databases will have the database’s version number or release date, since ROM databases are quite prone to changing names for ROMs at a whim.

Good:

• Database match: Final Fantasy III (USA) (Rev 1)
• Database: No-Intro: Super Nintendo Entertainment System (v. 20180813-062835)
• File/ROM SHA-1: 057ADA1C641E3E0B3CA34E6E4F4EB1B05A87143A
• File/ROM CRC32: C0FA0464

Bad:

• Use the US 1.1 ROM.
• C0FA0464

The ROM/ISO Information field can be pretty easily split among two basic types: checksums, and identifying names.

Checksums

In simplest terms, a checksum is a number, usually in hexadecimal, that is unique to a file. An algorithm is run on the file that compares all of its binary data, and produces a unique number as a result. Modifying a single byte, or even a single bit, in a file can completely change its checksum.

Because checksums are (mostly) completely unique, they’re a great way to quickly compare files to make sure that all of the data in each file are one-hundred-percent exactly identical. This way, if you have a ROM with a checksum that matches the checksum provided on Romhacking.net, you’re (mostly) guaranteed to have the correct ROM for the patch you want.

I say “mostly” because the numbers can’t all be exactly, perfectly unique. The most commonly-used checksum algorithm is called CRC32, and produces an eight-digit hexadecimal number for a checksum. An eight-digit hexadecimal number can only count from zero to 4,294,967,295, though, and there are WAY more files than that out there on the internet. So, in mathematical terms, you *can* have two completely different files with the same checksum, but in the practical world, you only have a one in four billion chance of it actually happening to you.

There are many different checksum algorithms out there, and as a general rule, the more digits it’s able to generate, the more unique the number is. CRC32 is the most common algorithm, but the most preferred ones here at RHDN are SHA-1 or SHA-256. MD5 is also popular.

That’s fine, you say, but how do I actually calculate the checksum myself, right? If you’re using Windows, the simplest method is to install a shell extension. HashTab is my favorite, but there are many others. Once it’s installed, you can just right-click any file and choose Properties to see the checksum in a new tab. Easy! There’s checksum calculators for other OS’s too, but a method everyone can use is going to a website such as this one and uploading the file to the site. It will list many popular checksums for the file for you, right there on the page.

An alternate method is to use near any hex editor. For a quick example, download this hex editor, HxD. Open your source ROM. Click Analysis -> Checksums -> Highlight CRC32, SHA-1, SHA-256, MD5, and click OK. Copy that Information! Those file hashes will unmistakeably identify the ROM your patch is intended for!

Identifying names

“Identifying name” is a good general descriptor of any particular name that identifies a certain game as being different from others. No rules! Anything to set it apart is fine, as long as it’s easy to tell where it came from. Since RHDN deals with games on cartridge pretty frequently, ROM databases will likely be used the most often.

ROM databases first gained popularity in the late 90s (I think?) with GoodNES, a tool that could scan all those ROMs you downloaded from all those weird FortuneCity sites, and would compare each ROM’s checksum with an internal database. From the database, GoodNES could determine what game you have, what country it came from, whether or not it was a bad dump, whether someone hacked it or added a trainer, and so on. All that information is easy to take for granted nowadays, but when you’re on an FTP downloading hundreds of games that only have eight-letter filenames, sometimes you have no idea what game is which, even (for the Japanese games) when you sit down and start playing them. Just think, for years you could’ve been playing Super Mario Bros. without a title screen and never know something was wrong, without ever realizing that pressing Select could make Mario swim through the air! Emulation was pretty weird back then.

Cowering, the creator of GoodNES, then went on to create databases for most other game systems, but with not nearly as clever names: GoodSNES, GoodGen, GoodMSX, and so on. Other databases have also come along, with different functions and purposes. Romhacking.net’s recommended database is No-Intro, though it’s hard to figure it out if you’re not intimately familiar with the arcade ROM curation community and the programs they use. The “GoodTools” are far more popular, though they’re very seldomly updated, and only by one guy who insists on keeping his databases from the public. This makes them easy to use, though, so long as you’re familiar with the command line. There’s also the Zapatabase, which you don’t really ever see, but it’s open and very easy to use, if that’s your thing.

ROM databases aren’t the only identifying names, though! You can use the official filename if it’s a Windows file, or the program’s version number. Or, you can use the Pocketheaven release number for Nintendo handhelds, because you still see those sometimes! Or, PlayStation games can use their serial number! For instance, the limited-edition version of Tokimeki Memorial: Forever with You for PS1 has a serial number of SLPS-00064! No other PlayStation game has that serial number!

Restrictions are in place for material pertaining to current consoles, platforms, and games.

For current generation platforms, no hacks or translations for these systems are permitted at this time. Current generation platforms are those still being commercially manufactured by their original developers. The following is a list of what are, at the time of writing, considered ‘current’ platforms:

• Nintendo Switch
• Playstation 5
• Playstation 4
• Xbox Series X or S
• Xbox One

This restriction also extendeds to current games on any platform. Therefore, no hacks or translations are permitted for games still commercially available on the intended platform.

• A review must consist of a headline summarizing an established opinion, along with body of text containing supportive evidence or reasoning for that opinion. Specific points given must be from an experience of using the item being reviewed. Text is expected to address other users of the item rather than a message or comment to the author.
• We expect supporting evidence in all reviews! You are free to like or dislike an item, but you must specify reasons why in a constructive, respectful fashion. At least some specific points are required. Reviews such as ‘This is good!’ or ‘This sucks’ without accompanying supporting evidence or specific points from the experience will be rejected.
• Reviews should be written in English only, even for non-English translations such as Spanish, Portuguese, Italian, etc.
• Linking to additional review information such as videos or off-site text is allowed only in addition to a text review. Reviews containing only reference to external links are not acceptable.
• Comparisons to other similar or alternative items are encouraged and will be viewed as being helpful and informative.
• Numerical ratings or scores, though allowed, are discouraged. Our goal is to put the emphasis on the review content and we already support a ‘Recommended’ or ‘Not Recommended’ selection to your review.
• Users are encouraged to use all BB code formatting tools available to present the most organized, clean reviews possible. For example, when making lists or bullet points, please use the associated BB code for lists.

Non-Permitted Items

• Reviews consisting exclusively of bug reports, patching problems, feature requests, unrelated comments, or questions are not permitted. Such items are generally best suited for direct reporting to the author or related project forum discussion topics. Such items can be mentioned for benefit of all in addition to a review, but they cannot be the only thing contained in the review.
• Reviews based solely on an item’s entry text, author, or hack premise without direct experience using the item are not permitted.
• Non-English reviews are not permitted.
• Reviews without any specific points about why an item is liked or disliked, recommended or not recommended, from a direct experience of using the item in question are not permitted.
• Reviews containing insulting language are not permitted.

Staff reserves the right to reject reviews for reasons not specifically mentioned here to uphold a level of professionalism and usefulness of the User Reviews feature.

As per the Screenshots policy, native resolution screenshot images are required. The following are the known acceptable resolutions that the submission system enforces for each platform. Platforms not listed here are either unknown or do not have fixed resolution modes.

Atari 2600

• 192×160

Dreamcast

• 640×480

Famicom Disk System

• see Nintendo Entertainment System

Game Boy/Game Boy Color

• 160×144

Game Boy Advance

• 240×160

GameCube

• 480i (720×480) (640×480)
• 576i (720×576) (640×576)
• 480p (720×480) (640×480)

Game Gear

• 160×144

Megadrive/Genesis/SegaCD

• 256×224
• 256×448
• 320×224
• 320×448
• 256×240(PAL and NTSC)
• 320×240
• 256×480
• 320×480 PAL only)

Jaguar

• “Programmable screen resolutions, from 160 to 800 pixels per line. The resolution can be increased even further with additional hardware up to a reported 1350 pixels per line.” I.e. this console sucked so much no one got around to figuring out what the max resolution was.

Master System

• 256×192
• 256×224
• 256×240 (PAL/SECAM)

MSX

• 256×192

MSX2, MSX2+, MSX TurboR

• 80×24 text mode
• 256×192 graphics mode
• 512×212
• 256×212

NeoGeo CD

• 304 x 224

NeoGeo Pocket

• 160×152 (256×256 virtual screen)

Nintendo 64

• 256 × 224
• 320 × 240
• 640 × 480

Nintendo DS

• 256×192 per screen

Nintendo Entertainment System / Famicom

• 256×240 (256×224 also acceptable with over scan cut off)

Nintendo Wii

• 480i (720×480) (640×480)
• 576i (720×576) (640×576)
• 480p (720×480) (640×480)

PC

• If you can dream it, you can do it.

Playstation

• 256×240
• 320×240
• 384×240
• 512×240
• 640×240 Non Interlaced
• 256×480
• 320×480
• 384×480
• 512×480
• 640×480 Interlaced

Playstation 2

• NTSC-NI 640×240(224)
• NTSC-I 640×480(448)
• PAL-NI 640×288(256)
• PAL-I 640×576(512)
• VESA-1 640×480
• VESA-2 800×600
• VESA-3 1024×768
• VESA-4 1280×1024
• DTV-480P 720×480
• DTV-1080I 1920×1080
• DTV-720P 1280×720

Playstation Portable

• 480×272

Sega Saturn

• Horizontal sizes of 320, 352, 640, 704 pixels
• Vertical sizes of 224, 240, 256 scanlines, non-interlaced
• Vertical sizes of 448, 480, 512 scanlines, interlaced (only PAL consoles support 256 and 512 scanline displays)
• Hi-Vision (EDTV) and 31 kHz (VGA) display support:
  • 31 kHz: 320×480 or 640×480, non-interlaced (progressive scan)
  • Hi-Vision (EDTV): 352×480 or 704×480, non-interlaced (progressive scan)

Sega 32x

• 320×224
• 320×240
• 320×204 (direct color)
• 320×408 (8bpp)
• 450×262 (Overscan NTSC)
• 450×313 (Overscan PAL)

Sega CD

• See Genesis

Sega SG-1000

• 256×192

Super Nintendo

• Progressive:
  • 256×224
  • 512×224
  • 256×239
  • 512×239
• Interlaced:
  • 512×448
  • 512×478

Turbografix-16

• X (Horizontal) Resolution: variable, maximum of 565 (programmable to 282, 377 or 565 pixels, or as 5.37mhz, 7.159mhz, and 10.76mhz pixel dot clock)[15] Taking into consideration overscan limitations of CRT televisions at the time, the horizontal resolutions were realistically limited to something a bit less than what the system was actually capable of. Consequently, most game developers limited their games to either 256, 336, or 512 pixels in display width for each of the three modes.[16]
• Y (Vertical) Resolution: variable, maximum of 242 (programmable in increments of 1 scanline) It is possible to achieve an interlaced “mode” with a maximum vertical resolution of 484 scanlines by alternating between the two different vertical resolution modes used by the system. However, it is unknown, at this time, if this interlaced resolution is compliant with (and consequently displayed correctly on) NTSC televisions.
• The majority of TurboGrafx-16 games use 256×239,[15] though some games, such as Sherlock Holmes Consulting Detective did use 512×224. Chris Covell’s ‘High-Resolution Slideshow’ uses 512×240.

Virtual Boy

• 384 x 224

Wii

• 480i (720×480) (640×480)
• 576i (720×576) (640×576)
• 480p (720×480) (640×480)

Wonderswan

• 224 x 144

x68000

• 256 x 240
• 256 x 256
• 512 x 240
• 512 x 256
• 512 x 512
• 640 x 480
• 768 x 512
• 1024 x 1024

XBox

• 480i(720×480)
• 480p(720×480)
• 576i(720 x 576)
• 576p(720 x 576)
• 720p (1280×720)
• 1080i (1920×1080)

• All screenshots used in submissions must be “clean.” Clean means they are at the console’s actual resolution with no video filters enabled, and they shouldn’t contain the emulator window.
• Acceptable native resolutions for each console can be found below in the Resolution section.
• All screenshots must be in a compressed image format, preferably PNG or GIF, JPEG is not recommended as it reduces the image quality. Bitmap (BMP) screenshots will be rejected.
• All screenshots must be an in-game captured images. Other types of images such as boxart, manual covers, posters, or “photoshopped” images are not allowed.
• All hack images are expected to be safe for work/school viewing.

If you take the time to read the documentation that comes with your emulators you will find most of them support saving a clean screenshot. For your convenience we have provided a list of popular emulators with instructions on how to save a clean screenshot:

Nintendo Entertainment System

• FCE Ultra (All variations)- Hit F9 to save a PNG screenshot.
• Nestopia - Select “Paths…” from the Options menu, make sure “PNG” is selected as the image format. Hit Alt and E or select “Save Screenshot” from the File menu to save a PNG screenshot.
• NNNesterJ - Hit F12 or select “Screen Shot” from the File menu to save a PNG screenshot.

Nintendo Game Boy

• BGB - Right click the emulator window and select “save screenshot” from the menu to save a bitmap (BMP) screenshot. Open this bitmap in an image editing program and save it as either a GIF or a PNG.

Super Nintendo Entertainment System

• ZSNES - Hit F1, change “IMAGE FORMAT” to “PNG,” select “SAVE SNAPSHOT.”

Sega Genesis/Mega Drive, Sega CD, 32X

• Gens Plus - Select “Configuration” from the Options menu and make sure “Compress screen shots (GIF)” is checked. Set the video mode to Normal, turn off any video filters, hit Shift and Backspace or select “Screen Shot” from the Graphics menu to save a GIF screenshot.
• Kega Fusion - Set video mode to Normal, turn off any video filters, hit Shift and F12 or select “Save Screenshot” from the File menu to save a bitmap (BMP) screenshot. Open this bitmap in an image editing program and save it as either a GIF or a PNG.

Sony Playstation

• pSX Emulator - Hit F12 to save a PNG screenshot.

Nintendo 64

• Project64 - Select “Generate Bitmap” from the System menu to save a bitmap (BMP) screenshot. Open this bitmap in an image editing program and save it as either a GIF or a PNG.

Nintendo Game Boy Advance

• VisualBoyAdvance - Select “Emulator” from the Options menu and make sure “PNG format” is checked. Select “Screen capture…” from the File menu to save a PNG screenshot.

Most emulators with screenshot options allow you to set up a screenshot directory where they will be saved. If you don’t set up a screenshot directory most emulators will save the screenshot to the same directory as your ROM.

If you’re using an emulator that doesn’t have an option to take a clean screenshot you’ll have to take one “the hard way.” First, open your emulator, make sure it’s running windowed at the console’s resolution and turn off any video filters you have on. Hold down Alt and hit Prnt Scrn, this will copy a screenshot to your clipboard. Paste this into any image editing program and crop out the window border, leaving only the in-game image.

• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!
• Including a readme file is highly recommended, but not required. The readme field is plain text format files able to be viewed properly in an internet browser. Other formats should be included in your archive file only.
• You must include one screenshot, but have the option to include three additional ones and a title shot. Ideally all complete translations will fill in all five screenshot fields. (Screenshot Policy)
• You are required to provide identifying information regarding the ROM or ISO your patch is for in the ‘ROM/ISO Information’ field. One identifying item per line. Items may include ROM database filenames (such as No-Intro filenames), file hashes (SHA-1, SHA-256, CRC32, MD5) and more. (Please see the full explanation)
• PC hacks are generally out of scope as there are many entire sites devoted to PC game modding. However, an exception may be made for something unique to our community such as translations of Japanese only releases.
• The translation section designed strictly for game translations. Translations of hacks, utilities, documents, or any other item are not permitted in this section.

Categories

RHDN accepts translations that fall into four categories.

• Fully Playable: This is for completed projects where the patch is fully playable in the target language.
• Unfinished: This is for incomplete projects where the patch is not fully playable in the target language.
• Announced: This is for announced projects with no released patches yet.
• Addendum: This is for translation projects that fix bugs, or improve upon an existing translation project released from another author/s. The resulting patch is intended to also be a translation. Patches should contain addendum work only unless it is not possible due to the technical requirements of the patch (such as patches targeting a different ROM). The original work the hack is an addendum to should be linked in the description (The original hack must be on the site also!). Significant improvements that convert an unfinished translation to a fully playable translation are exempt and may be submitted under the Fully Playable category. (Example)

Non-Permitted Items

• Machine translation patches may be accepted so long as a reasonable amount of effort has been put into editing so it doesn’t sound like straight broken English.
• RHDN does not permit translation patches for products that have only recently been released, have been announced as coming to the target language on the target platform, or can reasonably be expected to receive such an announcement. This includes ‘0-day’ material. (See full policy)
• RHDN does not permit translation patches that may be viewed as encouraging piracy, ‘competing’ with publishers/developers, or patches containing ROMs or other infringing materials.
• Translations by “unknown” or “anonymous” authors are not currently accepted. This option led to too many translations with inadequate information.
• General game hacks that may incorporate a translation, but are not intended to be translation hacks themselves, belong in the Hacks section.
• Commercial translations are not permitted.
• Translations of Hacks: Translations of Hacks are not formally recognized. They are considered regular text hacks of another author’s work. Such hacks would be classified as an Addendum category entry in the Hacks section. Applicable Addendum category rules apply, and the base hack must be present in the database.
• Translations of Homebrew: Translations of Homebrew are out of scope and not currently accepted. Consider contacting the developer to include your translation in the official distribution.

• Descriptions should contain the romhacking related purpose of the utility, what it specifically does, and why someone would want or need to use it. Assume no familiarity.
• Descriptions should be written in third person as is standard across most major wiki based sites as well as academic and professional writing. No one knows who ‘I’ or ‘we’ are in community edited descriptions!
• A version is required. If the version is unknown, use ‘1.0′.
• Only one category can be selected at this time. Please choose the best fitting one.
• Please choose ‘N/A’ for the game field if your utility does not apply to any specific game.
• Please choose ‘Not Applicable’ if your utility does not apply to any specific platform.
• Choose ‘Multi-Platform’ if your utility applies specifically to multiple game platforms.
• Only one operating system platform can be selected. ‘Indep’ should be be chosen if the release is cross platform.
• In the event there are multiple releases of the utility for different operating systems, they should each get their own Utility entry.
• If available, source code should be included in the archive.
• A screenshot is required. Command line utilities should display a command line image of either the help output of the program or any operational example command line string for the utility.
• Utilities must target console ROM/ISO hacking, Japanese home computer hacking, or a rare exception for obscure Japanese PC games.

Non-Permitted Items

• Game specific cheat utilities (including game save editors, save state editors, and trainer like utilities) with the primary purpose of aiding in game cheating/enhancing is beyond the scope of RHDN.
• Password Generators are also classified as cheat utilities and out of scope unless they contain ROM hacking related information, such as source code with engine details, or documentation such as this example entry.
• Non English Utilities may be accepted only if they have translated English Instructions, or are so intuitive language doesn’t matter.
• Third party dependencies, libraries, or applications that may be needed for certain software are out scope for RHDN. Such software includes DOS extenders, DOSBox, WINE, Virtual PC, .NET framework, DirectX, the Visual Studio C++ runtime DLL files, Linux dependencies etc.
• General use PC utilities without ROM hacking specific features are out of scope. Such software may include regular hex editors, word processors, image viewers, file archivers, etc.
• PC or mobile game modding utilities are not permitted and out of scope. Bigger and better homes exist on the web for those.
• Commercial utilities are not permitted. This includes utilities containing ads.

We are aware that some utilities may span multiple categories, multiple games, multiple platforms, and multiple operating systems. At this time our system only allows you to select one. We are looking for ways to upgrade our database system and search engine to facilitate more complex relationships. In the meantime, we provide several workaround options mentioned in the guidelines above.