Covarr said:
DiscostewSM said:
Rankio said:
I don't know why they can not resize the screen correctly. You can have the same SNES aspect ratio but adding black bars to the sides.
The performance hit would be greater, as copying from one buffer to another would have to go pixel-by-pixel, vs the line-by-line they are doing now.
Let me give the world a little lesson about SNES aspect ratio:
The SNES renders at a resolution of 256x224. With square pixels, that would be an 8:7 aspect ratio. The only thing is, the games were never meant to have square pixels. The SNES was designed to output to a television, which would display non-square pixels, stretching the games to fit its 4:3 aspect ratio. Game developers knew this, and so all the art, assets, etc in a game was intended to be stretched in this manner.
The DS renders and displays at a resolution of 256x192. It has square pixels, and an aspect ratio of 4:3, same as a TV. A SNES game has to be squished and lose some pixels to display on a DS, but it's the right aspect ratio. Cropping the top and bottom is a LESS accurate image in that regard.
Any questions?
You are correct, but you are not understanding Rankio's suggestion. He's talking about the aspect ratio of the SNES, not the aspect ratio of the TVs back in the day. He suggested squishing the display horizontally so that it matches the internal 8:7 ratio the SNES displays at (he made sure to include adding bars to the
sides in his post for clarification). Most people nowadays that play SNES games are not playing on an actual SNES, but an emulator that is played on a system who's display doesn't take into account a TV's aspect ratio.
My response was that it would create a performance hit because the number of operations to handle the same amount of data would be much greater. As it is right now with Display Mode 0, it repeats the copying of a block of 6 pixel lines (256 pixels each), which is about 1536 pixels a go while skipping a full line of pixels. With trying to achieve the SNES aspect ratio via software, copying would be forced to about 6 pixels per go while skipping one pixel alongside for each line being copying from the earlier example. The amount of data having to be copied shows the latter method as less, but because of the great inclusion in CPUs known as Block Copying, large chunks of sequential data become faster to copy because of no need to stop as often when skipping a set of data. An example would be that in the amount of time it took to copy 6 pixels (12 bytes in this case), the version of copying 48 bytes could take just as much time, possibly less because it was optimized to handle large amounts of data. We could go into further detail, such as problems when copying from a non 4-byte aligned memory location, but no one needs to know that stuff.