MarioWiki:Proposals

Current time: Thursday, October 24th, 18:11 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. Any user can support or oppose, but must have a strong reason for doing so (not, e.g., "I like this idea!"). 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.

A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code {{User|User name}}.

How to

Rules

1. If users have 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 the other users, who will then vote about whether or not they think the idea should be used. 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}}.
2. Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals. Users may vote for more than one option, but they may not vote for every option available.
3. Proposals end 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.
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 administrators.
   • 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 "(banned)" 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. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
8. 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.
9. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
10. 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 the {{proposal check}} tool to automate this calculation; see the template page for usage instructions and examples.
11. 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 can only be re-proposed after four weeks (at the earliest).
12. 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.
13. If the administrators deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
14. Proposals can only be rewritten or canceled by their proposer within the first six days of their creation. However, proposers can request that their proposal be canceled by an administrator at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
15. 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.
16. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
17. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
18. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal and support/oppose format

This is an example of what your proposal must look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting 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|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 14 days after the proposal was created, at 23:59 GMT, in the format: "October 24, 2024, 23:59 GMT"]

====Support====
#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]

====Oppose====

====Comments====

---

Users will now be able to vote on your proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own proposal just like the others.

To support, or oppose, just insert "#{{User|[add 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 just say "Per my 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. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

For a list of all settled talk page proposals, see MarioWiki:Proposals/TPP archive and Category:Settled talk page proposals.

Rules

1. 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. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{settled TPP}}.
2. All rules for talk page proposals are the same as mainspace proposals (see the "How to" section above), with the exceptions made by Rules 3 and 4 as follows:
3. The talk page proposal must pertain to the subject page of the talk page it is posted on.
4. When a talk page proposal passes, it should be removed from this list and included in the list under the "Unimplemented proposals" section until the proposed changes have been enacted.

List of ongoing talk page proposals

• Merge Spiked Thwomp to Thwomp (discuss) Deadline: October 26, 2024, 23:59 GMT
• Remove "(series)" identifier from titles that don't need it (discuss) Deadline: October 29, 2024, 23:59 GMT
• Rename or delete X-Ship (discuss) Deadline: October 29, 2024, 23:59 GMT
• Rename or delete Flip-Flop Folk (discuss) Deadline: October 29, 2024, 23:59 GMT
• Split Jet Pipe from the Current article (discuss) Deadline: October 29, 2024, 23:59 GMT
• Add "variant," "variant of," "related," and "comparable" parameters to the item infobox (discuss) Deadline: October 30, 2024, 23:59 GMT
• Split Impostor Bowser from Fake Bowser (discuss) Deadline: October 31, 2024, 23:59 GMT

Unimplemented proposals

Proposals

Establish a standard for long course listings in articles for characters/enemies/items/etc., Koopa con Carne (ended June 8, 2023)

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 games, Super Mario Run, or 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)

Tag sections regarding the unofficially named planets/area in Super Mario Galaxy games with "Conjecture" and "Dev data" templates, GuntherBayBeee (ended September 10, 2024)

Create MarioWiki:WikiLove and WikiLove templates, Super Mario RPG (ended September 20, 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)

Split articles for the alternate-named reskins from All Night Nippon: Super Mario Bros., Doc von Schmeltwick (ended October 3, 2024)

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

Cite relevant proposals and discussions on policy pages and guidelines, Koopa con Carne (ended October 17, 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)

Split Banana Peel from Banana, Doc von Schmeltwick (ended September 18, 2024)

Merge pages into List of Play Nintendo secret messages, Axii (ended October 4, 2024)

Create Secret exit article, EvieMaybe (ended October 15, 2024)

Merge Bunker and Professor E. Gadd's Lab / The Lab, Blinker (ended October 19, 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 and an undergraduate Minor in Art 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...) Anyways, I'm not gonna make this a big to-do, since I still can be beautiful on my own page, but I still think it looks and functions better than a schedule-looking list with inconsistent image resizings and row heights.
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. Additionally, the course map for GCN Dry Dry Desert could be cropped by half while keeping 128px parameters and not affecting the vertical positioning on center-aligned displays (like consistent-sized galleries and table rows), so that is an example of a cropping-to-save-space that does not really lose anything - and the kind that this proposal would still consider within reason to cut down by.

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.
5. OmegaRuby (talk) Per all. Better to be able to see the contents of an image without having to zoom in and view.

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)

That empty space is the alignment, though. And I have yet to see a 16x16 image become less useful for a template or table than an artificially shrunk 14x14 one - if anything, consistent image sizes make that easier because they don't cause table cells to become inconsistently sized (AKA OCD's biggest nightmare). Doc von Schmeltwick (talk) 13:50, 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)

The MKDD map sprite galleries all seem to be preset with widths=128px heights=256px anyway, meaning that the galleries wouldn't suddenly change size or look all wonky: the worst that could happen is if the original image was off-center and that being no longer reflected, but I don't recall that being the case with Dry Dry Desert's map (even then, the maps being off-center was something I tried keeping in mind when cropping them). And in my upload, the width was unchanged anyway, too. rend (talk) (edits) 13:25, October 24, 2024 (EDT)

Well I mean, I guess as long as the height's not off-center, there's no harm, no foul, as long as it doesn't screw up the course tables on the main page. I've gone ahead and reverted it and the similar ones; that's an example of a "good" crop, akin to the Diddy Kong Pilot icons or the Count Down background. Doc von Schmeltwick (talk) 13:42, 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)

The current one is intended to be case-by-case; see the discussion I had with Arend above. Doc von Schmeltwick (talk) 13:45, October 24, 2024 (EDT)

Miscellaneous

None at the moment.