MarioWiki:Proposals

Current time: Sunday, December 22nd, 05:32 GMT

Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken. Voting periods last for two weeks, but can close early or be extended (see below). Any autoconfirmed user can support or oppose, but must have a strong reason for doing so. All proposals must be approved by a majority of voters, including proposals with more than two options. For past proposals, see the proposal archive and the talk page proposal archive.

If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.

How to

If someone has an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with other users, who will then vote on whether or not they think the idea should be implemented. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.

Rules

1. Only autoconfirmed users may create or vote on proposals. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
2. Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times GMT).
   • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is two weeks later on Monday, August 15, at 23:59 GMT.
3. Users may vote for more than one option, but they may not vote for every option available.
4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
5. Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may not remove or alter the content of anyone else's votes. Voters can remove or rewrite their own vote(s) at any time, but the final decision to remove another user's vote lies solely with the wiki staff.
   • Users can also use the comments section to bring up any concerns or mistakes in regards to the proposal itself. In such cases, it's important the proposer addresses any concerns raised as soon as possible. Even if the supporting side might be winning by a wide margin, that should be no reason for such questions to be left unanswered. They may point out any missing details that might have been overlooked by the proposer, so it's a good idea as the proposer to check them frequently to achieve the most accurate outcome possible.
6. If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote. If a proposer is blocked, their vote is removed and "(blocked)" is added next to their name in the "Proposer:" line of the proposal, which runs until its deadline as normal. If the proposal passes, it falls to the supporters of the idea to enact any changes in a timely manner.
7. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
8. If one week before a proposal's initial deadline, the first place option is ahead of the second place option by eight or more votes and the first place option has at least 80% approval, then the proposal concludes early. Wiki staff may tag a proposal with "Do not close early" at any time to prevent an early close, if needed.
   • Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
9. Any proposal where none of the options have at least four votes will be extended for another week. If after three extensions, no options have at least four votes, the proposal will be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
10. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
11. If a proposal reaches its deadline and the first place option is ahead of the second place option by three or more votes, then the first place option must have over 50% approval to win. If the margin is only one or two votes, then the first place option must have at least 60% approval to win. If the required approval threshold is not met, then the proposal is extended for another week.
    • Use {{proposal check}} to automate this calculation; see the template page for usage instructions and examples.
12. Proposals can be extended a maximum of three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and cannot be re-proposed until at least four weeks after the last deadline.
13. All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
14. After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
15. If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
16. Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. However, proposers can request that their proposal be canceled by a staff member at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
17. Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting, or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
18. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and handled by the bureaucrats.
19. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
20. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal formatting

Below is an example of what your proposal must look like. If you are unsure how to set up this format, simply copy the following and paste it into the fitting section. When updating the bracketed variables with actual information, be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option must be clearly defined. Such options should also be kept to a minimum, and if something comes up in the comments, the proposal can be amended as necessary.

===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

'''Proposer''': {{User|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{User|{{subst:REVISIONUSER}}}} [make a statement indicating that you support your proposal]

====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====

====Comments ([brief proposal title])====

Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.

To vote for an option, just insert #{{User|[your username here]}} at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on another user's proposal. If you are voting on your own proposal, you can simply say "Per proposal".

Talk page proposals

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. All of the above proposal rules also apply to talk page proposals. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{settled TPP}}. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPP discuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, and the deadline. If the proposal involves a page that is not yet made, use {{fake link}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links.

List of ongoing talk page proposals

• Move Shadow (character) to Shadow (Sonic the Hedgehog) (discuss) Deadline: December 23, 2024, 23:59 GMT
• Move "Rare Ltd." to "Rareware" or "Rare" (discuss) Deadline: December 25, 2024, 23:59 GMT
• Make changes to List of Smash Taunt characters (discuss) Deadline: December 27, 2024, 23:59 GMT
• Tighten Category:Deceased characters (discuss) Deadline: December 27, 2024, 23:59 GMT
• Merge Cascading Stone, vanishing platform, and moon platform with Falling Platform (discuss) Deadline: December 28, 2024, 23:59 GMT
• Add to-do tasks on the Main Page (discuss) Deadline: January 1, 2025, 23:59 GMT
• Rename the NES Template (discuss) Deadline: January 4, 2025, 23:59 GMT
• Merge the list of show hosts in All Night Nippon: Super Mario Bros. (discuss) Deadline: January 4, 2025, 23:59 GMT

Unimplemented proposals

Proposals

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)

Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)

