File talk:BS SMUSA Mario and Friends.png

From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search

This image is a good example of the potential problem of a "exactly as rendered" policy - it was never intended to be shown with square pixels (which give an 8:7/1.143 aspect ratio, rather than the intended 4:3/1.333), meaning it's squished horizontally. [While the same problem technically occurs in many other cases, it's nowhere near as essential in the case of your average sprite-based screenshot since they're stylised either way]. - Reboot (talk) 22:32, 17 August 2016 (EDT)

Yeah. The goal should be to have good screenshots, not screenshots that are closest to the hardware output. I don't know why people push for 320x240 Super Mario 64 screenshots even though 640x480 is of higher quality. A gossip-loving Toad (Talk) 22:42, 17 August 2016 (EDT)
There are many rendering problems within N64 emulation. [1] Bigger doesn't mean better quality. That produces artifacting. It's better to go with a pixel-accurate screenshot. GCN/Wii emulation, I don't know why it looks excellent to take HD. Going pixel accurate is also very good for file size. All pixels are accounted for and no rendering issues occur. --Wildgoosespeeder (talk) (Stats - Contribs) 01:13, 18 August 2016 (EDT)

Just to show the difference between native-resolution-with-square-pixels and intended-aspect-ratio (with 7:6 pixels). It's quite visible:
Please note, the reason the 4:3 image is so large is because there's no other way to do 7:6 pixels than enlarge the image by 700% horizonally & 600% vertically to make each "pixel" a block of 7x6 square pixels! (Similarly, I didn't reduce to <256 colours because of the way MediaWiki scales such images in thumbnails) - Reboot (talk) 01:00, 18 August 2016 (EDT)
I'll be honest here. Snes9x is not cycle accurate. That is what I used to take that screenshot. I don't know if the screenshot I submitted is what a real Satellaview would produce. I would try Higan/bsnes (cycle accurate), but the setup is genuinely confusing for Higan and I can't seem to get that emulation to work on the bsnes fork (black screen). I don't know if it is possible to do a sprite rip. --Wildgoosespeeder (talk) (Stats - Contribs) 01:13, 18 August 2016 (EDT)
The problem here is very simple and is very unlikely to be emulator-related - it's the same as, say, N64 widescreen screencaps, which tend to look squished if you go "pixel accurate" (or that weird DK64 bootup I think you've commented on before). The only difference is that it's 8:7-intended-to-be-4:3 rather than 4:3-intended-to-be-16:9. The aspect ratio of the pixels themselves is not intended to be square* - no TV ever has been 8:7 AFAIK - but digital still formats generally have a square pixel ratio. Which means "pixel-accurate" is not accurate to what you would see on a TV.
*which is the case with a lot of TV stuff - hell, the active picture area excluding blanking of the "ideal" UK digital SD broadcast is 704x576, although channels often broadcast at 544x576 to save bandwidth [i.e., money]. For 576 tall, the 4:3 width with square pixels would be 768, for 16:9 it would be 1024) - Reboot (talk) 01:28, 18 August 2016 (EDT)
I don't know if the pixel-accurate plug-in is responding as a real N64 would or it could be experiencing bugs. I don't know for sure but many games render very well, such as Super Mario 64, Paper Mario, and Yoshi's Story. Some games I have experienced weirdness, such as Mario Tennis 64, Donkey Kong 64, and maybe the Mario Party (series). As for 8:7 to 4:3, I think some letterboxing is being added to the 8:7 image to keep it to scale. --Wildgoosespeeder (talk) (Stats - Contribs) 01:36, 18 August 2016 (EDT)
Why are you primarily responding to the aside rather than the main point?
Because there wasn't much more to talk about? This is a mystery to me at this point until someone can either do a sprite rip or use Higan/bsnes to take a screenshot of the output. I read somewhere about how inaccuracies with how the emulator tries to mimic the instruction set of the real hardware can yield improper results. [2] --Wildgoosespeeder (talk) (Stats - Contribs) 15:40, 18 August 2016 (EDT)
No, it wouldn't be letterboxed (strictly, pillarboxed). The 256x224 image is horizontally squished (just look at it!) because the pixels were intended to be stretched to a rectangular shape by the TV. It isn't even uncommon in the TV domain today, which is why I pointed out the UK transmission thing (or HD 1440x1080 pictures intended to be stretched to 16:9). - Reboot (talk) 06:48, 18 August 2016 (EDT)
No, what I mean is that a NES/SNES internal resolution is 256x224 (NTSC) or 256x240 (PAL). To make it not stretch on a 4:3 TV at the time, the vertical letterboxing was added. It was usually unnoticeable on TVs at the time but if you were to use an HDTV compatible with composite video or coaxial input, the letterboxing is more easily noticed. --Wildgoosespeeder (talk) (Stats - Contribs) 15:40, 18 August 2016 (EDT)
And my point is that it DID stretch. It was always and forever INTENDED to be stretched. - Reboot (talk) 16:06, 18 August 2016 (EDT)
The difference between the TV and emulator output, is this an issue only for Satellaview screenshots? The issue of showing a correct aspect through television stretching hasn't seemed like an issue to me until now. I'm having trouble following all these resolution numbers, although I am clever enough to see the difference between the two images which Reboot has compared.
'Shroom Spotlight Shokora (talk · edits) 17:27, 18 August 2016 (EDT)
It's not just an issue for Satellaview strictly, the reason I'm bringing it up here is that it matters more because we're talking about a drawn image that is visibly stretched (whereas most screenshots are stylised enough that it may technically be wrong, but "curing" it is more trouble than it's worth).
The simple point to take is that pixels don't have to be square, but in the PC domain - and most modern equipment that derives from PC formats like tablets, digital cameras, etc - they virtually always are. In the TV domain, that hasn't always been the case (and to some extent, still isn't), and it wasn't the case for the Super Famicom. But an emulator produces output (including screenshots) that are in formats which have square pixels (Hell, if you somehow hacked a physical SNES and redirected the picture signal from before the digital-to-analogue converter and sent it to a device that could PNG screenshot it, PNG has square pixels, so the exact same thing applies. It's the picture format, not the emulator, that's relevant here). Which means the whole output is, to the human eye, stretched or squished slightly. Compensating for this has some unwelcome side-effects, so it's only something to consider when things are visibly wrong - but I think these drawn images qualify. - Reboot (talk) 17:58, 18 August 2016 (EDT)
What about embedding the bitmap in a SVG to restore the intended aspect ratio? - A gossip-loving Toad (Talk) 11:12, 19 August 2016 (EDT)
File:BS SMUSA Mario and Friends.png, aspect ratio corrected --A gossip-loving Toad (Talk) 05:13, 2 December 2016 (EST)
Convoluted way to solve the issue. It all comes down to MediaWiki. Why can't we stretch the image directly? Why is forced scale a thing? All web browsers can support this but SVG support is hit or miss. --Wildgoosespeeder (talk) (Stats - Contribs) 20:20, 2 December 2016 (EST)