Theme

Newest Hacks

Super Mario Bros. NEW SMB w/ SMB3 GFX Hack Bomber Mario Battle City 2

Newest Translations

Ghostbusters Trouble Shooter Twin Cobra Twin Cobra

Newest Utilities

Spike McFang de/compressor Ocarina Text Editor Rockman & Forte Compression / Decompression Tools No Image Available

Newest Documents

Documents

Newest Reviews

Lei Dian Huang: Bi Ka Qiu Chuan Shuo Double Dragon II (Easy) Dragon Warrior II General Improvement Mahou Kishi Rayearth 2nd: The Missing Colors

Newest Homebrew

MashyMashy UWOL - Quest for Money Christmas Craze Russian Roulette

ROMhacking.net Policy

Tribal Knowledge in Written Form

Abandoned

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

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, Licensing, and Noncompliant Items

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.
  • 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 reasons for the item’s noncompliance. 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 .

Credits

  • Only direct credits for actual work should be considered for inclusion. Beta Testers and Special Thanks like credits should be omitted.
  • 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.

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.

Documents

  • A version is required. If the version is unknown, use ‘1.0′.
  • Please choose ‘NA’ 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.

File Submissions

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:

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.

Fonts

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.

Games

  • 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 in academic or professional writing.

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

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 in academic or professional writing.

General Submission Form Rules

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! No local uploads are allowed at this time for security reasons. (Submission File PolicySee our file recommendations.[/url])
  • 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 3DS, Nintendo Wii U, Playstation 4, Playstation Vita, and Xbox One; only news, documents, and utilities may be submitted. No hacks or translations are permitted at this time.

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 unfairly, please either respond directly to the staff member whom issued the rejection notice, or 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.

Hacks

Categories

RHDN accepts hacks that fall into five 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)
  • Spoof: Complete Hacks that specialize in humor, usually being parodies of the original game. They also frequently contain adult content. The same rules apply to them as do Complete hacks. (Example)
  • Improvement: These hacks improve on some aspect of the original game, while leaving the majority of the original content intact. Game Improvement hacks must be in the spirit of an extension or enhancement to the original game. 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. While hacks that rebalance difficulty or modify game mechanics may be considered improvement hacks, those that apply simple cheats (infinite lives, invincibility, game genie or pro action relay codes) are considered out of scope for RHDN. (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). 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.

Guidelines

  • Descriptions should be written in third person as is standard in academic or professional writing.
  • 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 spoof and 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.

Homebrew

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![/b]
  • 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.

Guidelines

  • Descriptions should be written in third person as is standard in academic or professional writing.
  • 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.

Links

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.

News

If you are submitting news relating to a document, utility, or patch release (incomplete/demo ROM hacks do not apply), 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.

  • 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 in academic or professional writing.
  • News images are expected to be safe for work/school viewing.

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.

Restricted Consoles and Platforms

For current generation platforms, submissions are restricted to news, documents, and utilities. No hacks or translations for these systems are permitted at this time. The following is a list of what are, at the time of writing, considered ‘current’ platforms:

  • Nintendo 3DS
  • Nintendo Switch
  • Playstation 4
  • Playstation Vita
  • Xbox One

If you have material for a platform that is a.) not available to select in site drop down boxes and b.) does not fall into the above current generation restrictions, please contact staff alerting them of the material you’d like to add along with the platform option that is not currently provided.

Reviews

  • Your reviews must be constructive in nature. User Reviews are expected to be helpful to other visitors in evaluating items on our site. Reviews such as ‘This is good!’ are not very helpful and will be rejected.
  • 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 can be as short or as long as you’d like so long as it meets all other requirements.
  • 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.
  • 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.
  • Whenever possible you should state the VERSION of the item you’re reviewing. This is to ensure users will know what version you reviewed in the future when newer versions are released.

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.

Screenshot Resolutions

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)
  • 576i (720×576)
  • 480p (720×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)
  • 576i (720 x 576)
  • 480p (720×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

  • 720×480
  • 720×576

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)

Screenshots

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

Translations

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). Significant improvements that convert an unfinished translation to a fully playable translation are exempt and may be submitted under the Fully Playable category.

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.

Guidelines

  • Descriptions should be written in third person and in the English language.
  • 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 spoof and 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)
  • If you have a translation for a language not yet in our selection box, please use the contact staff form to bring it to our attention.

Utilities

Guidelines

  • 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 ‘NA’ for the game field if a game is not applicable to your utility.
  • Please choose ‘Not Applicable’ if your utility does not apply to any specific platform.
  • Choose ‘Multi-Platform’ if your utility applies specifically to multiple 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.

Non-Permitted Items

  • Game specific SRAM or savestate editors are classified as cheat utilities with the primary purpose of aiding in game cheating/enhancing which is beyond the scope of RHDN. Documentation on SRAM or savestate hacking is preferred.
  • 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.

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.

It’s beyond the scope of RHDN to carry third party dependencies, libraries, or applications that may be needed for certain software. Such software includes DOS extenders, DOSBox, WINE, Virtual PC, .NET framework, DirectX, the Visual Studio C++ runtime DLL files, Linux dependencies etc.