^ NOTE: Not yet integrated for the Super Mario Maker titles, Super Mario Run, and Super Mario Bros. Wonder.

Create new sections for gallery pages to cover "unused/pre-release/prototype/etc." graphics separate from the ones that appear in the finalized games, Doc von Schmeltwick (ended September 2, 2024)

Add film and television ratings to Template:Ratings, TheUndescribableGhost (ended October 1, 2024)

Use the classic and classic-link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)

Clarify coverage of the Super Smash Bros. series, Doc von Schmeltwick (ended October 17, 2024)

Remove all subpage and redirect links from all navigational templates, JanMisali (ended October 31, 2024)

Prioritize MESEN/NEStopia palette for NES sprites and screenshots, Doc von Schmeltwick (ended November 3, 2024)

Stop considering reused voice clips as references (usually), Waluigi Time (ended November 8, 2024)

Allow English names from closed captions, Koopa con Carne (ended November 12, 2024)

^ NOTE: A number of names coming from closed captions are listed here.

Split off the Mario Kart Tour template(s), MightyMario (ended November 24, 2024)

Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)

Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)

Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)

Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)

Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024)

Expand and rename List of characters by game to List of characters by first appearance, Hewer (ended November 20, 2024)

Determine how to handle the Tattle Log images from Paper Mario: The Thousand-Year Door (Nintendo Switch), Technetium (ended November 30, 2024)

Merge False Character and Fighting Polygon/Wireframe/Alloy/Mii Teams into List of Super Smash Bros. series bosses, Doc von Schmeltwick (ended December 2, 2024)

Writing guidelines

Encourage concise, consistent and minimalistic layouts and design for tables

Tables in game articles are a total playground. Overall, they often are as inconsistent and showy as they can be, and are often laid out in such a way that it makes them worse to read. Some are more extreme than others, like driver and track tables in Mario Kart articles, such as this and this. Those ostentatious charts look like they belong in a promotional website rather than in an encyclopedia, and do not prioritize ease of reading and data relevancy. Some are not all that exaggerated, but still look over the top, overstyled and are more spacious than they need to be. Maybe people think it is more fun to design them like that, but they look unprofessional.

That being said, these are the points I judged good ones to encourage when it comes to creating tables:

1. Uniformly use plain wikitable style for regular tables. Pages often use several styles for tables for no reason (the article for Paper Mario: Sticker Star uses four styles throughout, here, here, here and here). The wikitable style is pretty standard, so it makes sense to use it consistently.

2. Prefer to lay out table data in simple rows or columns. If the table data fits well in a "one entry per row or column" format, do it, rather than attempting to use more elaborate, arbitrary layouts. Some examples of such arbitrary layouts are this table, which is laid out like it is a grid of infoboxes, and this set of tables. If you judge it wouldn't work to make a table fit that minimal layout, try making it the closest possible to it.

3. Avoid using images of text in lieu of actual text. This is often done for the name of the subject, and it is purely for decoration purposes. Cases include Mario's name and stat names here and board names here (notice that the images in those examples are not there for mere visual reference, as they replace links; the editor likely wanted to add some flavor to the table). It makes the text less straightforward to read, in some cases duplicates it, because normal text is used alongside the image. Another common occurence is using images of stars or other icons to represent scales (such as "X out of 5 stars" scales), when you could use standard star characters (★ and ☆) instead. That does not mean to never use images instead of text, only consider whether it is worth it or not. For example, this is a good use of images replacing text because writing the names for each driver and part as text would make it harder for the reader to quickly find the desired info.

