User talk:Wildgoosespeeder/sandbox

Suggestions
Here are some tips based on my own experience. I suggest you read TCRF's guidelines thoroughly. Various systems DS/i 3DS Wii U --Hiccup (talk) 04:36, 10 February 2016 (EST)
 * NO$GBA
 * on DS/i (at least) You must set NO$GBA to "poppy bright" to get proper colours
 * ripped in-game video frames
 * should be marked as "sprite", not screenshot
 * NO$GBA
 * Never use NO$GBA for 3D
 * capture card
 * hold start+select when capturing DS/i software via a 3DS capture card, so the software is run at native resolution
 * capture card
 * make sure the software is updated, as older versions seemed to produced screenshots with dark borders
 * capture card
 * use a capture card that is suitable for high resolution images, and does not use lossy compression
 * This is nice things to add to the guide (especially NO$GBA-related suggestions), but this doesn't answer my original question. Internally before the rendered frame is sent to HDMI, can the Wii U produce a 1920x1080 image?
 * Oh, sorry. I don't actually know about the Wii U hardware's workings. I will ask at wiiubrew.org. --Hiccup (talk) 06:52, 10 February 2016 (EST)
 * Anything? -- 18:21, 11 February 2016 (EST)
 * Not yet. --Hiccup (talk) 12:28, 12 February 2016 (EST)

RE: Wii U
Unfortunately I don't own a Wii U, let alone have a deep understanding of how it works. Regarding the actual draft I have several concerns:
 * For starters, this page encourages the use of when the image doesn't comply with these standards. As I stated earlier, the image-quality template was created for one purpose, to mark poor quality images with high-priority. Using it for every image that simply doesn't follow these standards is an overshot, and will reduce its usefulness.
 * Requiring PNG compression is also another thing that complicates the situation. Even though the compressed image has the same quality as the original image, usually, the difference in size is so minor, that it becomes a slow and tedious task to compress every image being uploaded. Forcing uploaders to use it, as the introduction implies is not something I agree with, PNG-Monstar is an unnecessary additional step to otherwise an already difficult process of capturing images following these standards and the intro should be changed to reflect that the uploader should use it, but it is not a requirement.
 * Discouraging screenshots taken from YouTube videos is another huge mistake. Say a user finds an article with no image, and he doesn't have the necessary setups to take such screenshot, in that case, he should be encouraged to fix the no-image issue by getting a simple screenshot from any YouTube video he comes across, and tag it with if, and only if it has poor quality.
 * N64 screenshots: As I stated earlier, I'm aware of the fact that the N64 system's internal resolution is 320 × 240. But as far as I know, if you use a capture card, you get a 640 × 480 shot. And our screenshots should reflect that fact and show the images, as the original hardware shows it, which brings me to the next point...
 * GCN, and Wii screenshots: in the actual draft, this is a huge inconsistency. We can get screenshots as close as the native IR as we can by using a few settings, and I actually agree with that to an extend, but I remember discussing that with a few people a few years ago, and the general response was: there is no reason to have standards for Dolphin's screenshots, and that the higher the resolution is (even if beyond the hardware's native IR) the better the image is, but why have a complicated set of standards for otherwise a good working system.

At this point, I'm not actually supporting the draft, the GCN and Wii resolution inconsistency problem should be tackled first, and if it is not solved. Well, there is no reason to make a law that goes around the reality. It's a worthless page. Unless it was changed to a help page instead.-- 09:04, 10 February 2016 (EST)
 * Addressing concerns:
 * I know this . I still remember the conversations we had here. I think I have a good idea what MarioWiki needs and how we can split up all images tagged with so that way we can put disputes around that tag to bed once and for all. If you want to know what I had in mind, I want to follow a system similar to the one found on Bulbapedia. There will be subcategories for Category:Quality requested. If an image is not tagged with  but rather some other tag, it will not show up in Category:Quality requested but rather the subcategory.  will still work as it always has.
 * I will note this.
 * Taking screenshots from YouTube videos only solves one of two problems. Emulator screenshots, if done right, kills two birds with one stone. Exception being pre-release videos as those can't be replicated in the final release most likely.
 * The HUD pixelates if higher than 320x240. File:PMBowserBattle1.png was the biggest offender I have seen so far. I have since corrected this.
 * My experiences with Dolphin is a whole different can of worms. That section was to simplify the overly complicated way to take good screenshots which other emulators for other systems do with one simple step. Exception being N64 and NES as TCRF put it.
 * I see a lot of screenshots uploaded without proper care how to get them to look good. A lot are taken haphazardly. MarioWiki lacks a recommended procedure. That is the goal of this sandbox. -- 15:25, 10 February 2016 (EST)
 * I disagree with the "bigger is better" notion. These games aren't designed to be displayed like this, and they often look crisper in native res. They also take up much less space. But I do agree that PNG compression is sometimes useless. Sometimes however, it makes a *huge* differences. --Hiccup (talk) 11:56, 10 February 2016 (EST)

