User talk:Wildgoosespeeder/QualityRequestTypes/sandbox
This page is for addressing specific concerns with proposing new tags and modifying existing tags. These are current concerns that have yet to see a resolution be reached. --Wildgoosespeeder (talk) (Stats - Contribs) 03:25, 12 April 2016 (EDT)
Categories[edit]
- Category:Images to be reuploaded with higher quality
- Category:Images that need improvement
- Category:Images that need a game rip
- Category:PNG requested
Comments[edit]
There have been concerns that these two additional categories may not be enough and current crowding will just be shifted over to the new categories. The categories should be split even further into one for screenshots, sprites, etc..
- Now Category:Images that need a game rip has been added. --Wildgoosespeeder (talk) (Stats - Contribs) 00:31, 14 April 2016 (EDT)
Implementation[edit]
Someone suggested that if the proposal passes, ~70,000 files need to be examined. This is false. Only images with {{image-quality}}, which is around ~1,000 images at this current time, will be examined and have their tags changed. The only thing the proposal adds/removes/changes is giving more tag options and reducing debates surrounding the {{image-quality}} tag. The way we go about finding images to tag will remain the same (casual regular everyday browsing of MarioWiki).
Definitions/Restrictions[edit]
{{image-quality}} doesn't have a shared understanding on its proper use. That is why additional tags are being created and new rules are being suggested as to reduce subjectiveness surrounding its use.
Template:Image-quality[edit]
- Bad cropping
- Blurriness
- Too small
- Used a camera to take a screenshot of a game
Comments[edit]
Well for some of your points, that depends. What if the said screenshot is the only image source of said game? I guess you could say vaporware or pre-release builds are the exception to these.
Xiahou Ba(the Nasty Warrior) 18:19, 12 April 2016 (EDT)
- Right. I have that established in yet another future proposal. User:Wildgoosespeeder/sandbox. --Wildgoosespeeder (talk) (Stats - Contribs) 19:50, 12 April 2016 (EDT)
- I got a weird idea. Would a special tag for beta images needing a better image be acceptable? --Wildgoosespeeder (talk) (Stats - Contribs) 23:06, 12 April 2016 (EDT)
I'll put examples of each. I tried to order it by most awful to least awful-looking
- NOTE: These images were scanned April 12, 2016. Their quality may have improved since then. Check their file histories for further details.
- Cyrrus.jpgToo small (screenshot)
If you like these, then you should reupload these as separate images just for the page. Don't upload them until you create the page, though!
It's me, Mario! (Talk / Stalk) 22:58, 12 April 2016 (EDT)
- File:SMG BobOmb Dispenser.png Why is this even an image? It looks like it was taken from File:Bob-omb Dispenser.png as a source, and the source is of terrible quality. I have been meaning to redo the bunch of Battlerock Galaxy images anyways, but there are a lot to do, especially the gallery section of that page. I don't know if that many images are necessary.
- Anyways, the rest of the image are good examples. --Wildgoosespeeder (talk) (Stats - Contribs) 23:06, 12 April 2016 (EDT)
- Didn't realize that the DISPENSER image is a massive derp. Try File:Kamella SMG.png. Bonus: you tagged that one. :P Also, I agree, Battlerock Galaxy has WAY too many images and I also think the gallery is a bit excessive.
It's me, Mario! (Talk / Stalk) 00:21, 13 April 2016 (EDT)
- Didn't realize that the DISPENSER image is a massive derp. Try File:Kamella SMG.png. Bonus: you tagged that one. :P Also, I agree, Battlerock Galaxy has WAY too many images and I also think the gallery is a bit excessive.
I also think you should put emulator glitches as a parameter, but I don't know how often that pops up.
Xiahou Ba(the Nasty Warrior) 19:08, 13 April 2016 (EDT)
- I can think of five off the top of my head: --Wildgoosespeeder (talk) (Stats - Contribs) 19:23, 13 April 2016 (EDT)
- NOTE: These images were scanned April 13, 2016. Their quality may have improved since then. Check their file histories for further details.
- Super Mario Sunshine (formerly a screenshot containing a glitch)
- Super Mario Galaxy (Cosmic Mario's shell isn't supposed to look like that)
- N64 games in general (bad filtering, see here how to fix)
- Super Mario 64 (HUD looks ugly, see here for correct HUD look)
- Megadardery (talk) says the fog is missing
- Yeah, all are pretty bad as well as well misleading. You're going to consider making a separate image-quality template for that as well?
- I think the easier solution is to just amend {{tweak}} section of this proposal. --Wildgoosespeeder (talk) (Stats - Contribs) 19:36, 13 April 2016 (EDT)
- Yeah, all are pretty bad as well as well misleading. You're going to consider making a separate image-quality template for that as well?
Template:Convert to PNG[edit]
No questions asked images should be PNG:
- {{game-screenshot}}
- {{game-sprite}}
- {{game-3Drender}}
Iffy if JPEG or PNG:
- {{artwork}}
- {{character-artwork}}
Comments[edit]
It really depends on the screenshot. As you said on the proposal, shader-based games with relatively high-res screenshots generally don't need color preservation. I get sprite-based low-res games like GBA games, but I think we can tolerate .jpg for stuff like Super Mario Galaxy or even Paper Mario.
Also, .jpg in art and character-artwork is acceptable. The only reason you'd be using .png is for preserving transparency. You could also upload art as .png while expecting a better-quality work to come later such as :File:BabyLuigibeinghimself.PNG, but that's not guaranteed.
It's me, Mario! (Talk / Stalk) 21:48, 12 April 2016 (EDT)
- If we are going to make exceptions with JPEG being tolerable with screenshots, how are we going to educate people how to get good quality JPEG screenshots for MarioWiki? I'm very stupid with that format. PNG is just so much easier to work with. Microsoft Paint's JPEG saving is terrible. That I know for sure. The only exceptions I am willing to throw with JPEG for sure are 3DS and Wii U screenshots because the 3DS upload to Miiverse looks quite nice. Wii U, I don't advise images be uploaded to Miiverse because those images are 800x450. The Wii U is capable of uploading 1280x720 screenshots directly to any website willing to host the images, including MarioWiki because the Wii U's built-in web browser has special upload dialog box handlers. --Wildgoosespeeder (talk) (Stats - Contribs) 22:04, 12 April 2016 (EDT)
- Not sure how GIMP handles them, but I've uploaded .jpg images in another wiki by putting the .png in GIMP and exporting as .jpg with default settings, and it doesn't seem trashy to me. I still think you should discuss 3DS homebrew stuff. Speaking of which, you probably need a disclaimer on ISOs and homebrew just to be safe.
It's me, Mario! (Talk / Stalk) 22:21, 12 April 2016 (EDT)
- The entirety of emulation needs a disclaimer. :P Emulation is legal because it falls under the lines of reverse engineering being fair use. Distribution of the games for emulation is illegal as well as downloading them, even if you own authentic copies of those games. Obtaining a back-up copy of the games you own authentic copies of yourself is legal. Homebrewing is something that Nintendo does not like at all but it isn't illegal, but it does void any warranties. --Wildgoosespeeder (talk) (Stats - Contribs) 22:29, 12 April 2016 (EDT)
- Not sure how GIMP handles them, but I've uploaded .jpg images in another wiki by putting the .png in GIMP and exporting as .jpg with default settings, and it doesn't seem trashy to me. I still think you should discuss 3DS homebrew stuff. Speaking of which, you probably need a disclaimer on ISOs and homebrew just to be safe.
I feel like some .gifs don't necessarily need to be in .png format, such as the grayscale Super Mario Land sprites. I'd maybe take issue with more complex sprites like the Paper Mario ones, as .gifs are rendered worse as thumbnails, but is there any difference of the rendering .png/.gif of the lower-res sprites such as the aforementioned SML sprites?
Xiahou Ba(the Nasty Warrior) 23:00, 13 April 2016 (EDT)
- To get technical, the GIF format in general suffers from having a limited 8-bit color pallet (256 colors) with limited transparency (value of 0 or 1) and has dated compression algorithms. PNG has a 24-bit color pallet (16,777,216 colors) with less limiting transparency (values ranging from 0 to 255) and higher compression in almost all cases compared to GIF counterparts (a few edge cases would put GIF superior). --Wildgoosespeeder (talk) (Stats - Contribs) 23:32, 13 April 2016 (EDT)
Template:Tweak[edit]
- Transparency requested
- Incorrect aspect ratio
- Images with artifacting present
- Removal of watermarks
- A proper resampling is needed
- Slightly inaccurate colors
- Screenshots featuring emulator glitches
Comments[edit]
What's a "resampling"? Is it retaking a screenshot to fit the appropriate resolution? Also, include .jpg screenshots on sprite-based games.
It's me, Mario! (Talk / Stalk) 21:44, 12 April 2016 (EDT)
- Resampling when it comes to saving in an imaging format is regenerating something to be in a raw format (such as a BMP) and then converting that raw image into a different file format for compression. In the case of game screenshots, it would be the regular playing of a game live and then pressing the screenshot button. The expected output format should be BMP or PNG. If we want a JPEG from that, there would be no artifacting with the input image. The output image would be untainted. The only artifacting would be from the JPEG algorithm itself with the output JPEG format. Essentially we want a clean input file to generate a good output JPEG file. --Wildgoosespeeder (talk) (Stats - Contribs) 22:15, 12 April 2016 (EDT)
Template:Tweak-gamerip[edit]
- Looking through game sprites via hacking or hex editing would provide the best version of an image compared to screenshot cropping.
- A custom 3D render would be of higher quality than a cropped screenshot render.
Comments[edit]
I don't 100% get what the latter is saying. You say we should get a model from the game, slap it right in 3DS Max/Maya/Blender and just take a picture there?
It's me, Mario! (Talk / Stalk) 14:17, 15 April 2016 (EDT)
- I guess. I don't have much experience in game ripping, more specifically, 3D rendering of the ripped 3D model data. --Wildgoosespeeder (talk) (Stats - Contribs) 14:25, 15 April 2016 (EDT)
- The results of ripping these properly is something like this: File:Mario and Luigi (render) - Mario Tennis Ultra Smash.png. Except the lighting is manually added because the lighting from the game, for the most part, simply isn't present. Also, models are in that strange pose just for the modelers' convenience. When you're trying to animate, for instance, you're defining weight values for these little points (vertices) on the models for the model's bones (joints in the model). You do NOT want the arms to be by the sides or the fists close or it will be unnecessarily difficult. On the other hand, the reason the image, File:MLNPC.png, has fists is that Super Mario Galaxy doesn't animate fingers; they swap around many different meshes for the hands. Anyhow, despite their T-shaped pose, you can move and even animate these models since the rig (what we call defining those weight values) is ripped as well, but an image doesn't do them justice. However, unless we get animation files, getting the models into a specific pose may be tricky.
It's me, Mario! (Talk / Stalk) 14:38, 15 April 2016 (EDT)
- The results of ripping these properly is something like this: File:Mario and Luigi (render) - Mario Tennis Ultra Smash.png. Except the lighting is manually added because the lighting from the game, for the most part, simply isn't present. Also, models are in that strange pose just for the modelers' convenience. When you're trying to animate, for instance, you're defining weight values for these little points (vertices) on the models for the model's bones (joints in the model). You do NOT want the arms to be by the sides or the fists close or it will be unnecessarily difficult. On the other hand, the reason the image, File:MLNPC.png, has fists is that Super Mario Galaxy doesn't animate fingers; they swap around many different meshes for the hands. Anyhow, despite their T-shaped pose, you can move and even animate these models since the rig (what we call defining those weight values) is ripped as well, but an image doesn't do them justice. However, unless we get animation files, getting the models into a specific pose may be tricky.
Target Audience[edit]
Only a few users actively contribute to fixing bad quality images. What is the ratio of writers vs. uploaders?
- Users can choose to:
- Take on one of the two roles, or
- Handle both roles as a writer and an uploader in varying degrees of effort.
- Amount of effort for a writer or uploader can make is determined by:
- Time investment to perform such a task
- Content sources that are accessible digitally (like the internet, or a downloaded game) or in physical form
- The ability to successfully capture what said content it is about
- As a general starting point, video games (not non-video game media based on video games) will be covered as it covers most of the overall images uploaded in the wiki in order to understand:
- How those two roles perform their tasks, and
- How it influences and explains the ratio of writers vs. uploaders
- Role descriptions
- Writers: Describe the information of the story, lore, game mechanics, actions, description of the subject's looks/imagery, anything that's not uploading images.
- Uploaders: Find images that capture what the subject is about.
- Sources
- Writers: Playing the game (from a console, or from an emulator), YouTube videos, or walkthroughs
- Uploaders: Taking screenshots from a game (with a capture device, or from an emulator), Miiverse (people playing Wii U/3DS games can upload screenshots on their accounts), screenshots from video game websites, game sprite image repositories, or off-hand sources (such as screenshoting a lossy-compressed YouTube video frame)
- Difficulty
- Writers: 1) Quality of gathering info. 2) Written info dependent on the quality of writing, grammar, etc from gathered info.
- Uploaders: Utilizing info to find the location of the content to be uploaded as an image.
- Margin of error
- Writers: Ways for incorrect info: 1) Misremembering info details, 2) misinterpreting given info, and 3) deliberate incorrect info.
- Uploaders: Ways for incorrect images: 1) Uploading the image that isn't the subject, and 2) deliberate incorrect image upload.
- Getting the highest quality content possible
- Writers:
- The highest possible quality of writing is limited by it's writing and analyzing skills.
- Writers can get all the info from the video game itself (from a console or from an emulator) by playing the game normally, with exceptions:
- Technical info such as enemy RPG statistics that can only be found through a strategy guide or hacking game files.
- Games with different versions and/or different languages with differing content, like story localization changes or additional content.
- If writers never played a particular video game before, they can use second-hand sources such as YouTube videos and walkthroughs.
- Writers using second-hand info should ask for verification from someone who has played that particular video game since second-hand info may not be accurate.
- Uploaders:
- Uploaders must get the highest quality of game screenshots through emulation, homebrew, or a screen capture device.
- Getting a game screenshot from a particular location through emulators requires playing through the game with accompanied skills to do so.
- Uploaders playing a video game from an emulator can use:
- Save states as a safety net to lower difficulty by replaying a difficult part without loss of time, or moments in the game that go by too fast to screenshot it.
- Download game saves from the internet in order to access to a particular part of the game to screenshot faster.
- Uploaders uploading should be aware that game screenshots captured through emulation may have emulation render errors.
- Screenshoting newer games by emulation (like 3DS and Wii U titles) is impossible due to:
- Lack of emulator programs.
- Emulators are not developed enough to take screenshots.
- Newer game console emulators like the Nintendo GameCube, or Nintendo Wii may require more powerful computer hardware due to increasing complexity of successfully emulating software in comparison to older game console emulators.
- A suggested alternative way is to retrieve screenshots posted from Miiverse (screenshots uploaded from 3DS and Wii U); however, I have no knowledge on how accurate the screen captures are uploaded from a 3DS or Wii U.
- For uploading game sprites, they can be found from image repositories, after making the background transparent, and cropping to only the game sprite.
- If the desired game sprite is not found, if the desired game sprite and game background is not too complicated to deal with: Screenshot that particular part from an emulator, separate the background from the sprite by removing the background, and make the background transparent.
- If the desired game sprite is too complex to successfully retrieve:
- Ask someone who specializes in retrieving and compiling sprites to request a particular game sprite piece.
- Learn specialized skills of retrieving and compiling sprites from a video game through emulation.
That was a lot of thinking and writing out! Took around 6 hours to write it out! I'm not sure which one is easier to do, since it's dependent on well you do in one of the two. Although, I would say that the potential for users to be image uploaders by uploading the best possible game screenshots through the use of emulators is suggested to be stunted because of the stigma crafted by publishers in that "emulating equals piracy" when emulators are a legal tool to be used. --
RAP... 04:00, 16 April 2016 (EDT)
- Very insightful stuff there RAP (talk). For the YouTube video screenshot as a source, my WIP has become more lenient with that source, although I advise these images shouldn't be forgotten and should be tagged or have a more appropriate screenshot be taken, whichever is the least time-consuming to achieve a good quality screenshot.
- As for 3DS screenshots, Miiverse is acceptable but those screenshots are JPEG. I think the JPEGs are on the higher quality end of JPEG quality instead the lower quality end like this exaggeration of File:CoinRush.png. However, Bazooka Mario (talk) has brought 3DS homebrew to my attention and is capable of taking raw screenshots and converting those to lossless PNGs. There is a catch. Nintendo regularly patches the 3DS firmware. I can't take PNG screenshots with my 3DS currently because I am running my 3DS on the latest firmware, which block current homebrewing methods. This method has yet to be verified as a viable method of screenshot taking. User:Wildgoosespeeder/sandbox#3DS --Wildgoosespeeder (talk) (Stats - Contribs) 18:10, 18 April 2016 (EDT)
- Just to let you know, I've just gotten a message from Kuribo64, just today: "[browserhax] is a really old version of webkit, expect browserhax to return someday." Browserhax lets you install homebrew using an exploit in the Internet browser. Nintendo did patch it, but I'm going to try to stop updating my 3DS from now on so I could use a possible newer version of browserhax. In the meantime, there are indeed other methods to run homebrew, but they're quite limited, especially on the latest firmware.
- Also, RAP, great summary. I do believe that you should include fluidity between the two. I myself interchange between a writer and an uploader. I'd also like to say that not only there is bad publicity on emulators, but those things require decently powerful computers to take images efficiently. You don't necessarily need powerful computers, but it could get tedious and tiring to slog through 3 FPS gameplay to get the screenshot you want. This is how we uploaded all of our Mario Party screenshots, and we even broken button mashing records that way. :P
It's me, Mario! (Talk / Stalk) 20:59, 18 April 2016 (EDT)
- Also, RAP, great summary. I do believe that you should include fluidity between the two. I myself interchange between a writer and an uploader. I'd also like to say that not only there is bad publicity on emulators, but those things require decently powerful computers to take images efficiently. You don't necessarily need powerful computers, but it could get tedious and tiring to slog through 3 FPS gameplay to get the screenshot you want. This is how we uploaded all of our Mario Party screenshots, and we even broken button mashing records that way. :P
- "Fluidity"
- I'm not sure what additional bulletpoints I would write about the fluidity between a writer and an uploader.
- The purpose of creating the bulletpoint list is listing down what tasks and obstacles both of those roles face in the wiki from my knowledge of observing and taking those respective roles.
- I can make an acknowledgement that both users can take both roles instead of just strictly one in varying degrees.
- I don't think I want to pigeonhole users to a particular role and ignore or deny them from taking on the other role.
- For instance, I lean heavily on image uploading over writing articles (because for me, I sometimes have trouble outputting my thoughts into words for subjects that I have to tackle in a variety of angles (such as not taking account that emulation for later consoles may require more powerful computers!) and type it out in a accessible, accurate, and compact matter.
- If you take account of this comment, and read the bulletpoint list, you can safely infer that I have a history of uploading a ton of game screenshots and games sprite images in the wiki in general; and if you check my contributions and took a quick skim of my work, you can infer that I have minor contributions of writing (most of it gnomework, and maintenance but I don't mind that), but has a notable foothold in writing articles for Mario Party series mini-games, particularly 1-3.
- However, thinking about the role of a writer, does it extend to the amount of wiki code knowledge? (This is one of those angles that I haven't considered covering and defining!). For it to be the highest quality content, information like statistics would be more suited for wiki tables for neatness and readability. I could probably add that (or maybe have it's own separate category due to technical details of using wiki coding). May need extensive thinking or help. Maybe another time?
- Another barrier: Emulating newer game consoles = more powerful computer hardware
- Oh yeah, powerful computers. That's another barrier...I forgot about that.
- I blocked that memory when I failed to play an emulated GameCube (the latest is earlier in 2016) because it's slow and unproductive for my tastes.
- I'll edit the bulletpoint list accordingly.
- Oh, when you played those GameCube Mario Party mini-games, I seriously hope you changed the characters at random, it would stupidly odd to have like 50 Mario Party 4 images of Mario, Luigi, Donkey Kong, and Yoshi playing those mini-games, and not randomly mixed those characters. >;o
- --
RAP... 23:02, 18 April 2016 (EDT)
- for those gamecube titles crap, we could reupload it with different characters if you really want us to. i'd be more comfortable doing all of that myself than someone else doing this because "lol characters" crap. our computer's graphic card can handle it pretty good, so we can take a stab at it.
Xiahou Ba(the Nasty Warrior) 23:56, 18 April 2016 (EDT)
- for those gamecube titles crap, we could reupload it with different characters if you really want us to. i'd be more comfortable doing all of that myself than someone else doing this because "lol characters" crap. our computer's graphic card can handle it pretty good, so we can take a stab at it.
- @Baby Luigi (talk): The reason I suggested to have randomized characters in those Mario Party series mini-games is to continue the positive reinforcement that there are multiple playable characters players can choose, whether it's their favorite, or just 1-button confirm Mario. :P While I admit it sounds like a nitpick, tiny but subtle stuff like that counts, tis fair representation I say. --
RAP... 01:16, 19 April 2016 (EDT)
- that's fair enough i guess. though, fun fact, not even ndcube/hudson follows this: I think in Mario Party 9, 90% of the game previews used only Mario, Luigi, Peach, and Yoshi if I recall correctly, or, if it's a another certain amount of characters. I'm not saying that we should follow them and do screenshots exactly like they do, of course. but i agree that some variety is nice, and we can please all viewers whose favorite character should be represented at least once.
Xiahou Ba(the Nasty Warrior) 02:42, 19 April 2016 (EDT)
- that's fair enough i guess. though, fun fact, not even ndcube/hudson follows this: I think in Mario Party 9, 90% of the game previews used only Mario, Luigi, Peach, and Yoshi if I recall correctly, or, if it's a another certain amount of characters. I'm not saying that we should follow them and do screenshots exactly like they do, of course. but i agree that some variety is nice, and we can please all viewers whose favorite character should be represented at least once.
- @Baby Luigi (talk): The reason I suggested to have randomized characters in those Mario Party series mini-games is to continue the positive reinforcement that there are multiple playable characters players can choose, whether it's their favorite, or just 1-button confirm Mario. :P While I admit it sounds like a nitpick, tiny but subtle stuff like that counts, tis fair representation I say. --
- Why Mario, Luigi, Peach, and Yoshi in most game previews of Mario Party 9? – @Baby Luigi (talk):
- It's probably a PR thing. Mario, Luigi, Peach, and Yoshi are the most recognizable Mario characters they can pick from.
- Bowser has the same level of recognition as those 4, but cannot be picked as a playable character.
- The purpose of those characters being picked is to maximize exposure through reinforcement and reach:
- It's probably a PR thing. Mario, Luigi, Peach, and Yoshi are the most recognizable Mario characters they can pick from.
- Fans who engage with the Mario series casually (not like MarioWiki users per say, they would've known more than just those 4), and
- Non-fans who never engaged themselves with the material, but had some surface knowledge from advertisement imagery, or noticing other people engaging with Mario content through discussion, playing Mario video games, or interacting with merchandise (like shirts or toys).
- The way PR has handled for Mario Party 9 could be a sub-section as marketing.
- Problem is that it's more subtle, non-gameplay, and usually under our noses when just wanting to engage with game mechanics and lore in the wiki. :p
- For example, I wrote a sub-section dedicated to marketing for Donkey Kong Country Returns (click here for my last revision dedicated to that section).
- There's a revision note I wrote that says: "Wow, this section remained untouched. Adding the sectionstub back; doesn't cover GameStop retailer bonuses. I have a feeling there's more than that." Apparently someone did not catch that note or felt like the sub-section is fulfilled enough and removed Template:stub. I know there's more than that!
- Or...there's a piece of marketing info that's just stuffed to the trivia section. Wow.
- @Bazooka Mario (talk): Why those four?! Is it because of their AI making them act more cunning and aggressive? :p
--
RAP... 04:13, 20 April 2016 (EDT)
- No, they're just funny to play against. We don't hate them.
Xiahou Ba(the Nasty Warrior) 21:21, 20 April 2016 (EDT)
- Yeah, but we varied it a bit more in Mario Party 8, so would you be okay with that if we did it like this? Or do you want full-on variety?
It's me, Mario! (Talk / Stalk) 21:24, 20 April 2016 (EDT)
- Yeah, but we varied it a bit more in Mario Party 8, so would you be okay with that if we did it like this? Or do you want full-on variety?
Downloading saves to shorten iteration time replacing images[edit]
RAP (talk) mentions downloading saves to shortcut replacing images. Should my screenshot guide include where to find such saves? Zophar's Domain has a lot of saves for NES (if supported or a savestate), SNES, N64, GB (if supported or a savestate), GBC, and GBA (I think) using "native saves" (battery back-up or flash memory, varies by cartridge). GameFAQs has GBA GameShark saves, DS Action Replay saves, *.gci (GameCube memory card save files) and Wii saves that can be imported to real hardware using GCMM (GCN only) or through Dolphin (both save types). For the GameShark and Action Replay saves, this requires you to import through the menu of the emulator because these saves are not native. --Wildgoosespeeder (talk) (Stats - Contribs) 19:07, 24 April 2016 (EDT)
- As long as it gets the job done faster on getting better quality screenshots, yeah. Just make sure that the instructions of using saves (created from emulators and from actual hardware) are simple, concise, and tries to cover every angle; like try to idiot-proof it as much as possible, such as my PNG Monster guide, in which for example, if there are unforeseen scenarios that I didn't cover due to not enough experience using this seemingly simple program or the actuality or perception that it would alter your computer without using virtual sandboxing when testing out extreme possibilities of stupidity, I blanket cover it with a note on backing up your PNG files before compression.
- If I took your place and wrote instructions on handling saves (either emulated replicate like native saves or as save states, and native saves copied from actual hardware) for your screenshot guide, I would have to cover questions like "If I use a hardware native save file, and I came across a point where I save in-game in an emulator either by prompt or automatically (that's not a save state), does it alter the actual file?", or "Where are the save states and emulated native saves stored?", and write them out either by describing the process of how these emulators function and execute when dealing with save files, put it in a FAQ format, or just blanket cover backup your stuff. --
RAP... 02:44, 8 May 2016 (EDT)
- If I took your place and wrote instructions on handling saves (either emulated replicate like native saves or as save states, and native saves copied from actual hardware) for your screenshot guide, I would have to cover questions like "If I use a hardware native save file, and I came across a point where I save in-game in an emulator either by prompt or automatically (that's not a save state), does it alter the actual file?", or "Where are the save states and emulated native saves stored?", and write them out either by describing the process of how these emulators function and execute when dealing with save files, put it in a FAQ format, or just blanket cover backup your stuff. --
- Section added. User:Wildgoosespeeder/sandbox --Wildgoosespeeder (talk) (Stats - Contribs) 14:49, 11 May 2016 (EDT)
Personal Lists vs. Tagging[edit]
Personal lists as well as tagging both have their pros and cons. Personal lists are great for people who are dedicated to supplying images and are aware of on-going MarioWiki projects but risks being too obscure for regular users. Tagging is more up front about requesting a better replacement image but overtagging is a concern and users should just upload anyways.
If you interested reading this sub-topic lurkers, Wildgoosespeeder (talk) and I discussed this topic on my talk page (click here if the talk page was archived) about my perspective on my experiences and tasks in working on my personal list of images that need to be tackled.
In regards to how my project progress goes, most of the reports and activity came from the MarioWiki forums (I will still refer to it to this day). Users that aid my project would usually discuss and debate on anything that has to do with images. Doing the percentage each week was tedious, as I had to manually total up all (this post is a good example) the crossed out images from all the sections I covered in the project. It got to the point that Megadardery (talk) aided me in manual counting to rack up the percentage. I abandoned the project because of focus on college education, and felt that it wasn't getting enough help, not realizing this project covers a niche that not all users may have time or skill (on getting highest quality images) to tackle it (which sucks thinking about it). 3 years later and then I pop up on these kinds of stuff after checking MarioWiki each month passively to see how it's going. --
RAP... 20:55, 18 April 2016 (EDT)
Screenshots[edit]
How do we define good screenshots? Internal native resolution (User:Wildgoosespeeder/sandbox)? What actually displays on an SDTV or HDTV? Should oversized screenshot images be discouraged? Encouraged?
I think the best screenshots show the best impression of the game. Internal native resolution is ideal, I believe. That means the screenshot should be at the closest size to the game (File:Ground Pound Down.png is at a close resolution to native, File:MarioMechs.png is probably oversized. BUT, if oversized screenshots exist, we should not be going backward to replace them. File size may not be a concern, but it's still best to save at internal native resolution to prevent bloating. This opinion may rub a bit against my sister, where File:Mario Party 5 Bill Blasters.png in this image, I attempted to revert to a closer native resolution, but she just undid it because she thinks the higher resolution is worthwhile.
It's me, Mario! (Talk / Stalk) 22:16, 12 April 2016 (EDT)
- My experiences with GCN and Wii screenshots have been very tricky. No other game system have I had issues with generating 1x native screenshots through emulation or some other method. I know my uploads are not native at all. The developers themselves of Dolphin Emulator have stated the screenshot code is looking at the wrong "buffer" when it is saving a frame as a PNG. Other emulators don't have this issue or there are very easy ways to get this corrected. --Wildgoosespeeder (talk) (Stats - Contribs) 22:21, 12 April 2016 (EDT)
- Don't worry about getting it exactly at native. We're not as stringent as SmashWiki (who's adamant about resolution sizes) when it comes to resolution, so don't let these issues get in the way. If you can't get it exactly at native, but you can get the aspect ratio correct, just don't bother.
It's me, Mario! (Talk / Stalk) 23:01, 12 April 2016 (EDT)
- In my opinion, I do personally like the looks of higher resolution screenshots. My opinion of this is why not? If we can capture gameplay with better clarity via emulation and therefore illustrates subjects better, then I like it. In my opinion, it's not that much different than rendering game-ripped models at higher resolutions than the game they originally appeared in.
Xiahou Ba(the Nasty Warrior) 23:03, 13 April 2016 (EDT)
- The issue of oversized emulator images vs. real hardware render is usually due to how true 3D graphics render vs. sprite-based renders. Rendering 3D images in general to look nice in a specified resolution does a lot of behind-the-scenes math that can round out rough edges before converting that scene into what is called a raster graphic, similar to how vector graphics work but in three dimensions instead of two. If you were to do the same to a sprite-based render, which is just a dynamic raster graphic, you would be duplicating pixels, increasing redundancy in the image. In that case, you are better off with 1x native because we can resize that on-the-fly to be any multiple native resolution without affecting the source image. --Wildgoosespeeder (talk) (Stats - Contribs) 23:46, 13 April 2016 (EDT)
- So, the HUD could be bloated? HUDs that are 2D are extremely common, so wouldn't those be bloated?
It's me, Mario! (Talk / Stalk) 14:15, 15 April 2016 (EDT)
- 100% the case with N64 games. I've noticed a few oddities with oversized Wii games. The world "Life" in the life meter of Super Mario Galaxy seems to be a vector graphic or something because no blurring occurs to make it appear smoother unlike the number (:File:Buldergiestpunching.PNG). --Wildgoosespeeder (talk) (Stats - Contribs) 14:34, 15 April 2016 (EDT)
- Nope, for the sake of the argument all HUDs I have seen are raster sprites, Dolphin just does "behind the scene" edits and scaling to make the sprites look better when enlarged.--09:17, 18 April 2016 (EDT)

- Nope, for the sake of the argument all HUDs I have seen are raster sprites, Dolphin just does "behind the scene" edits and scaling to make the sprites look better when enlarged.--
- 100% the case with N64 games. I've noticed a few oddities with oversized Wii games. The world "Life" in the life meter of Super Mario Galaxy seems to be a vector graphic or something because no blurring occurs to make it appear smoother unlike the number (:File:Buldergiestpunching.PNG). --Wildgoosespeeder (talk) (Stats - Contribs) 14:34, 15 April 2016 (EDT)
- So, the HUD could be bloated? HUDs that are 2D are extremely common, so wouldn't those be bloated?
- The issue of oversized emulator images vs. real hardware render is usually due to how true 3D graphics render vs. sprite-based renders. Rendering 3D images in general to look nice in a specified resolution does a lot of behind-the-scenes math that can round out rough edges before converting that scene into what is called a raster graphic, similar to how vector graphics work but in three dimensions instead of two. If you were to do the same to a sprite-based render, which is just a dynamic raster graphic, you would be duplicating pixels, increasing redundancy in the image. In that case, you are better off with 1x native because we can resize that on-the-fly to be any multiple native resolution without affecting the source image. --Wildgoosespeeder (talk) (Stats - Contribs) 23:46, 13 April 2016 (EDT)
- Oooh, good point, so I guess I'll have to throw out the sprite bloating argument. I still don't see exactly why we need 2K-sized screenshots when something close to native resolution works perfectly fine. It would ease screenshot browsing for starters.
It's me, Mario! (Talk / Stalk) 21:01, 18 April 2016 (EDT)
- The way Dolphin takes screenshots is faulty. It's looking at the wrong buffer. I keep trying to explain this to Megadardery (talk) as to why I upload oversized versions of GCN/Wii game screenshots but I don't think I am being very clear with communicating that fact to him because he keeps wanting to extend that argument to N64 games as well. The thing is that N64 emulation screenshot code is working perfectly for games running at native 320x237 while Dolphin is not. Usually N64 games are running in 320x237, but sometimes I see games truly go 640x474, like Bulbapedia:File:Pokemon Stadium Mode Select.png. Dolphin has a hard time capturing at native cleanly, even with recommended settings to capture at native resolution without the image being too large. Widescreen-enabled games have issues the most. The devs themselves have said so. The oversize resampling that happens above 1x native, which is the method I am currently recommending, just hides the blunders of the faulty screenshot code trying to capture at native at the expense of being bigger than what a real GCN/Wii can produce. --Wildgoosespeeder (talk) (Stats - Contribs) 00:24, 19 April 2016 (EDT)
- In my opinion, I do personally like the looks of higher resolution screenshots. My opinion of this is why not? If we can capture gameplay with better clarity via emulation and therefore illustrates subjects better, then I like it. In my opinion, it's not that much different than rendering game-ripped models at higher resolutions than the game they originally appeared in.
- Don't worry about getting it exactly at native. We're not as stringent as SmashWiki (who's adamant about resolution sizes) when it comes to resolution, so don't let these issues get in the way. If you can't get it exactly at native, but you can get the aspect ratio correct, just don't bother.
Maintenance Concerns[edit]
Is this just pointless maintenance or does this maintenance save time and energy in the longrun?
- If I thought it's pointless, I wouldn't be providing feedback AND I would be saying that it is a waste of time.
It's me, Mario! (Talk / Stalk) 00:25, 13 April 2016 (EDT)
- Not specifically you, but it could be a concern of others. --Wildgoosespeeder (talk) (Stats - Contribs) 00:38, 13 April 2016 (EDT)
Other Concerns[edit]
Voice them!
PNG Monster Misconceptions[edit]
I think there are some misconceptions about what PNG Monster does to existing PNGs. Technically, a PNG is an already compressed bitmap image just with the PNG extention instead of BMP. PNG Monster is there to apply the best compression algorithm possible for each PNG it looks at and remove meta data that is unusable in a web browser (like EXIF data that can be found on JPEGs). --Wildgoosespeeder (talk) (Stats - Contribs) 18:04, 26 May 2016 (EDT)
Potentially Bad Images (Not Really Up For Discussion But Rather a Personal Log)[edit]
This image is poor quality. It has been requested that it be reuploaded for better quality.
PNG and clean versions wanted. --Wildgoosespeeder (talk)