4. Avoid using more images than necessary to illustrate the subject. This is also often used for decoration and visual effect. As an example, playable character tables in sports games articles (such as this and this), where the playable characters' table entries often include both an illustration of the character and that character's in-game icon (which is just the character's head graphic), which is redundant (if I already have an illustration as visual reference for the character, an icon showing the same thing is unnecessary, and vice versa). This is a specific example but that happens with other kinds of tables, like the Mario Kart 64 track table featuring both an image of the track and the track's thumbnail. Consider whether adding extra images actually make sense or if it's just filler.

5. Avoid decoration in general, such as coloring text and cell backgrounds. Take the colored table here for example. As I said before, it is more about the visuals than the info, and it looks like some sort of promotional material. Instead, save coloring text and table cells for cases where it aids in reading data in some way.

Notice I've been proposing for these guidelines to be encouraged rather than enforced because some of them depend largely on the judgement of the editor.

Proposer: Bro Hammer (talk)
Deadline: November 6, 2024, 23:59 GMT

Support

1. Bro Hammer (talk) Per my proposal.
2. Waluigi Time (talk) The only thing this proposal is missing is encouraging tables to be horizontally aligned in accordance with web design standards, but otherwise, pretty spot on. I think a little visual flair with coloration is okay, but since this is more of a guideline to be encouraged, I'm fine voting for this as-is.
3. Nintendo101 (talk) I will say, I have used colors for some of the tables I have crafted for the mainline series articles I have worked on, but it is always with illustrative intent. When all the tables in an article look indistinguishable from one another, it can sometimes be easy to lose one's place or not easily understand how some bits of information relate to others. But otherwise, I thinks these are great guidelines and they have my support.
4. Camwoodstock (talk) Per all, especially Nintendo101; color has a time and a place, but stuff like the SM3DW character chart just kinda feels like a meld. That's not to say we should be replacing everything with the dull greys, of course, but we should probably dial it back at least a little bit. No real objections to the other parts, we should probably standardize as best we can.
5. Ninelevendo (talk) I just don’t like what’s been done to the Mario Golf: Toadstool Tour character table so whatever it takes to fix that.
6. Koopa con Carne (talk) per all
7. Lakituthequick (talk) Per proposal and per WT – I have indeed commented a few times on tables and how they should be used for tabular data (more notably for Mario Kart Wii), and this proposal will start enforcing tables to do that.
8. Cadrega86 (talk) Wholeheartedly agree with all your points. These tables are over-designed and often include superfluous information (e.g. the track table in the Mario Kart 64 page, why don't we also add staff ghost times and future appearances while we're at it?)
9. Shy Guy on Wheels (talk) Per all.
10. SolemnStormcloud (talk) Per all.
11. EvieMaybe (talk) per Camwoodstock and Waluigi Time
12. TheFlameChomp (talk) Per all.
13. MCD (talk) Per all.

Oppose

1. Tails777 (talk) I can agree that there should be a bit more consistency and organization on when and where to use certain elements for a table, but I also believe in making tables both informative and entertaining to look at. I see nothing wrong with using board logos to represent names for some of the earlier Mario Party boards that had them or using colored backgrounds on tables (something I've already supported). And while I can agree that some of the Mario Kart related tables are a bit all over the place, I believe we could take certain similar cases (tracks, boards, statistics, etc) and maybe make guidelines for each based on the topic. I get that this isn't outright enforcing the outage of these elements, but I don't really think we should actively enforce minimalist designs for tables, rather deciding what to do on a more case-by-case basis.
2. Doc von Schmeltwick (talk) - As the person who made many of the more "showy" ones, I'm kinda societally obligated to oppose this as a matter of course. I can't let my MS in CS with a few classes on advanced web design/web app programming go to waste and I find it more engaging and explanatory as to the different aspects of whatever entity is being described to have both an in-game graphic and either an artwork or a screenshot. Stat bars and star-bubble fill-in charts with color-coding are also a lot more immediately understandable than numbers alone. To quote Bowser, "Haven't you heard? A picture's worth a thousand words." (People also generally seem to approve of my tables for the Golf games...)
3. OmegaRuby (talk) Per all. Some consistency between tables in articles would be nice, but I feel the rules this proposal would put in place are a bit too much. I mean, we did recently pass a proposal allowing colorful tables again.

Comments

@Tails777 Using images as a substitute for text is very poor for accessibility and searchability with ctrl+f, though. -- Too Bad! Waluigi Time! 22:08, October 23, 2024 (EDT)

With regards to colours and visuals as is most often used as a counterpoint: I believe those are strictly speaking less important than being informative and clear, but I do love myself tables that look good as well. I can see a future proposal to establish some generic reusable table styles and colours for specific purposes. To take one back a while, Walkazo did just that for navigation templates, which, with updates, resulted in this chart to be created, still in use today. The 'Shroom for instance also features its own table styles which are pleasant to look at, and which use colours that match the page's theme. Lakituthequick 08:41, 24 October 2024 (UTC)

There are a ton of tables on here that use STRONG, EXTREME colours in attempt to look flashy but just end up being really hard to read, and I think above all else those need to go. Colour should be used very sparingly. I came across this recently looking at the MK8 Color Scheme tables for Standard Kart and Standard Bike. When you see things like Pink, White, Medium yellow, Yellow, Chartreuse, Light-gold, light-gold and especially Inklings, it's murder on the eyes... Shadow2 (talk) 04:45, October 24, 2024 (EDT)

Hmm, would it be acceptable if we kinda did what Inkipedia does with ink colors, and have a colored square show before the color terms? rend (talk) (edits) 12:31, October 24, 2024 (EDT)

@OmegaRuby the guidelines stipulate to "save coloring text and table cells for cases where it aids in reading data in some way." The colors used on those tables provide quick distinction between New Super Mario Bros. U and New Super Luigi U, so I don't think they would be impacted by this proposal. - Nintendo101 (talk) 11:32, October 24, 2024 (EDT)

New features

None at the moment.

Removals

None at the moment.

Changes

Remove all subpage and redirect links from all navigational templates

Navigational templates are one of this wiki's best features. They're a really convenient way to get around the wiki. However, one common pitfall of the templates is bloat, in particular in the form of links to subjects that do not have dedicated articles. I have previously made a proposal about this subject specifically in the context of the Super Smash Bros. series, but the problem extends to navigational templates across the entire wiki.

In principle, navigational templates should be directories of articles on the wiki. What advantage does it give the reader for Template:WWMI to have a whole section dedicated to eighteen separate links to subsections of Form Stones on top of a link to the main article itself? Why does Template:Humans link to all seven individual members of List of show hosts in All Night Nippon: Super Mario Bros. individually? Does the already crowded Template:Super Mario games really need to use precious space on a link to a two-sentence section about a theoretical game that Elon Musk claims to have failed to have pitched to Nintendo?

I propose that, across the board, all subpage and redirect links on all navigational templates should be either removed or replaced. (Red links are relatively fine, as long as the things they don't link to theoretically should be articles that just haven't been made yet. Edge cases like "Unnamed Worlds A-C Human" should be decided case-by-case in the relevant talk pages.)

Proposer: JanMisali (talk)
Deadline: October 31, 2024, 23:59 GMT

Remove the extra links from navigational templates

1. JanMisali (talk) As proposer.
2. Hewer (talk) To be honest, the main reason I'm supporting this is because I hate how cluttered Template:Super Mario games is with useless links, and this would help solve that problem. We don't need to list every single game to ever have been pitched there.
3. Camwoodstock (talk) This makes sense to us. It's much easier to just list a page link once and only once.
4. OmegaRuby (talk) Per all.
5. EvieMaybe (talk) per all
6. ThePowerPlayer (talk) When I think about it, it's an extreme stretch to e.g. list Mario Chase on the list of Super Mario games just because it was a reworked demo, or to give real estate to Mario's Castle, a concept so nebulous that it is covered by a list article in a grand total of two sentences. I feel more ambivalent about entries that are clearly their own games, such as Dokidoki Mario Chance! or Reflex Rally, but those could be split on a case-by-case basis if necessary.
7. SeanWheeler (talk) If we're not allowed to link redirects, how could our templates have redirect links?

Comments

Wait, that ANN thing is a page? I was unaware. Doc von Schmeltwick (talk) 18:51, October 17, 2024 (EDT)

A page that's linked to on nearly 900 (!!) other pages! But since those links are hidden in a big bloated alphabetical list of characters (only most of which have actual articles), it's not nearly as visible of an article as it otherwise would be. jan Misali (talk · contributions) 19:09, October 17, 2024 (EDT)

When I made that proposal not too long ago on that game, my idea was a page for each since they're all based on real people and look different despite having the same role (like the people in Mario is Missing and the NES Mario's Time Machine). Doc von Schmeltwick (talk) 19:13, October 17, 2024 (EDT)

That sounds perfectly reasonable. If/when those dedicated articles are created, then including links to them in Template:Humans would make sense. As it stands now, of course, linking to one list article several times is just messy and unhelpful. jan Misali (talk · contributions) 19:20, October 17, 2024 (EDT)

Prioritize MESEN/NEStopia palette for NES sprites and screenshots

I want to preface this by saying this proposed change will NOT be a one-person job to go back and change all instances of uploaded images. This will be more a general guideline going forward, and a thing anyone who wants to help can do without feeling like it might be unnecessary or unwanted. If this succeeds, the only immediate change needed to be considered "put into effect" is an edit to the image policy, though there will probably be a lot of quality tags for blatantly off colors.

For context of this, the NES and the Japanese FamiCom/Disk System do not have a "native" hard-coded palette. As such, different machines display different colors. However, a majority of contemporary televisions in the NTSC region (which includes both Japan and America, so where the FamiCom and the NES were initially respectively developed - sorry PAL pals) would display them with a particular muted palette. Many early computer-based emulators instead displayed an extremely bright palette with colors that tended to clash with each other, which is still present on many old images on the site. Even a few today are like that, such as FCEUX, which while great for ripping tiles, has a very odd color display.

MESEN and NEStopia are NES emulators that display that more "accurate" (for lack of better term) color. It is widely recommended by sources such as The Spriters Resource and The Cutting Room Floor as a good way to ensure color consistency. Even Nintendo themselves seems to prefer its colors, as official emulators like the Nintendo Switch Online use that type of palette. I think we should start prioritizing it going forward as a general rule so there's more consistency to the uploads color and quality.

For an example of what I am talking about, see the upload history for File:SMB Goomba Sprite.gifMedia:SMB Goomba Sprite.gif. A lot of the fixes have already been historically done; I myself worked a lot on the Famicom Grand Prix and Golf series images. Most of what's left are random images in larger platforming games as well as assorted more obscure games (looking at you, Wario's Woods), as well as newer uploads from people using older sources without realizing or caring about this issue (which is the main thing this proposal hopes to address).

