Project:Wiki Conventions

This is a generalized outline of how things are done here on the Dolphin Emulator Wiki. These are all "common law" concepts; no one has ever set in stone how these things work, they are simply what has grown out of the wiki over its many years of existence. And they will continue to evolve as the wiki grows, and this page will be updated periodically to reflect the changes that have occurred. These conventions are not "rules" in any sense of the word, but guidelines, instructions, and help for those new to the wiki.

Our mission is to be the best resource for accurate and up-to-date Dolphin information. Everything on the wiki is built around that goal. As such, pages, problems, ratings, and everything else on the wiki is aimed at the very latest Git release, updating and changing based on what goes on with development. Furthermore, accuracy matters, and anything that can be reproduced is favored, and subjective information is avoided.

Ratings
Ratings show the compatibility of a game for the latest master branch Git release. The compatibility guide is below. Secondary branches are not included in these ratings.

Description
A description can be anything the editor wants. But generally, they should be brief but include some basic information about what the game is and what its gameplay is like. Usually we put the name of the game fairly early in the description, and put it in  bold italics . Links to relevant articles, such as prequels or the system the game is on, are always good. Most of the time we just pull descriptions from wikipedia and tweak them a bit, removing things like references to other systems and release dates or other info covered in the infobox.

Infobox
Infoboxes use the Infobox VG template, and have a bunch of options. Most of the general information bits can be taken straight off wikipedia with minimal fuss, except for images: Wikipedia's are too small for us. Ideally all of these bits of information will be filled but it's not required. Wikipedia, GameTDB.com, GameFAQ.com, and Nintendo.com's gameguide are our primary sources for information.


 * |image = must have the thumbnail size tag based on software type. We use 300px size for GameCube, Wii and Virtual Console games, 350px size for Wii Channels screenshots and 160px size for WiiWare titles. If your image doesn't resize, only add some garbage in the end of tag such as the image name (i.e. ). Cover preference order would be: US NTSC, UK PAL, Other PAL, JP, Other.

for multiple, or use the vgrelease template to divide out regions.
 * |developer = and |publisher = Only use developers and publishers for the versions of the game that can play on Dolphin. You can either just list the information, or use


 * |series = Series are italized.


 * |release = Release dates use the vgrelease template, and should be in chronological order. We cut out any outside systems from our release date entries, as it doesn't matter to us when a game came out on the PS2, for example. Usually we can copy paste these straight off Wikipedia, but if the page uses the template, it'll have to be adapted.


 * The final code for a release date will look something like the below. Note that the last call is disconnected from the others; sometimes it has to be done to keep the list in chronological order.


 * |genre = Just get it off Wikipedia. Should list just the "genre", not "genre game" (i.e. "Action" instead of "Action game"). Should be plain text, and not contain wiki/html markup. Please use spelling and capitalization from Category:Genres.


 * |modes = Simple-player, Multiplayer, Co-op, Online. That's all the modes we use here. Modes are presented one after another, with a comma between, going through in that order. Please place the number of possible players after a mode in parenthesis. Example: Multiplayer (2).


 * |input = Displays all input combinations, shown with commas inbetween. For example: Wii Remote, Wii Remote + Nunchuk, GameCube Controller, Classic Controller. Wikipedia doesn't have this information, but gametdb.com and game reviews will have it. The Wii Zapper, Wii Wheel, and the like are accessories for controllers and not controllers themselves, so they should not be included.


 * |forumlink = The forum link directs the user to the forum thread that has the same wiki page embedded within it. It is just a straight up URL to the wiki page.

Patches
The patches area is generally absent of most game pages, but if you have links to HD texture packs or Gecko/AR codes that overcome emulation issues, make titles run at higher frame rates or allow using wider Aspect Ratios, you can add them in that section. If the game article doesn't have that section yet, feel free to create it, right before Problems section. Please note that any AR/Gecko code that doesn't fit in any of these categories are not allowed and should not be included in this wiki.

Problems
The problems area is a list of problems that affect the current Git version. If a problem is fixed in the current Git version but is still in the current Release version, it should be moved to the bottom and the title of the problem crossed out with the s template ( === like this === ), with a note in the problem on when and how it was fixed if that info is known. Once a Release occurs all existing fixed problems are purged, so it is vital to fill out when and why a problem was fixed so it can be cleared later. Each problem is listed on its own without grouping, to make it easier to deal with. Problems are generally ordered with the most severe ones first, such as crashing or hanging bugs, then going to down to the least severe. Fixed problems are at the bottom.

If the problem has a screenshot showing the issue, the screenshot should be included using Image template and must have a caption (mandatory) with a brief description of the image. Captions bigger than one line will be automatically truncated.

Anytime a revision is mentioned, it should use the revision template. It would appear like this in the editor:.

Configuration
Only non-default settings for maximum emulation accuracy should be used in the Configuration area. An ideal configuration setup lists all the settings needed for flawless emulation regardless of performance.

Each configuration entry should include a "notes" entry with a short explanation of the addressed issue(s).

Performance information, like telling users to go with EFB to Texture because it works fine, shouldn't be included. The principle is that if a more compatible isn't mentioned, then the high performance setting is assumed to work fine. If an unusual setting improves performance and does nothing else, it still shouldn't be included here, but a note may be placed elsewhere in the article (such as in a problem related to it) or in testing.

