Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
EDIT: I have merged another thread with a very large poll with this one, which is why the text doesn't seem to match up with the poll. See [post 275914]here[/post] for the post that originally led off that thread.
Original post below.
---
I'm starting this thread out of a discussion that arose on IRC, and a desire for greater feedback thereof.
Currently, our encoding of SGB games is done with the border and with a 4:3 display aspect ratio flag. The justification for this is that SGB, as a platform, outputs a 256x224 (or 256x240) video stream to be displayed on a TV; thus, in accordance with the rest of our set-top consoles, the 4:3 flag is set.
There's been some disagreement that this is the proper course of action for this particular console, and I'm inviting further discussion on the matter.
Ok, guess it's that time again.
Quoting the encoder guidelines, there's this paragraph:
Handhelds don't need AR correction, because their resolution is always fixed to match the display matrix pixel-for-pixel without any kind of stretching involved.
For those those consoles which are intended to be displayed on a TV or on CRT monitors, the MKV/MP4 must specify a display aspect ratio of 4:3.
The contradiction here is in the fact that we're using GameBoy (a handheld) games for SGB, yet SGB is intended to be shown on a TV. So what appears to be the norm now is stretching the signal sent by SGB to conform to the 4:3 aspect ratio.
Now let's see what happens when you run a GB game through SGB: the original 160x144 (square pixel) signal is put into the middle of a 256x224 grid (SNES resolution, non-square pixel), and is then sent to the TV which stretches the 256x224 signal to 4:3 aspect ration. Obviously, the original 160x144 picture in the middle gets stretched as well, which isn't good. Could there be a way to counteract it? One would have to contract the GB signal before placing it inside the SNES resolution grid so that the TV would expand it back to the correct proportions. But since it's practically and economically infeasible for a low-power hardware to do that without even worse artifacts, it wasn't done.
Bottom line: stretching introduced by the TV is an artifact to a GB game. GB games are developed for square pixels. SNES games are developed for TVs that scale 8:7 to 4:3.
Now, let's touch the subject of using SGB in the first place. As far as I'm aware it was merely a part of Bisqwit's original plan of enhancing the viewing experience, which also was the sole reason for antialiasing N64 games. That was a very clear step away from authenticity, but it was well thought-out, paid off, and nobody complains. The SGB situation, however, wasn't so well thought-out and had amendments already introduced (again, by me; see the bottom addition). I think it's time for more amendments because SGB is by far not a miracle way to make any GB game look better, but a very limited colorization vehicle with its own shortcomings.
VBA doesn't stretch the games it shows in SGB mode. We have the choice of not stretching them by default in our encodes.
Bottom line 2: stretching for consoles with native 4:3 output devices made sense. Stretching SGB games doesn't make sense, because a TV is a non-native output device for GB games. Native devices should take precedence in deciding this.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
In the case of Pokémon games, it's clear that Game Freak wanted them to be displayed at a square-pixel 160x144 resolution considering they hopped on the Game Boy Color bandwagon as soon as they possibly could with the development of Pokémon Yellow version. It uses the same palette enhancements used by the Super Game Boy parts of Pokémon Green, Red, and Blue, but runs on a Game Boy Color.
Pokémon Green, Red, and Blue were intended to be played and completed on a Game Boy. This is evident from the goal of catching all the Pokémon, which requires a link cable usable only on the Game Boy (Pocket) hardware.
I stand by my argument that the developers' intentions matter most. The graphics in SkyRoads (DOS) were clearly drawn with a 4:3 aspect ratio in mind, despite the native resolution of its platform being a 16:10 resolution (as is evident from the circles). Graphics for the Pokémon games were drawn as squares with rotationally-symmetric Pokéballs and other circular sprites.
The NES outputs an NTSC signal over composite and rf, but it isn't stretched to the full width of the signal. I don't know why NES encodes on this site are stretched. They aren't stretched to the full 4:3 on my TV. There's quite a bit of black space on the left, which would normally be filled by a cable TV signal. One wouldn't stretch an NES' image because otherwise they would have to revert that change every time they wanted to watch TV.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
I'm also for turning off any aspect "correction". It just makes the videos look awful, and stretched.
I'm glad someone other than me has finally had the balls to scream at Grunt about it.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
I would say this really is best left up to a case by case basis.
Some games change their border throughout the game to reflect progression to different areas or levels. In those games, I think we definitely want to keep the border on.
For a game where it's static, I'd say it should hinge on what looks better for the game. For Pokemon Blue/Red, I personally think without.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Nach, nobody suggested removing borders. This discussion was born entirely out of my (and others') criticism of aspect-correcting SGB image. Personally I don't care about borders, but sure, let them stay.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
moozooh wrote:
Nach, nobody suggested removing borders.
Actually, Lex did. Further, proper aspect ratio is a factor tying into the border issue.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Sorry about that.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I did not have SGB in mind when I wrote whatever I wrote, and therefore I agree that it was not well-thought, in moozooh's words.
I have no qualms with the encoded video not including the SGB borders, and consequently, displaying with Game Boy aspect ratio, but I would like to see the borders in the screenshot.
Let's see.
SGB with borders: An imaginary 40 cm × 30 cm TV screen surface has 256x224 pixels cast to it. Each pixel therefore corresponds to a 1.5625 mm × 1.3393 mm area on the screen. The pixel aspect ratio therefore is 7:6.
The 160x144 game content is displayed at an aspect ratio of 35:27, or ~1.2̄9̄6̄.
SGB without borders: An imaginary 44.5976 mm × 40.1378 mm LCD screen has 160x144 pixels displayed on it. Each pixel therefore corresponds to a 0.2787 mm × 0.2787 mm square on the screen, for a pixel aspect ratio of 1:1.
The 160x144 game content is displayed at an aspect ratio of 10:9, or ~1.111̄ .
Yes, it can be seen from these calculations that the TV screen stretches the game's content very little horizontally (by 16.7 percent).
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
sgrunt wrote:
The justification for this is that SGB, as a platform, outputs a 256x224 (or 256x240) video stream to be displayed on a TV; thus, in accordance with the rest of our set-top consoles, the 4:3 flag is set.
So basically it's a handheld being displayed on TV, with an extra border around it?
That's a pretty big design flaw, I'd say. I'm sure a lot of graphic designers were very angry to see their artwork squished.
We should probably not use aspect ratio correction in order to keep the core artwork intact. Theoretically, that might cause a problem for the border artwork, which might very well expect a 4:3 ratio, but I think that's of less importance.
Bisqwit wrote:
Yes, it can be seen from these calculations that the TV screen stretches the game's content very little horizontally (by 16.7 percent).
I'd say that's significant. To illustrate by example, Abe's Oddysee has a native resolution of 368x240, to be displayed at 4:3. That's a 15% difference in horizontal width.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Interestingly, even the border appears to have been made for a 1.0 PAR, even though it's only visible when using a TV screen.
But it's pretty clear that the game art should be the leading factor, and it clearly wasn't made for this kind of stretching.
As for the border, I honestly don't care too much.
If it was up to me, I'd just remove the border as well, especially when it's meaningless like in this case. We care so much about screen savers, and then we keep the same pixels on the screen for various hours?
However, the REAL reason of why I remove the border when I watch SGB movies in VBA is that without it I can get a much larger image when I go fullscreen, e.g. I can use the whole screen (minus the sides, of course) for the action and not for some questionable eye candy.
Should you want to keep the border, I think there should be no aspect ratio correction, since the pixels are square on the Game Boy. Good thing that I set Media Player Classic to ignore the aspect ratio flag.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Lex wrote:
Those Pokéballs look wrong, as does everything else.
I don't know what's going on here exactly, but Oak's eyes in the first screenshot look wrong. Is this a lossy or software enlarged image?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I don't know about you guys, but the two non-deformed screenshots look identical to me. I blew them up to 400% normal size and the only difference is that the second image uses a pale blue instead of pale grey.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Derakon, look at the number of used colors.
The first one uses 1216, the second one, correctly, uses 4.
You can perform an arithmetic difference between the two images to find out what's going on:
The difference should be nothing (e.g. a completely black image).
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
It's geometrically lossless. Professor Oak has facial details in a light grey. My shot was taken from my lossless x264 encode, which was encoded with a YV12 color space. Only the color is lossy.
I guess the extra colors are from bleed. I really wish I could use YV24. x264's lossless mode is clearly not really lossless.
Stretched to 4:3:
Those Pokéballs look wrong, as does everything else.
And this is how it looks like once it's deformed:
I hope that I helped.
The difference should be nothing (e.g. a completely black image).
