User talk:Semako

Advice On Good Quality Screenshots

Your screenshot uploads for Super Mario 64 aren't very good quality. Ever try emulation? I have a WIP guide that helps with all consoles. Hopefully you run Microsoft Windows, as some emulators haven't been compiled for other operating systems. That's a common problem I get told by other users that I give this advice to. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 04:29, 9 October 2017 (EDT)

Yes, I have a high-end Windows PC, so emulating shouldn't be a problem - however, I don't have a controller for the PC, and playing Super Mario 64 with mouse and keyboard is not exactly what I want to do ;-) Also, shouldn't it be possible to get higher quality screenshots from a N64 game via a capture card? When I record videos or screenshots from Wii U or Switch games, where the console can be connected to the capture card via HDMI rather than Cinch, I never have quality problems. Semako (talk) 04:34, 9 October 2017 (EDT)

Yeah, that's another hurdle with emulators that rely on the analog stick. The sooner you get an XInput device, such as an Xbox 360 (wired over wireless because a wireless adaptor is needed) or Xbox One controller (uses MicroUSB without the need to insert AA batteries or Bluetooth, but haven't tried the Bluetooth option), the better. HDMI is digital so that is a good option for screenshots for Wii U or Nintendo Switch. However, the Wii and older uses composite video, and that is analog, and that is a degredation of image quality no matter what you do. I recommend emulators because hardmodding to get the internal render is not a route I recommend taking. Internal render is the process that takes place before each frame is sent to the digital-to-analog converter of each console so a TV can understand. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 04:43, 9 October 2017 (EDT)

Switch Pro Controllers can be connected to the PC too using Bluetooth - and as I'm going to order a custom one from Controller Chaos, I won't need to get an Xbox one. Then I will redo those screenshots using Project64 1.6 (1.7 is banned on Speedrun.com, as it is possible to change the VI refresh rate in this version). But for now, I will have to use the current versions when I continue working on the SM64 glitch list, which will most likely be today afternoon after university ends. Thanks for your advices ;-) Semako (talk) 04:52, 9 October 2017 (EDT)

I've had issues using Nintendo controllers on non-Nintendo hardware. Nintendo actively goes out of its way to make their accessories incompatible with Windows (like with the Wii U GameCube adaptor that came bundled with Super Smash Bros. 4, but Dolphin emulator has a solution for that), but then again, I don't have a Bluetooth receiver. Actually, Project64 is on 2.3.2, it is on GitHub, and supports 64DD emulation (latest stable build available on the website has a bug that was fixed later). 1.7 is a very dated release. I highly recommend reading the N64 section of my guide. There are some important details there. I wouldn't worry too much about speedrun valid emulators on Super Mario Wiki. My guide is more for the casual editor. However, there are some minimum standards in place. For example, I advise not using ZSNES for SNES emulation. Edge cases, I guess there is no choice (had to do that with a replacement for a Yoshi's Safari image because a save was only available for ZSNES), but for general use, no ZSNES. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 16:33, 9 October 2017 (EDT)

You might not worry about speedrun-valid emulators, but I do as a Mario 64 speedrunner ;) And the emulator's version shouldn't really have an impact on the image quality. I never had problems using my Nintendo hardware on my PC (ran GCCs with the original nintendo adapter for both Dolphin and Rivals of Aether), and according to other users, the Switch Pro works well under Windows, so I'm not worried. Semako (talk) 16:39, 9 October 2017 (EDT)

You can have both the speedrun valid and more wiki valid installations of the emulators. To be fair, my page isn't any sort of policy to go by (I said "wiki valid"), but it is a great start so that way you or others don't submit images that need to be retaken later down the line. Reduced maintenance in the longrun. There are just so many images that need to be redone, many of which aren't tagged or even known to be faulty. I've gotten complaints that I use {{image-quality}} too often. I can understand that. I live by "get it right the first time" because then, the tag doesn't need to be used in the first place. Granted, having something that is of poor quality is better than having nothing at all, so I think in most cases, the tag can be avoided. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:38, 9 October 2017 (EDT)

Received my controller today, so I guess I'll be able to redo and do new images soon ;) Semako (talk) 10:53, 19 October 2017 (EDT)

Better, but a common problem with N64 emulator screenshots is bad filtering of HUD elements, likely using default plugins (which aren't recommended anymore by veteran Project64 users). Your newer uploads have this bad filtering. Use angrylion graphics plugin (or GLideN64, not Glide64) and follow recommended settings. Also, internal renders of Super Mario 64 are 320x237. Supersized screenshots tend to cause the bad filtering. Keep in mind that the N64 section of my guide needs to be reworked. I've been wanting to do that for some time now. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:26, 19 October 2017 (EDT)

Sorry, but do you really want such tiny images only because the HUD looks slightly better? When you scale down my screenshots down to the wiki's thumbnail size you don't even see the difference - and when you scale up one of those tiny images, you get an ungly looking mess of pixels.
I converted them to PNGs when cropping them with Photoshop to remove the black outlines, because PNG simply is the better format in terms of quality; and in the german MarioWiki, we only use PNG images ;-) Semako (talk) 15:14, 19 October 2017 (EDT)

The resolution reduction is the right balance between having an appropriately dimensioned image and having it not be a bandwidth hog. Also, the policy states that images closer to what real hardware can produce is preferred. Even though the analog composite video is roughly 640x480, that is blurry compared to the internal render of the N64, and that varies sometimes, but most of the time, it will be 320x237. I have a lot of trust that the angrylion plug-in is producing good screenshots. I have gotten into debates with other users about how big N64 images should be (amongst other Nintendo systems). It's a hard question to answer that doesn't satisfy everyone 100%. It's a very touchy subject.

As for PNG, I am aware of what it is capable of, but I explained in a proposal that JPEG to PNG conversion doesn't do any good. Why you got JPEG might be a setting you need to adjust in Project64. Should be no big deal. Under the options menu, go to configure graphics plug-in. I don't know what plug-in you are using but finding the screenshot setting for the plug-in should be there and what format should be used. If PNG is unavailable, select BMP. You can convert that to PNG later. Keep in mind this wiki considers converting and replacing two different processes. I do JPEG replacement all the time, if I can submit a high quality PNG that has no JPEG artifacting. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 15:33, 19 October 2017 (EDT)

Regarding file names.

In this proposal, you stated "in my opinion, file names should always be preferred over other sources." - however, that contradicts your position on this proposal. You may have not been aware since the proposer neglected it, but the file name for Morty Mole, "Indy", is the Japanese romanization for Mega Mole. I just wanted to make sure you knew what you were talking about when voting. LinkTheLefty (talk) 11:15, 10 October 2017 (EDT)

I did not neglect that. I said it at the top. I may have not surrounded it with a neon sign, but it was up there when I first made the proposal. Doc von Schmeltwick (talk) 19:28, 12 October 2017 (EDT)