Hacks not related to compatibility should also be left off the configuration list. For example, if someone turns on the widescreen hack or 3D Vision, they know what they are getting, and we don't need to tell them not to turn it on cause it might glitch out. The exception to that is if it causes something usual, like a crash.

Please do not use this area for recommended control configurations. What buttons are assigned to what role varies based on the game, the console, the controller the player is using, and personal tastes. It is up to the user to figure that out, with a little help from our Configuring Controllers guide.

Testing
Each page's testing entry should consist of the following

Test entries using the Test Entry template with a full set of options, should be inserted after the blank entry comment. Options should include:
 * |revision= The Dolphin revision used for testing (i.e. 3.0-543, 3.0, 7342).
 * Fed through the Revision template.
 * Categories will automatically be generated to indicate testing on major revisions: 2.0, 3.0.
 * |OS= The OS (Windows, Mac OS X, Linux ), OS version (i.e. XP, 7, 10.6.8) and related CPU architecture (x86, x64, x86_64, ?) used for testing (i.e. Windows 7 x64, Linux Ubuntu 10.10 x86_64).
 * Linux users use x86_64, rather than x64, to distinguish alternate 64 bit architectures.
 * Categories will automatically be generated to indicate testing on the related OS, if it includes: Windows, Mac, Linux.
 * The Dolphin executable is presumed to align with the OS (i.e. an x86 executable isn't being used under a x64 platform).
 * Omit OS package modifiers (i.e. Home Premium, Professional, etc.). These typically have no impact on Dolphin behavior.
 * |CPU= The title of the CPU vendor (AMD, Intel, ?) and CPU (i.e. Core i7-960) used for testing (i.e. Intel Core i7-960).
 * Align with names used in: Intel Product Listing, AMD Product Listing, or other official vendor product listings.
 * Omit the text: ™, ®, Processor, or AMDs "Black"/"Black Edition" identifiers.
 * Categories will automatically be generated to indicate testing on the related CPU vendor.
 * Indicate CPU speed with a "@ #GHz" postfix listing the stock or overclocked frequency (i.e. Intel Core i7-960 @ 3.4GHz, Intel Core 2 Duo E8600 @ 3.3GHz).
 * |GPU= The title of the GPU vendor (AMD, ATI, Intel, NVIDIA) and GPU (i.e. GeForce 580) used for testing (i.e. NVIDIA GeForce 580).
 * Align with names used in: Intel Product Listing, AMD Product Listing, NVIDIA Product Listing, or other official vendor product listings.
 * Indicate SLI setups with an "x#" post-fix (i.e. NVIDIA Geforce 580 x2).
 * Use chipset vendor names (Intel, NVIDIA, AMD, ATI) rather than the board vendor names (i.e. Asus, VisionTek). This better groups similar cards.
 * The last GPU manufactured by ATI was the ATI Radeon HD 5970, newer cards should list AMD as the GPU vendor.
 * Omit the text: ™, ®.
 * Omit any overclocking on GPUs.
 * List specific cards (i.e. NVIDIA GeForce 560), not series (i.e. NVIDIA GeForce 500 Series).
 * Categories will automatically be generated to indicate testing on the related GPU vendor.
 * |result= An English description of the test results. Linking to video of results is appropriate.
 * |tester= A wiki user name or other identifier used to identify multiple tests performed.

To Do

 * Need to access and list alternate architectures (i.e. ARM?, etc.)
 * Include some of this as documentation on Test Entry

Gameplay Screenshots
The screenshots area uses the Image template. This section can have countless screenshots, and every screenshot is added by including the code.
 * In the last screenshot, you must add an ||br}} to prevent floating elements issues (i.e. )
 * Screenshots taken with Dolphin (pressing F9 while playing the game) are preferred. Screenshots should not be altered by any outside image editing program outside of format conversions (i.e. PNG -> JPG).
 * Screenshots with different Aspect Ratio may cause floating elements issues. To avoid this, any game that doesn't support widescreen [16:9] natively (without Widescreen hack) should have only fullscreen [4:3] thumbnails. If the game support both modes, all screenshots should be in widescreen format.
 * If for some reason, a screenshot with different aspect ratio must be included, the override parameter |width= must be included and adjusted in this specific screenshot until it get the same height size of the other thumbnails (refer to template documentation for more details).

Gameplay Videos
This section must be below Gameplay Screenshots and should include video links by using Template:VideoGallery. Please note that only 3 thumbnails will be shown here, even if the page has more than 3 videos, and additional videos will show up as links below the thumbnails. The template randomly chooses which 3 videos will appear as thumbnails, so the order of the videos in the gallery does not effect which will appear.

For more details, read the template documentation.

Categories
Most Categories are generated automatically from the infobox. However, please place a category for the system(s) the game is on. Here are some examples.

Images
The sidebar has an "Upload file" link, use that to upload images. So we can actually find the images, they should be appropriately named, and they should have categories for whatever they are. Below are the most commonly used image categories.


 * Cover art - (example: Wii game covers)


 * Glitches/problems pics -


 * Screenshots - (example: Wii screenshots)

Disagreements
If two editors are changing things back and forth in a disagreement, they need to STOP and head to the talk pages. The wiki is entirely open, anyone can edit it, so disagreements need to be settled with communication and compromises.