(As a side note, I spent yesterday evening collecting the NEStopia colors for Super Mario Bros. 2 by playing through the whole game and applying them to the pre-existing level maps (which were ripped originally in one of those odd bright emulators), so assistance with applying them to the innumerable screenshots, sprites, and animations for the game would be greatly appreciated.)

Proposer: Doc von Schmeltwick (talk)
Deadline: November 3, 2024, 23:59 GMT

Supportopia

1. Doc von Schmeltwick (talk) - De vunderbar vald of color. CoRRECT color.
2. Nintendo101 (talk) I think utilizing a unified palette is a smart idea. It would look nice, unified, and would mitigate potential confusion as to how colors differ between subjects.
3. Camwoodstock (talk) The weirdly vibrant colors are a rare FCEUX L, as far as we're concerned, and it'd be nice to have some guidelines in place to encourage consistency.
4. SolemnStormcloud (talk) Though my Mega Man-brained self prefers the FCEUX palette in the context of that series due to MisterMike's sprite rips as well as it being the basis of Mega Man 9 and 10's palette, this isn't a Mega Man wiki, so per all.
5. ThePowerPlayer (talk) It's better to use the most accurate colors to the original output, to match the accuracy of the resolution of game screenshots.
6. LinkTheLefty (talk) TCRF standards FTW.
7. Killer Moth (talk) Per all.
8. EvieMaybe (talk) it's worth noting that CRTs and LCDs display color differently, so a direct rip of what the nes displays to an LCD might not be properly accurate. however, if both TSR and TCRF recommend it, then i have to defer to their opinion