re resolution: Image use policy specifically states it's preferrable to capture games in their native res and that external filters and aspect ratio changes are not acceptable. --Glowsquid (talk) 12:13, 10 February 2016 (EST)
 * In my opinion, while capturing Dolphin screenshots in their native resolutions is preferable, I'm not advocating reuploading all screenshots for lower resolution. The policy has stated that it is preferred, but not forbidden. I think it's too much restriction on what good stuff we have to upload or not. Granted, a user a few years ago uploaded screenshots that far exceeded the native resolution and aspect ratio, but that's in the extremes, where we don't allow it. 12:56, 10 February 2016 (EST)
 * Doing stuff better in the future != having to fix all the old stuff instantly, or even at all --Hiccup (talk) 14:09, 10 February 2016 (EST)
 * If the Dolphin screenshot code took pictures the right way instead of the current wrong way that is a pain in the butt to setup properly, the GCN/Wii section would see a revision reflecting that. The developers of the emulator know that this should be fixed for years now but haven't gotten around to it. Don't bother trying to talk to them. They don't like it. I learned that the hard way. -- 15:25, 10 February 2016 (EST)
 * What is the problem with dolphin? I just followed the TCRF page's instructions and it worked fine. --Hiccup (talk) 16:02, 10 February 2016 (EST)
 * The instructions work fine for games in 4:3 but for games that can render 16:9 natively, the images are too small. Also TCRF wants 4:3 over 16:9 in almost all cases. -- 16:12, 10 February 2016 (EST)
 * You have to right click on the game to edit its settings to set "widescreen" to on. No other way. Yes, it is annoying if you are taking screenshots of many games. Also, you shouldn't be so quick to judge what TCRF (i.e. the admins) want based on one page. --Hiccup (talk) 16:20, 10 February 2016 (EST)
 * Those settings for the version of Dolphin I am using are default (except for Super Mario Strikers and F-Zero GX as those games need to be set manually). I wasn't judging. Don't know why you thought that. I follow the rules because I hate being in trouble with admins (although I am not registered on TCRF). -- 16:36, 10 February 2016 (EST)

NES size
Shouldn't we follow TCRF's guideline that all NES screens (regardless of region) are 256×240? --Hiccup (talk) 07:16, 16 February 2016 (EST)
 * I think TCRF's stricter rules on that are for making things look neater on pages. MarioWiki kind of wants to include all regions, if possible, for cultural diversity or something but I am not entirely sure. -- 15:11, 16 February 2016 (EST)
 * Err... what? What has this got to do with cultural diversity? It is a screen resolution. --Hiccup (talk) 15:05, 19 February 2016 (EST)
 * I don't really know either. Why did I say that? Maybe not cultural diversity. Maybe to not be biased to just NTSC-U or NTSC-J but include PAL as well to if there is an international release. -- 17:18, 19 February 2016 (EST)
 * What exactly are you saying? Include what where? --Hiccup (talk) 06:38, 20 February 2016 (EST)

Virtual Boy screenshot
Indeed, I created the screenshot concerned. I used the VBjin emulator. --
 * Thank you. I shall try it out later. -- 17:19, 19 February 2016 (EST)

Could you enable editing
for everyone, or at least me? :P. I'd like to fix some stuff up. I won't vandalize it or anything :) --Hiccup (talk) 03:48, 13 April 2016 (EDT)
 * It's technically a userpage so by automatic protections, you can't do a thing about it. Only I or admins can edit it. Don't know if it can be overridden. -- 03:17, 5 May 2016 (EDT)
 * Please could you move it to a non-userspace space then? --Hiccup (talk) 08:31, 6 July 2016 (EDT)
 * That would be against MarioWiki policy. moved a different sandbox page of mine to be a user namespace instead of the template namespace. -- 14:36, 28 July 2016 (EDT)

MK7 works in HANS for me
The ones that don't work on any 3DS are the ones with the new encryption type (e.g. recent eShop apps) --Hiccup (talk) 06:21, 28 July 2016 (EDT)
 * Please explain that one to me because I am absolutely new to 3DS homebrewing. My copy of Mario Kart 7 is a cartridge (among all other 3DS games I own that has a cartridge version available). Do you think it is the patch that fixes online mode being able to take ultra shortcuts on three certain tracks that is interfering with HANS? -- 14:34, 28 July 2016 (EDT)

Virtual Boy screenshots
Hello again, sir! Remember the screenshot from VB Wario Land, which I uploaded some months ago? Well, as you can see, I edited it to match the Virtual Boy's original color scheme. The hue magnitude is +54. Is it correct? I would like to upload more screenshots from the game, but VBjin, the emulator I use, only renders the game in purple and I cannot find an in-app option to change it to red. Should I continue editing the screenshots I will further capture, or find some way to get them already red-coloured? Note that VB emulators like Mednafen or Red Dragon (which I heard are the best ones out there) work pretty bad on my PC despite me not having quite the oldest technology out there, and I do not trust other minor emulators to work well. Thank you for your attention! --
 * My guess is that internally, there are four values any pixel can be, similar to that of a Game Boy game before Game Boy Color. The color red was chosen by Nintendo as a cost-saving measure. That is as far as my knowledge goes. Going from purple to red just makes sense as that is how a real Virtual Boy shows us the game. As to how to accurately do so without having the file size be too large is unknown to me. If you want my best guess, just take a non-colorized version of the screenshot (white, light grey, dark grey, black), tint the picture with color #FF0000 (hex value for pure red) in Photoshop or something (becomes red, dark red, darker red, black), and apply PNG Monstrous. -- 16:51, 1 September 2016 (EDT)
 * OK! Thanks for the advice! --

More 3/DS/i methods
DS/i: 3DS --Hiccup (talk) 08:44, 8 January 2017 (EST)
 * Running DS/i games in 1:1 mode on 3DS and taking screenshot with a capture card
 * Using a DS/i capture card
 * Using a 3DS capture card
 * Using a CFW-only homebrew tool such as NTR