Commesents

Here's the source on The Cutting Room Floor's preference for the MESEN/NEStopia palette, in case anyone needs it. Sorry if it's unnecessary, but I think the claim of the other websites' stances could've had links provided. SolemnStormcloud (talk) 15:47, October 20, 2024 (EDT)

Thank you, now I can actually use FCEUX without needing to back-and-forth between emulators. Maybe I can get back into U.S. Course's prize card again... Doc von Schmeltwick (talk) 16:01, October 20, 2024 (EDT)

@SolemnStormcloud - Not to gossip but FR MisterMike'd be the best NES sprite ripper ever if not for exclusively using FCEUX palette. His Zelda 1 rips were... eyebrow-raising, to say the least, which is part of what inspired me to prioritize the NEStopia palette. Doc von Schmeltwick (talk) 15:58, October 20, 2024 (EDT)

@EvieMaybe - Note the "closest to contemporary NTSC display" thing, so that'd be close-to-CRT. Doc von Schmeltwick (talk) 00:16, October 22, 2024 (EDT)

makes sense! i figured that by "contemporary" you meant an LCD or an OLED, thanks for clarifying EvieMaybe (talk) 11:12, October 22, 2024 (EDT)

Prioritize sprite/tile uploads that have their original file parameters

This proposal relates to the above, and like it, the only direct change it will bring is an addendum to the image policy.

Most sprites in games are coded so that their parameters are divisible by 8 (though ones that don't follow that exist, particularly in later machines, they are still highly rare). This is due to the same binary-based system that gave us things like "8-bit," to make a long story short it's easier for computers to understand. In sprites, this is not always filled in; for example, you might see a Boo sprite that's only 14x15px filled in rather than 16x16, but that blank space making up the remainder of that 16x16 area is still part of the sprite as it was drawn and programmed in-game. Aside from putting it at the same resolution of the other sprites, odds are the hitbox is still 16x16 pixels, so it still effects the game.

If anyone is still confused at what I'm talking about since I am primarily talking in a spriter-based mindset, see the blank areas to the right and top of DK? That is hard-coded in the game's graphic data so it's 64 pixels by 64 pixels, so it is absolutely meant to be there.

Basically, I want to reflect that as much as possible. Aside from the hitbox and resolution thing, this also makes them easier to animate and is just a neat little "visual" bit of trivia that can only be seen by accurately displaying their parameters, including the small amount of blank space some may have. I don't know if it will make it easier for the wiki's storage or not, but if it does, that's an added bonus.

Now, this is not attempting an across-the-board shift towards this; the key is feasibility for each image. An image from an NES game or a mugshot icon for a large-cast game will invariably be simple enough for this, but then there's convoluted things like Roger the Potted Ghost or Air Bag that are mishmashes of distorted sprites and models. There's no way to follow this guideline for them to the letter because of that, and those are hardly the only weird things - or even edge cases - out there. Essentially, if an image can be displayed in a manner that is true to its internal parameters while still resembling how it appears in-game, it's better that it does. If it can't, then just don't worry about it, it's a non-issue. Uploading one that does not follow it is also not an issue, but if a replacement can be uploaded that follows it, then it will have priority. If an image has an utterly ridiculous amount of blank space disproportionate to its size or the size of related images, then it can be cut down to a still 8x8-numbered smaller size if it covers them all; for instance, according to the TSR rip it is sourced from, thisMedia:DKP03 health Donkey Kong.png sprite was from a 64x64-sized tile that only had the graphic in the 16x16 section of the middle. Granted, it may just not have been cut down during development since it was canceled, or that may be artificial on Ragey's part, but the point is that there's a point where it's unnecessary, but there are better ways to deal with it than purely cutting down to the visible portion's size.

Proposer: Doc von Schmeltwick (talk)
Deadline: November 6, 2024, 23:59 GMT

Support-by-sixteen

1. Doc von Schmeltwick (talk) - I'm tiled of the confusion
2. Super Mario RPG (talk) Per proposer.
3. Hewer (talk) Doesn't hurt to be more accurate to what's official, per proposal.
4. EvieMaybe (talk) supporting this primarily for smaller 8/16 bit sprites that actually stick to tile rectangles (ie, no DKC). i'm not sure if we should do this on texture-type assets

#PnnyCrygr (talk) I'm supporting this so that we can have consistent display resolutions of sprite. Consistency always is great. Per Doc

Oppose-by-seven

1. Nintendo101 (talk) I think sometimes the display and formatting demands of our articles entails adjusting the empty space around some assets, and I do not think that is inherently a wrong thing to do. We have animated and assembled sprites to reflect their in-game appearances in ways that do not reflect how the assets are stored in the game's files in order to reflect how they actually look to the player during gameplay, and I view narrowing the empty space around an asset as the same type of revision. If folks truly want assets displayed as the raw materials they appear in the files, without any curatorial adjustments, the Spriters-Resource is available to them. (For clarity, I am not opposed to folks wanting to hang onto the empty space around an asset, but I do not think there should be a blanket rule mandating we "must" do it.)
2. Waluigi Time (talk) Per Nintendo101. As a wiki, the main reason we have sprites is to illustrate a subject, not to show the hitbox or archive a particular asset exactly as it was programed into the game. Sometimes there's a good reason to have some empty space on an image (all playable character icons being the same size is nice, for example) but other times preserving it is arbitrary or even makes them look worse when in use.
3. PnnyCrygr (talk) Per all. Best leave the spaces filled especially when theres a great deal of space around the graphic. I have seen Mega Party Games asset dumps of character sprites from my Dolphin, and boy they look small with all that big, wasted space around Mona, Crygor, Kat, etc..
4. Arend (talk) It's optimal at times, but I don't think it needs to be enforced, especially if there's loads and loads of empty space. Take File:DryDryDesertMap-MKDD.png for example. When I reuploaded the file back in 2023, I decided to crop the thing in a 128 x 128 square (keeping it divisible by 8) instead of keeping the original ratio of 128 x 256, because, quite frankly, at least half of the image's height is empty space. You restored the original ratio because that's how it was stored in the data, hereby recreating the bulk of unnecessary empty space again.

Comments-by-64

@Nintendo101 - TSR doesn't always have that either, though, and I don't think it's really our place to wholesale rely on other websites for this sort of thing. Besides, this also looks better and makes things easier when using the multiframe and multiple-image templates since the boxes are at a consistent size and both match each other and don't need to have their sizes checked individually when adding the template in. Also, I'd like you to read the last paragraph of the proposal and tell me where that "must" came from. Doc von Schmeltwick (talk) 17:30, October 23, 2024 (EDT)

Again, if folks choose to do that for individual assets or articles, that's fine. But I would not support a blanket rule. Speaking for myself, I have put a lot of careful thought into how sprites and models are displayed on things like Template:Icon or the tables for the mainline games. The removal or presence of space around an asset is largely deliberate, and is part of the curatorial craft of presenting information. I know I would find contributing to the site a lot less enjoyable if I had to undo much of that work for something like this. - Nintendo101 (talk) 17:37, October 23, 2024 (EDT)

Again, where are you getting the idea of a "blanket rule?" The proposal says that this is done case-by-case, doesn't need enforced, and involves no punitive measures. It's more of a general suggestion. Doc von Schmeltwick (talk) 17:41, October 23, 2024 (EDT)

I guess I just don't understand why this proposal was enacted, or how it would be substantively realized if it passes, if it does not necessitate any actual changes. From your perspective, how would things be different if the proposal were to pass? What would actually happen that is different from how things are handled now? If I uploaded a sprite that was narrowed to the visible parts of a sprite with deliberate intent, and it was replaced with a version that retained the empty space around it with this proposal cited, would I have the freedom to change it back? Because if that is the case, then it does not really seem like this proposal is very necessary unless we had a rule that insists we "must" crop to content. To the best of my knowledge, a rule like that isn't on the books. - Nintendo101 (talk) 17:50, October 23, 2024 (EDT)

Again, they would be prioritized so they'd be reverted to the non-narrowed version, but this isn't a call to enact a sweeping change. This is more to clarify if that should be done. As a sprite-ripper, I think it absolutely should. Doc von Schmeltwick (talk) 18:02, October 23, 2024 (EDT)

So for clarification, I would not have the freedom to change it back if this proposal were to pass? - Nintendo101 (talk) 18:04, October 23, 2024 (EDT)

Why would you want to? What benefit does 14x14 have over 16x16? Doc von Schmeltwick (talk) 01:03, October 24, 2024 (EDT)

Because sometimes retaining the empty space around a sprite knocks it out of alignment with other assets when displayed in a table, gallery, or template (or renders it completely unusable for something like a template), and because the visual material we have is meant to be illustrative it seems needless to retain that when there is nothing visual informing the reader. I value the freedom to exercise discretion, and I suspect I am not alone in that. - Nintendo101 (talk) 13:04, October 24, 2024 (EDT)

@PnnyCrygr - "If an image has an utterly ridiculous amount of blank space disproportionate to its size or the size of related images, then it can be cut down to a still 8x8-numbered smaller size if it covers them all" Doc von Schmeltwick (talk) 18:32, October 23, 2024 (EDT)

@Arend - The issue there is that for the gallery to work right the images - all the same ratio in the data - need to be at the same size. If they were all different anyway (like MK64's maps), that edit wouldn't have been an issue, but since they are all equivalent in size, the gallery ought to reflect that. Doc von Schmeltwick (talk) 12:20, October 24, 2024 (EDT)

Abstaining for now, but we wonder if there should be like, an option for a more case-by-case approach; NES and SNES games get the full aspect ratios, but N64 onwards are fine to crop. Or, alternatively, NES, SNES, and N64 get the aspect ratios, and the GameCube is the cutoff point. ~Camwoodstock (talk) 13:16, October 24, 2024 (EDT)

Miscellaneous

None at the moment.